OpenIG、OpenDJと連携したOpenAMの新機能：OSSによるアイデンティティ管理（3）（1/2 ページ）
今回は、OpenAMの姉妹製品で既存アプリケーションを改修せずにシングルサインオンを可能にする「OpenIG」と、OpenAMのデフォルトデータストアである「OpenDJ」について解説します。
アイデンティティ管理を取り巻く課題について説明した第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を実現する目的で導入します。
これらのアプリケーションの前段にOpenAMとともに配置し（注1）、DNSの設定を変更してアプリケーションに対する全てのリクエストを受け付けるようにします。
ユーザーがアプリケーションにアクセスしようとすると、実際にはOpenIGがリクエストを受信します。認証が必要な場合はOpenAMに依頼し、そうでなければアプリケーションへそのままリクエストを転送します。
注1：正確には、OpenIGと同一サーバー上にOpenAM Policy Agentと呼ばれるソフトウェアもインストールします。Policy AgentはOpenIGに対するリクエストをインターセプトして、必要に応じてOpenAMにユーザー認証を要求します。シーケンスが若干複雑になるため、今回の説明では省略していますが、「OpenIG」としている部分には「Policy Agent」も含まれていると考えてください。
ユーザーがアプリケーションの任意の画面にアクセスしようとしてから、SSOが完了するまでの詳細なシーケンスは以下のようになります。
まず、ユーザーがアプリケーションの画面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をする際のシーケンスを表しています。
この場合、SAML 2.0のIdPがOpenAMで、SPがOpenIGとなります。
OpenIGの構成例
OpenIGを導入したシステムの構成例を以下に示します。
このように、社内にある全てのアプリケーションはOpenIGによって代理認証できるようになります。さらにSAML 2.0サービスを有効にすると、OpenIGはSAML 2.0のSPとして、Google AppsなどのクラウドサービスとともにSAMLのトラストサークルの構成要素となり、SSOが実現できます。
OpenIGを導入する上で特に注意すべきことは、性能面の影響です。OpenIGはアプリケーションに対する全てのリクエストの通過点となるため、連携するアプリケーションが多ければ多いほど負荷が集中し、性能面に影響が出る可能性があります。この点については設計の段階で十分な検討が必要です。
Copyright © ITmedia, Inc. All Rights Reserved.