マイクロサービスの Active Directory の活用
庄司です。
新たなサービスの開発では、誰がサービスを使用できるかを確認するための認証 (Authentication) とサービスのどの機能にアクセスしてよいかを確認するための認可 (Authorization) を考える必要があります。
さらに既存の他のサービスが利用されている場合や、マイクロサービスのように複数の小さなサービスを組み合わせたサービスを提供しようとする場合、それぞれのサービス毎に認証の UI が異なっていたり、さらには、異なるログインID、異なるパスワード、パスワードポリシーの差異があると、ユーザーにとっては全体として負担の大きい使いにくいサービスとなります。
この課題に対応して、シングルサインオン (SSO: Single Sign-On) というソリューションを使う方法が一般的です。
Microsoft の Windows の世界では、「Active Directory ドメイン」で知られているネットワークに参加することで、シングルサインオンが実現されています。
サービス指向アーキテクチャ (SOA) では、SAML という SOAP ベースの実装によりシングルサインオンが提供されてきました。
多数のサービスの連携が一般的になり、またマイクロサービスアーキテクチャの進化とともに、OAuth 2.0 の具体的な実装として登場した標準である OpenID Connect が最近では多く利用されるようになってきています。
マイクロサービスアーキテクチャでの SSO
#いくつか理由がありますが、ここでは詳細を述べることは控えて、マイクロサービスアーキテクチャで SSO を実現するソリューションとして、現時点で最適なのは、OpenID Connect であると考えています。
OpenID Connect に対応した製品は増加し続けていますが、ソーシャルメディア向け、クラウド型、オンプレミス対応にわけることができます。エンタープライズアプリケーションを主とした場合には、Facebook、Twitter、Yahoo! 等のソーシャルメディア向けの実装は除外されることが多いと考えています。
クラウド型は、Amazon Cognito や IDaaS に分類されるさまざまな製品が登場してきています。
オンプレミスに導入する製品としては、Keycloak や OpenAM が有名です。
ユーザーディレクトリ
#SSO で認証認可を実現するベースとして、ユーザー情報 (ユーザー名、電話番号、電子メールアドレス、所属、役職、役割等) を管理するディレクトリが必要となります。
企業では、このディレクトリは社員の入退社、人事異動等さまざまな原因で頻繁に変更が発生します。
Active Directory
#企業に導入したそれぞれのサービスに個別のユーザーディレクトリが必要だとすると、すべてのユーザーディレクトリの同期を取ることが非常に大変なことであるということが容易に想像できると思います。
多くの企業で、Active Directory を利用したユーザーディレクトリが構築済みです。このような企業では、ユーザーディレクトリである Active Directory と人事システムが密接に連携されていることでしょう。
この Active Directory が持つユーザーディレクトリを Active Directory ドメインの外、つまり SAML や OpenID Connect で利用したい場合にどのようにするかというのが、この記事のテーマとなります。
これには、それぞれの SSO 製品のユーザーディレクトリにデータ移行する方法と、SSO 製品が持つフェデレーションという機能を利用する方法があります。データ移行による方法は、通常バッチ処理となり、そのためリアルタイム性を損ない、また、さまざまな SSO 製品が採用されている場合を想定すると、この移行のためのソフトウェアの構築、運用のコスト負担も大きくなります。後者の場合には、データ移行を必要とせずリアルタイムに変更が反映されるため大きな利点があります。
SAML フェデレーション
#多くの SSO 製品では、SAML フェデレーション機能が用意されています。そして、Microsoft の Active Directory では、Active Directory フェデレーション サービス (AD FS) があるため、SAML の IdP (Identity Provider) として機能させることができます。
SAML フェデレーションを利用することで、SAML を利用した SSO を実現しているサービスだけでなく、OpenID Connect を利用するサービスも含めて、Active Directory のユーザーディレクトリが活用できるようになります。つまり、単に認証時に同じログインIDとパスワードが使えるということだけではなく、電話番号、電子メールアドレス、所属、役職、役割等、ユーザーディレクトリで管理されている属性をも含めて連携が可能となるということです。
ネットワークセキュリティ
#Active Directory ドメインのネットワークへの参加は、一般的に社内のプライベートネットワーク (イントラネットともいいます) 内に閉じています。Active Directory をサービスしているドメインコントローラに、インターネット等外部のユーザーはアクセスすることはできません。
では、SAML フェデレーションを利用するために、AD FS で SAML の IdP をサービスする場合、インターネット等外部からのアクセスを許可しないといけなくなるのでしょうか?
そうではありません。SAML が登場した時代の歴史的な事情もあり、SSO 製品がパブリッククラウド等のインターネット上にあったとしても、AD FS のような SAML の IdP との直接的なネットワークを通じたアクセスは発生しません。SAML で受け渡しを行うデータは、暗号化されていない HTTP を使った場合でも安全に受け渡しが行えるように、IdP とサービスプロバイダ (SP) の相互認証に基づいて暗号化されています。そして、このデータの受け渡しはブラウザを通したものとなるため、SAML フェデレーション機能を利用した場合は、AD FS (IdP) - ブラウザ - SSO 製品 (SP) の経路になるため、AD FS が社内ネットワーク以外からのアクセスができない場合でも、ブラウザを操作する環境が同様に社内ネットワーク内にさえあれば、結果として Active Directory のユーザーディレクトを利用した SSO を、SAML や OpenID Connect に提供できます。
まとめ
#今、クラウドコンピューティングの進化とともに、エンタープライズアプリケーションをマイクロサービスアーキテクチャで実現しようとするトレンドに勢いがあります。こうしたときに、新たに認証認可基盤を構築し、ユーザーディレクトリの移行が検討されることがあると想像しています。
ですが、多くの場合、企業内には Active Directory のような認証認可のためのユーザーディレクトリが構築済みで、しかも、それは、実際、堅牢かつセキュアに運用されています。この既存の資産をセキュリティポリシーをそのままに、マイクロサービスへの移行に活用することの利点は大きいと考えています。
