検索
連載

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

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

Share
Tweet
LINE
Hatena
「OSSによるアイデンティティ管理」のインデックス

連載目次

 アイデンティティ管理を取り巻く課題について説明した第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はアプリケーションに対する全てのリクエストの通過点となるため、連携するアプリケーションが多ければ多いほど負荷が集中し、性能面に影響が出る可能性があります。この点については設計の段階で十分な検討が必要です。

       | 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る