OpenIG、OpenDJと連携したOpenAMの新機能：OSSによるアイデンティティ管理（3）（1/2 ページ）

今回は、OpenAMの姉妹製品で既存アプリケーションを改修せずにシングルサインオンを可能にする「OpenIG」と、OpenAMのデフォルトデータストアである「OpenDJ」について解説します。

[和田 広之（野村総合研究所）, 田村 広平（フリーランス），＠IT]

連載目次

　アイデンティティ管理を取り巻く課題について説明した第1回、オープンソースのアクセス管理ソフトウェア「OpenAM」の概要とそれを用いた不正ログイン対策について解説した第2回に続き、第3回は、OpenIGとOpenDJについて概説します。

　OpenIGは代理認証とフェデレーションゲートウェイを実現するプロキシサーバーで、OpenDJはアイデンティティ情報の管理やパスワードポリシーの制御などを実現するディレクトリサーバーです。今回は、これらを利用したOpenAMの新機能についても幾つか紹介します。

ユーザーの認証を代行し、SSOを実現する「OpenIG」

　OpenIG（Open Identity Gateway）は、既存のWebアプリケーションを改修することなくシングルサインオン（以下、SSO）できるようにする、オープンソースのプロキシサーバーです。OpenAM 10.0.0から追加されたOpenAMの姉妹製品であり、基本的にOpenAMと連携して動作します。

　OpenIGは、一般的に「代理認証」と呼ばれるアプリケーションへの認証を代行する機能と、後述するSAML 2.0のフェデレーションゲートウェイとしての機能を持っています。リバースプロキシ型のアーキテクチャを採用しており、HTTPリクエストをエミュレートしてユーザーの認証を代行します。

概要	内容
最新版	2.1.0 / 2012年5月15日
実装言語	Java
対応OS	クロスプラットフォーム
対応言語	英語
サポート	フォージロックによるサブスクリプション、日本国内でも幾つかの企業が有償サポートを提供
機能	代理認証、フェデレーションゲートウェイ
ライセンス	CDDL
プロジェクトサイト	http://openig.forgerock.org/
表1　OpenIGの主な情報

OpenIGによる代理認証

　OpenIGがどのようにSSOを実現するかについて、少し詳細に解説します。OpenIGは以下の図のように、一般的なフォーム認証を利用した複数のWebアプリケーションに対するSSOを実現する目的で導入します。

図1A　OpenIG導入以前

　これらのアプリケーションの前段にOpenAMとともに配置し^（注1）、DNSの設定を変更してアプリケーションに対する全てのリクエストを受け付けるようにします。

図1B　OpenIG導入後

　ユーザーがアプリケーションにアクセスしようとすると、実際にはOpenIGがリクエストを受信します。認証が必要な場合はOpenAMに依頼し、そうでなければアプリケーションへそのままリクエストを転送します。

注1：正確には、OpenIGと同一サーバー上にOpenAM Policy Agentと呼ばれるソフトウェアもインストールします。Policy AgentはOpenIGに対するリクエストをインターセプトして、必要に応じてOpenAMにユーザー認証を要求します。シーケンスが若干複雑になるため、今回の説明では省略していますが、「OpenIG」としている部分には「Policy Agent」も含まれていると考えてください。

　ユーザーがアプリケーションの任意の画面にアクセスしようとしてから、SSOが完了するまでの詳細なシーケンスは以下のようになります。

図2　OpenIGによる代理認証のシーケンス

　まず、ユーザーがアプリケーションの画面Aにアクセスすると（1）、アプリケーション本体ではなく、OpenIGがこのリクエストを受け付けます。この時点ではまだOpenAMにログインしていない状態なので、有効なセッションを検出できず、OpenAMのログイン画面にユーザーをリダイレクトします（2）。

　OpenAMはユーザーにログイン画面を表示し（3）、ユーザーはIDとパスワードを入力してログインします（4）。認証が成功すると、OpenAMはユーザーをアプリケーション（OpenIG）にリダイレクトします。OpenIGはリクエストを受信した際に有効なセッションを検出し、リクエストをそのままアプリケーションに転送します（5）。

　アプリケーションは、ローカルのセッションを検出できないため、アプリケーションのログイン画面にユーザーをリダイレクトします（6）。OpenIGは、そのレスポンスを検査し、ログインページであると判断すると（7）、セッションに一時的に保持していたIDとパスワードを入力した状態のログインフォームを作成し、アプリケーションにログインリクエストをポストします（8）。アプリケーションは認証情報を検証し、ユーザーを画面Aにリダイレクトします（9）。アプリケーションはユーザーに画面Aを表示します（10）。

　以上でアプリケーションへのSSOが完了しました。この一連の流れによってOpenAMに対してもログイン済みの状態となっているため、ユーザーが別のアプリケーションにアクセスしたときでも、再度ログインを要求されることなく、すぐにそのアプリケーションを利用できます。

　このようにOpenIGはアプリケーションへのログインをエミュレートすることで、各アプリケーションに対して何らかの修正を加えたり、エージェントのようなアプリケーションをインストールしたりしなくてもSSOを実現できます。

OpenIGによるフェデレーションゲートウェイの実現

　OpenIGのような代理認証を実現するソフトウェアは、国内の幾つかのベンダーによっても提供されています。それらと最も異なっている部分が、SAML 2.0^（注2）のフェデレーションゲートウェイとして機能する点です。この機能により、OpenIGはSAML未対応の複数のアプリケーションをまとめるSP（Service Provider）となり、IdP（Identity Provider）に認証・認可を委譲できます。

注2：SAML 2.0はHTTPにユーザーの属性や認証・認可に関する情報を含めてサーバー間で通信することで、SSOを実現するためのプロトコルです。SAMLの仕様において、サービスを提供するサーバーをSP（Service Provider）、認証やユーザー属性を提供するサーバーをIdP（Identity Provider）といいます。

例えば、SAMLを使うことで、IdPであるOpenAMにログインして、SPであるSalesforceの機能を利用するといったことができます。

　図3は、SAML未対応アプリケーションに対して、OpenIGとOpenAMを連携してSAML 2.0を使用したSSOをする際のシーケンスを表しています。

図3　OpenIGとOpenAMによるSP Initiated SSO

　この場合、SAML 2.0のIdPがOpenAMで、SPがOpenIGとなります。

OpenIGの構成例

　OpenIGを導入したシステムの構成例を以下に示します。

図4　OpenAMとOpenIGの構成例

　このように、社内にある全てのアプリケーションはOpenIGによって代理認証できるようになります。さらにSAML 2.0サービスを有効にすると、OpenIGはSAML 2.0のSPとして、Google AppsなどのクラウドサービスとともにSAMLのトラストサークルの構成要素となり、SSOが実現できます。

　OpenIGを導入する上で特に注意すべきことは、性能面の影響です。OpenIGはアプリケーションに対する全てのリクエストの通過点となるため、連携するアプリケーションが多ければ多いほど負荷が集中し、性能面に影響が出る可能性があります。この点については設計の段階で十分な検討が必要です。