|
| |
| Sun Java System Identity Server 2004Q2 配備計画ガイド | |
第 3 章
Identity Server のアーキテクチャSun JavaTM System Identity Server には、アイデンティティオブジェクト、ポリシー、およびサービスの管理用インタフェースが用意されています。この章では、これらのインタフェースについて、製品のコアアーキテクチャとの関連を示しながら説明します。また、必要に応じて、サービスのアーキテクチャ上の詳細についても説明します。次の節で構成されています。
概要Identity Server は、JavaTM 2 Platform, Enterprise Edition (J2EE) プラットフォーム上に構築されており、サービスを提供するサーブレット、Web サービスエンドポイント、および Web アプリケーションを操作するためのインフラストラクチャとして Web コンテナを使用します。提供される各サービスは、Web サービスとして実装されます。Web サービスは、現在注目を集めている標準技術セットを使用して構築され、ネットワーク上で集中的に提供されます。
これらのサービスを企業間で実装するため、Identity Server はアイデンティティ関連のオブジェクト、ポリシー、およびサービスの管理用インタフェースを提供します。主なインタフェースには、多様な Web サーバーおよびアプリケーションサーバーにセキュリティを提供するポリシーエージェント、JavaTM および C アプリケーションプログラミングインタフェース (API)、XML (eXtensible Markup Language) ファイル、JavaServer PagesTM、HTML (HyperText Markup Language) ページ、コマンド行インタフェース (CLI)、およびグラフィカルユーザーインタフェース (Identity Server コンソール) が含まれます。これらのインタフェースを使用することで、Sun Java System Directory Server 内のアイデンティティ情報の管理が可能になります。また、SSO、認証、ポリシーベースの承認、およびログ機能を企業規模のアプリケーションにまで拡張することも可能になります。
図 3-1 に、Identity Server 2004Q2 の機能アーキテクチャ、および異なるコンポーネントが相互にやり取りを行う方法を示します。
図 3-1 Identity Server 2004Q2 の機能アーキテクチャ
これらのコンポーネントに固有の個別サービスの詳細は、『Identity Server 2004Q2 Developer's Guide』を参照してください。次の「統合化ポイント」では、一部のコンポーネントが相互にやり取りを行う方法について説明します。
統合化ポイントIdentity Server は、さまざまな統合化ポイントを利用してサービスの提供を行う分散型システムです。「統合化ポイント」とは、アプリケーションがサードパーティ製のシステムやソフトウェアとの円滑な対話処理を可能にするコネクタのことです。Identity Server の主要な統合化ポイントは、ポリシーエージェントおよび SDK (ソフトウェア開発キット) です。
ポリシーエージェント
Identity Server 内のアクセス制御は、ポリシーエージェントを使用して行われます。ポリシーエージェントは、指定された Web、アプリケーション、またはプロキシサーバーを不正な侵入から保護します。ポリシーエージェントは、Identity Server とは個別に提供されます。最新の Sun Java System Identity Server ポリシーエージェントは、Sun Microsystems Download Center からダウンロードできます。ポリシーエージェントは、Web およびプロキシサーバー上のリソースを保護するものと、さまざまな配備コンテナ内の J2EE アプリケーションを保護するものの 2 つに分類できます。
Web およびプロキシサーバーエージェント
Web サーバーおよびプロキシサーバーのポリシーエージェントは、対象のサーバーに配備されたコンテンツを不正侵入から保護します。エージェントは、管理者が設定したポリシーに基づいて、多数のサービスおよび Web リソースへのアクセスを制御します。ユーザーが、ブラウザで、保護された Web サーバー上の URL を指定すると、エージェントは要求を遮断し、ユーザーのセッショントークンが存在する場合にはそれを検証します。トークンの認証レベルが不十分であるか存在しない場合、ログインページに適切な認証サービスが呼び出されて、認証を (さらに) 行うようユーザーに求めます。認証サービスは、ユーザーの証明情報の有効性を検証します (たとえば、LDAP サービスは、ユーザー名およびパスワードが Sun Java System Directory Server に格納されているかどうかを検証する)。ユーザーの証明情報が正しく認証されている場合、ポリシーエージェントはユーザーに割り当てられているすべてのロール (ポリシーを含む) を確認します。ユーザーに割り当てられたすべてのポリシーを集約して、URL へのアクセスを許可するか拒否するかが個別に決定されます。
J2EE エージェント
Identity Server は、さまざまな配備コンテナ内の J2EE アプリケーションを保護するエージェントを提供します。これらのアプリケーションには、IBM Lotus DominoTM などのサーバーや、PeopleSoft などの企業が提供するアプリケーションが含まれます。通常、J2EE エージェントは、エージェントフィルタとエージェントレルムという 2 つのコンポーネントで構成されます (ただし、配備コンテナにより公開およびサポートされるインタフェースに部分的に左右される)。前者は認証を処理し、後者は承認を処理します。
エージェントフィルタ
エージェントフィルタは、サーバー内部に向かう要求を遮断するサーブレットフィルタです。これは、要求にセッショントークンが含まれるかどうかをチェックします。利用可能なセッショントークンが存在する場合、エージェントフィルタは Identity Server セッションサービスを使用してトークンを検証します。利用可能なトークンが存在しない場合、ユーザーは、通常の SSO 交換の場合のように認証サービスにリダイレクトされます。認証されたユーザーは、サーバーに再度導かれます。エージェントフィルタはそこで要求を再び遮断し、新たに取得したトークンを検証します。検証後に、フィルタはコンテナの主体およびレルムをインスタンス化します。要求は許可され、フィルタを通過してアプリケーションにアクセスすることが可能になります。このメカニズムを通して、エージェントフィルタは、有効な Identity Server トークンを保持する要求だけが、保護されたアプリケーションへのアクセスを許可されることを保証します。
エージェントレルム
エージェントレルムは、承認コンポーネントを提供します。「レルム」とは、J2EE 準拠のアプリケーションサーバーが、ユーザー、グループ、配備済みアプリケーションへのアクセス制御に関する情報を提供する手段です。これは、セキュリティポリシーが定義および施行される範囲を指します。リソースへのアクセスが試みられた場合、サーバーは、特定のレルムを使用してユーザーおよびそのロールを検証するように設定されます。デフォルトでは、多数のアプリケーションサーバーが、出荷時にレルムを実装しています。これには、デフォルトの File Based に加え、LDAP、NT、UNIX、および RDBMS (Relational Database Management System) が含まれます。エージェントレルムは、サーバーのレルムインタフェースを実装します。Identity Server を配備することでユーザーおよびロール情報の管理が可能になります。エージェントレルムを使用すると、エージェントフィルタにより認証されたユーザーに対し、ロールベースの J2EE リソースの承認をきめ細かく提供できます。
注
詳細は、『Sun Java System Identity Server Web Policy Agents Guide』または『Sun Java System Identity Server J2EE Policy Agents Guide』を参照してください。
Identity Server SDK
Identity Server 内部のアプリケーションを統合する別の方法は、SDK を使用してプログラム上で行う方法です。SDK アクセスは、主に Java で提供されます。いくつかの機能は C インタフェースで提供されます。XML over HTTP(s) 経由で Identity Server サービスとのインタフェースを直接提供することも可能です。ただし、ドキュメント形式は今後のリリースで変更される可能性があります。Identity Server の将来のバージョンでは、WSDL (Web Service Defintion Language) により定義されたエンドポイントとの Web サービスインタフェースが正式にサポートされる予定です。現在提供されている SDK は、次のとおりです。
アイデンティティ管理 SDK
基盤となる Directory Server で使用されるデータモデリングが記述された Identity Server テンプレートと、アイデンティティ管理 SDK を組み合わせて使用することで、ユーザー、ロール、グループ、コンテナ、組織、組織単位、およびサブ組織の作成および管理用フレームワークが提供されます。これにより、LDAP クライアント API よりもはるかに高い抽象化レベルでインタフェースが提供されるため、ディレクトリベースのアイデンティティ情報の管理が簡略化されます。ここで、コアパッケージは、Directory Server に対して直接動作する com.iplanet.am.sdk、および JAX-RPC 経由で Identity Server に対してリモートに動作することで Directory Server 自体に対して機能する com.sun.identity.um です (これは、am_services.jar の一部)。最後に、データの検証、パスワードポリシーの施行などのタスクに対応した、コア SDK のプラグイン作成用の SPI が提供されます。
サービス管理 SDK
開発者は、サービス管理インタフェースを使用してサービス定義を登録できます。サービス定義は、アプリケーション設定データの管理に使用されます。API パッケージ名は、com.sun.identity.sm です。
認証 API と認証 SPI
Identity Server では、プログラムによる Identity Server への認証を可能にする JAAS 実装が提供されます。これにより、認証サービスのすべての機能にリモートからアクセスできます。また、JAAS PAM 仕様に準拠した認証 SPI により、新規認証タイプの作成が可能になります。
ユーティリティ API
この API は、システムリソースの管理に使用できるいくつかの Java クラスを提供します。これには、スレッド管理やデバッグデータ形式などがあります。Java パッケージ名は com.iplanet.am.util です。現在 C インタフェースとの互換性はありません。
ログ API とログ SPI
ログサービスの主なタスクは、アクセス許可、アクセス拒否、およびユーザーアクティビティの記録です。ログ API を使用して、外部 Java アプリケーションのログ作成を有効にし、統合化された任意のアプリケーションに共通ログ機能を提供できます。ログ SPI を使用して、カスタマイズされた機能に対応したプラグインを開発できます。
クライアントディテクション API
Identity Server は、リソースにアクセスを試みているクライアントブラウザのタイプを検出して、適切に書式設定されたページを使って応答できます。この目的で使用する API パッケージは、com.iplanet.services.cdm です。このパッケージは、am_services.jar の一部です。
SSO API
Identity Server では、セッショントークンの検証および管理用インタフェース、およびユーザーの認証証明情報の管理用インタフェースが提供されます。SSO ソリューションへの参加を希望するアプリケーションはすべて、この API を使用できます。パッケージ名は com.iplanet.sso です。
ポリシー API
ポリシー API を使用することで、Identity Server ポリシーの評価と管理、およびポリシーサービスの追加機能の提供が可能になります。ポリシーストアからポリシーを直接読み込んで解釈するポリシーエバリュエータ、および JAX-RPC (Java API for XML-based Remote Procedure Calls) を使用して Identity Server のクライアントとして動作するリモートポリシーエバリュエータが提供されます。この API は、アイデンティティがアクセスするリソースを判別する機能も提供します。
SAML SDK
Identity Server は、SAML API を使用して認証動作、認証決定、および属性情報の交換を行います。API パッケージ名は、com.sun.identity.saml で始まります。このパッケージは、am_services.jar の一部です。
連携管理 API
Identity Server では、連携管理 API を使用して、Liberty Alliance Project 仕様に基づく機能が追加されます。API パッケージ名は、com.sun.liberty です。このパッケージは、am_services.jar の一部です。
詳細については、『Identity Server 2004Q2 Federation Management Guide』を参照してください。
機能プロセスIdentity Server には、統合化された多数の機能が含まれます。以下にその内容を示します。
統合化されたプロセスについては、次の節で説明します。プログラムに関連するポイントの詳細は、『Identity Server 2004Q2 Developer's Guide』を参照してください。
認証とユーザーセッション
認証サービスは、Identity Server のエントリポイントです。ユーザーは、Identity Server コンソールおよび対応する管理機能にアクセスする前に、認証プロセスに合格しなければなりません。Identity Server により保護されたサービスまたはアプリケーションへのアクセスを試みるユーザーは、アクセス許可の前にも認証が必要になります。認証サービスは、認証モジュールを呼び出して、必要な証明情報を収集および検証します。Identity Server は、アプリケーションによるシングルサインオン機能への参加を可能にする API も提供します。シングルサインオン機能を利用すると、ユーザーは一度の認証で複数のリソースにアクセスできるようになります。
Identity Server への認証には、2 つの方法があります。1 つは、管理者またはエンドユーザーが管理目的で Identity Server コンソール自体へのアクセスを試み、認証サービスにリダイレクトされる方法です。もう 1 つは、ユーザーが Identity Server により保護されたアプリケーションへのアクセスを試みて認証サービスにリダイレクトされる方法です。前者では HTML over HTTP(S) インタフェースを使用し、後者では C ベースの API または Java API を使用します。
注
3 番目のオプションは、ユーザーがリモートサーバーマシンの保護されたリソースへのアクセスを試みる場合です。このオプションには、Identity Server ポリシーエージェントのインストールが含まれます。詳細は、「ポリシーの統合」を参照してください。
HTML over HTTP(S) インタフェース
通常の Web ベースのシナリオでは、管理目的で Identity Server を起動する管理者またはエンドユーザーが、Web ブラウザに認証サービスの URI を入力して、 認証ユーザーインタフェース Java サーブレットにアクセスします。
URI は、1 つ以上の認証モジュールを定義する認証プロセスに対して事前に設定されます。サーブレットは URI をパースし、セッションサービスと通信を行い (セッションサービスは無効な状態のセッショントークンを作成する)、トークンを Cookie に埋め込みます。認証 SPI (com.sun.identity.authentication.spi) は特定の認証モジュールを呼び出して、ログインページおよびトークン/Cookie を要求元のブラウザに渡します。ユーザーは証明情報を入力し、認証 SPI は情報を認証サービスに返します。認証サービスは、情報を対応するデータストア内の情報と比較して検証します。要求された認証プロセスがすべて完了および成功すると、ユーザーのポリシー (URL アクセスおよび拒否リストを含む)、認証レベル、および設定パラメータがセッションサービスに渡されます。セッションサービスは、トークンを有効な状態に設定します。(セッション情報はトークンに埋め込まれず、サーバーに格納される。トークンは情報へのポインタに過ぎない)。最後に、URL パラメータを使用してユーザーが適切なリソースに導かれます。
XML over HTTP(S) インタフェース
Java と C アプリケーションの両方で、認証 API を使用して Identity Server からユーザー認証を要求できます。Java パッケージ com.sun.identity.authentication は、認証プロセスを開始し、未検証の認証証明情報をアプリケーションから認証サービスに送り返すためのインタフェースを提供します。
注
com.sun.identity.authentication は、ローカルとリモートのどちらでも実装できます。リモートの場合、開発者はこのパッケージから取得したクラスおよびメソッドを Java アプリケーションに統合します。
Java コールは XML メッセージに変換されて、HTTP(S) 経由で Identity Server に渡されます。受信後に、XML メッセージは Java に再度変換され、認証サービスにより解釈されます。C アプリケーション開発者も同じ手順に従いますが、最初に Identity Server との通信を行います。
接続のオープン後に C アプリケーションが有効になり、認証要求を XML メッセージとして HTTP(S) 経由で Identity Server に送信します。受信時に、XML メッセージが再度 Java に変換され、認証サービスによりパースされます。認証サービスは、認証メソッドを判別して、セッションサービスと通信を行います。セッションサービスは、無効な状態のセッショントークンを作成し、トークンを Cookie に埋め込みます。認証 SPI (com.sun.identity. authentication.spi) は特定の認証モジュールを呼び出して、ログインページおよびトークン/Cookie を要求元のアプリケーションに渡します。ユーザーは証明情報を入力し、認証 SPI は情報を Identity Server に返します。Identity Server は、情報を対応する認証データストア内の情報と比較して検証します。要求された認証プロセスがすべて完了および成功すると、ユーザーのポリシー (URL アクセスおよび拒否リストを含む)、認証レベル、および設定パラメータがセッションサービスに渡されます。セッションサービスは、情報をセッショントークンに埋め込んで、有効な状態に設定します。最後に、要求元にアプリケーションへのアクセスが許可されます。
ポリシーの統合
Identity Server 配備内部の認証とシングルサインオンはどちらも相互依存の関係にあります。このため、認証が成功した後、ユーザーがセッショントークンを保持していない場合には、ユーザーができることはあまりありません。ポリシーサービスには、同様の相互依存性が存在します。ユーザーのポリシーにより配備内部の保護されたリソースに関する権限が定義されるため、Identity Server なしでは、定義済みのポリシーに関して多くを行うことはできません。この機能は、Identity Server により保護されたリソースを格納するリモートマシンの Web サーバーにインストールされたポリシーエージェントを使用して管理されます。
注
最新のポリシーエージェントは、http://wwws.sun.com/software/download/inter_ecom.html の Sun Microsystems Download Center 内の「Web And Directory Servers」ページからダウンロードできます。
ユーザーがポリシーエージェントにより保護された Web サーバーに接続すると、エージェントは要求を遮断して Cookie に埋め込まれたセッショントークンをチェックします。トークン/Cookie が見つからない場合、エージェントはユーザーをこのエージェント用に設定されたログイン URL にリダイレクトして認証プロセスを開始し、セッショントークンを作成します。ここから、「認証とユーザーセッション」に記載された手順に従って処理が行われます。ユーザーは、有効なセッショントークンを受信すると、最初に要求したリソースに再び導かれます。そこで、エージェントにより要求が再度遮断され、セッショントークンがチェックされます。セッショントークンを検出したエージェントは、新規トークンを検証し、要求がネーミングサービスに渡されてトークンが復号化され、特定のセッションサービスが転送されて検証が行われるようにする必要があります。エージェントは、応答を受信してセッションサービスの URL を抽出し、その URL にアクセスしてトークンの検証を行います。セッションサービスは、応答をエージェントに返してトークンを検証します。エージェントは、何らかの理由でセッションがタイムアウトするか無効になった場合、セッションサービスが通知を受け取ることを要求します。セッションサービスは、肯定的な応答を返します。ユーザーの定義したポリシーを取得するため、エージェントはポリシーサービスと通信できるようになります。ポリシーサービスにより、決定が返されます。次に、エージェントはこの決定を使用して、要求されたリソースへのアクセスを許可または拒否します。また、ログメッセージがログサービスに送信されます。
クライアントディテクションの統合
ユーザーを認証する最初のステップは、要求元のクライアントタイプを識別することです。認証サービスは、URL 情報を使用してブラウザタイプの特性を取得します。これらの特性に基づいて、適正な認証ページ (HTML ページなど) がクライアントブラウザに送信されます。ユーザーの検証後に、クライアントタイプがセッショントークンに追加されます。セッショントークンを使用することで、他のサービスからもクライアントタイプを取得できるようになります。クライアントディテクションの詳細は、『Sun Java System Identity Server Developer's Guide』のクライアントディレクションに関する章を参照してください。
CDSSO、SAML、および連携
CDSSO (Cross-Domain Single Sign-on)、SAML (Security Assertion Markup Language) サービス、および連携管理は、Identity Server の別個の機能です。どの機能も、手法は異なりますが提供する機能は同じです。CDSSO は、複数の DNS ドメイン間でシングルサインオンを可能にする Identity Server 独自の機能です。既存の配備に SAML 仕様が実装されている組織では、同様の目的 (クロスドメインのシングルサインオン) で SAML サービスを使用できます。連携管理では、連携アイデンティティ管理に Liberty Alliance Project バージョン 1.1 仕様が使用されます。連携管理を使用することで、接続されたパートナーのネットワーク経由でのサインオンの簡略化や、個人のアイデンティティの使用および公開などのユーザー制御が可能になります。
CDSSO
CDSSO は、Identity Server 認証および承認プロセスの設定可能な部分です。これには、「認証とユーザーセッション」で説明したポリシーエージェントのインストールおよび設定が含まれます。詳細は、『Sun Java System Identity Server Developer's Guide』、『Sun Java System Identity Server Web Policy Agents Guide』、または『Sun Java System Identity Server J2EE Policy Agents Guide』のシングルサインオンに関する章を参照してください。
SAML
SAML サービスは、セキュリティ当局と信頼されるパートナー間のセキュリティ情報の交換に XML フレームワークを使用する、オープンな標準プロトコルに基づいています。Identity Server の内部アーキテクチャの詳細は、『Sun Java System Identity Server Developer's Guide』の SAML サービスに関する章を参照してください。
連携
連携管理を使用すると、認証ドメイン、ホストプロバイダ、およびリモートプロバイダを Identity Server コンソールから設定および管理できます。これにより、ユーザーが一度サインオンするだけで、他の任意の連携リソースにアクセスできるようになります。連携アーキテクチャの詳細は、『Sun Java System Identity Server Developer's Guide』の連携管理に関する章を参照してください。
Identity Serverの拡張Identity Server は、リモートの Web またはアプリケーションサーバー、Sun Java System Directory Proxy Server などの LDAP ロードバランサ、およびマルチマスターレプリケーション内に配備できます。インストールする前に、以下の製品が配備に適しているかどうかを確認してください。Identity Server をインストールする前に、これらの製品をインストールおよび設定することが必要な場合があります。
Web コンテナ
一部の Web コンテナは、Identity Server の配備先の Sun Java System Web Server (または他の Web コンテナ) に対してリモートの位置に存在します。リモートの Web コンテナが、組織のコンテンツページ用として配備済みである場合には、Web コンテナを追加する必要があります。コンテンツを保護するためにポリシーエージェントをインストールすると、リモートの Web コンテナは Identity Server 環境に統合されます。Web コンテナのインストールおよび管理の詳細は、サーバーに付属のマニュアルまたは Sun Java System Web Server のマニュアルを参照してください。
複数の Directory Server インスタンス
アップグレード、フェイルオーバーディレクトリの設定、マルチマスターの配備を行うために、Directory Server の複数インスタンスをインストールできます。Identity Server の配備を成功させるためには、Directory Server のインストール、設定、および配備を適切に行う必要があります。Identity Server をインストールする前に、データベースレプリケーションアグリーメントを定義する必要があります。Directory Server のインストールおよび配備に関する詳細は、『Directory Server 5 2004Q2 Installation and Migration Guide』および『Directory Server 5 2004Q2 配備計画ガイド』を参照してください。
LDAP ロードバランサ
Sun Java System Directory Proxy Server などのロードバランサと連携して動作するように、Identity Server を設定できます。Identity Server のパフォーマンスと応答時間を改善するには、レプリケートされたサーバー間でロードバランスを行う方法と、ユーザー付近に配置されているレプリケートされたサーバーの位置を検出する方法の 2 つの方法があります。ロードバランサを使用することで、Identity Server の基本機能に、高可用性レイヤーおよびディレクトリフェイルオーバー保護を追加できます。バックエンドの LDAP サーバーが一切利用できない場合、ロードバランサは要求トラフィックを管理し、クライアントのクエリを拒否します。インストールおよび管理の詳細は、Sun Java System Directory Proxy Server 5.2 のマニュアルを参照してください。ロードバランサに関するその他の情報については、製品に付属のマニュアルを参照してください。
