| Oracle Identity Federation管理者ガイド 10g（10.1.4.0.1） B31476-02 |
|
 戻る |
 次へ |
この章では、インストール・オプションをよく理解できるように、Oracle Identity Federationのデプロイメントに関する考慮事項を説明します。内容は次のとおりです。
Oracle Identity Federationのデプロイメントを計画する場合、サーバー・アーキテクチャ、運用環境、およびフェデレーテッド交換ネットワークでサーバーが持つロールについて把握する必要があります。この項では、Oracle Identity Federationのデプロイメントにおけるアーキテクチャについて、次のような事項を概説します。
前述したとおり、フェデレーテッド・ネットワークでのOracle Identity Federationのインスタンスは、アイデンティティ・プロバイダとサービス・プロバイダのいずれか、または両方として動作できます。
アイデンティティ・プロバイダ・ロール
フェデレーテッド・ネットワーク内の保護されたリソースにアクセスする場合、サービス・プロバイダはユーザーをOracle Identity Federationにリダイレクトし、Oracle Identity Federationが認証のIdPとして動作します。Oracle Identity Federationは認証エンジンと連携し、資格証明を取得してユーザーを認証します。これでOracle Identity Federationはユーザーのアイデンティティをリソース（SP）に対して宣言することができます。SPは、ユーザーをログインさせ、リクエストされたアプリケーションを提供します。
サービス・プロバイダ・ロール
ユーザーがOracle Application Server Single Sign-Onなどの認証エンジンによって保護されたリソースにアクセスしようとすると、Oracle Identity Federationにリダイレクトされます。SPロールでは、ユーザーはOracle Identity Federationにより、グローバル認証のために、ポータルなどのアイデンティティ・プロバイダにリダイレクトされます。これでIdPポータルは資格証明を入手し、ユーザーを認証してOracle Identity Federationにリダイレクトすることができます。Oracle Identity Federationは、宣言されたアイデンティティをIdPから取得します。Oracle Identity Federationは（認証された）ユーザーを認証エンジンにリダイレクトし、認証エンジンが保護されたリソースへのアクセスを許可します。
Oracle Identity Federationは、次の2つのうちいずれかのネットワーク構成でインストールできます。
ハブ・アンド・スポーク・ネットワークでは、複数のソース（アイデンティティ・プロバイダ）が1つの宛先（サービス・プロバイダ）と通信します。
図2-1は、企業Dが企業A、B、CおよびEの接続先となっているハブ・アンド・スポーク・ネットワークを示しています。企業Dは金融サービスなどのリソースを提供し、他の企業の従業員はそこにアクセスする必要があります。
|
注意: ハブ・アンド・スポークは、ソース（IdP）または宛先（SP）が、ハブまたはスポークのいずれとしても動作することができるトポロジです。このため、図2-1のロールは、逆にIdPのハブとSPのスポークで構成されるネットワークを表したものと見ることもできます。 |
ピアツーピア・ネットワークでは、複数のドメインがハブとして動作します。
図2-2は、企業Aが企業BとCのサービス・プロバイダであり、企業Cが企業DとEのサービス・プロバイダであるピアツーピア・ネットワークを示しています。このため、企業Cは、アイデンティティ・プロバイダとサービス・プロバイダの両方として動作しています。企業Eは、企業AとCでサービスを消費するユーザーのアイデンティティ・プロバイダとして動作します。
DMZにどのコンポーネントを置くか、プロキシ・サーバーを使用するかどうかを決定する必要があります。Oracle Identity Federationをファイアウォールの背後に置いた場合、プロキシがリクエストとレスポンスをフェデレーション・サーバーに転送することによって、インターネットなどの外部ネットワークからサーバーへの透過的なアクセスを可能にする必要があります。
Oracle Identity Federationの構成は、実装するプロファイルの種類により異なります。
SPのDMZに置いたプロキシを使用するPOSTプロファイル
POSTプロファイルはHTTPS経由でSPにアサーション全体を送信します。IdPとSPはどちらも、SSLポートを経由して通信するように構成されています。本番環境でPOSTプロファイルを使用する場合、SPはDMZにあるプロキシ・サーバーを使用します。
IdPおよびSPのDMZに置いたプロキシを使用するアーティファクト・プロファイル
ブラウザ・アーティファクト・プロファイルを使用する場合、IdPは実際のアサーションでなく、アーティファクト（識別子）を送信します。SPはアーティファクトを受信し、その後でアサーション全体をリクエストします。
プロキシの使用を選択する場合は、このプロファイルを使用するためにはIdPとSPの両方のプロキシを使用する必要があることに注意してください。プロキシは、アーティファクト、アサーション・リクエストおよびアサーションを処理し、それらのオブジェクトをそれぞれのプロバイダに転送する、受信者およびレスポンダ・サービスとして機能します。
Oracle Identity Federationは、次を使用することによってセキュアな通信を提供します。
Oracle Identity Federationは、パートナ・ドメイン相互の間にセキュアなSSL通信を提供します。SSL暗号化は、インストール時にサーバー・インスタンスごとに有効または無効にできるオプションです。
|
注意: SSLおよび関連のシステム・セキュリティに関する説明は、『Oracle Application Serverセキュリティ・ガイド』を参照してください。 |
初回の設定とテストでは、アイデンティティ・プロバイダおよびサービス・プロバイダはデフォルトの自己署名証明書を使用できます。しかし、本番に移行する前に、インストールされたプロバイダがサード・パーティのCA証明書を使用するように設定されていることを確認する場合があります。
Oracle Identity Federationには、信頼できるCAのリストと証明書失効リスト（CRL）を格納できるリポジトリがあります。
サーバーで証明書が有効になっている場合は、Oracle Identity Federationにより、Liberty 1.1、Liberty 1.2およびSAML 2.0の各プロトコルで、着信するシグネチャを検証するために使用されているすべての証明書が検証されます。
証明書を検証する際、サーバーは証明書または信頼できる証明書とみなせるその発行者を見つけようと試み、証明書がCRLにないことを確認します。
この項では、プロファイルとバインディングを説明します。内容は次のとおりです。
フェデレーション・サーバーのインスタンスがサポートするプロトコルを選択したら、実装するプロトコル・プロファイルと転送バインディングを選択する必要があります。
表2-1と表2-2は、Oracle ID Federationインスタンスで有効化できる、サポート対象のプロトコル・プロファイルとセキュリティ転送バインディングの組合せのリストを示しています。
表2-1 Liberty 1.xとSAML 2.0の場合のOracle Identity Federationのプロファイルおよびバインディング
| 機能 | プロファイル/バインディング | Liberty 1.1 | Liberty 1.2 | SAML 2.0 |
|---|---|---|---|---|
|
シングル・サインオン |
アーティファクト |
x |
x |
x |
|
シングル・サインオン |
HTTP Post |
x |
x |
x |
|
ログアウト |
HTTPリダイレクト |
x |
x |
x |
|
ログアウト |
HTTP Post |
x |
||
|
NameID登録 |
HTTPリダイレクト |
x |
x |
x |
|
NameID登録 |
HTTP Post |
x |
||
|
NameID登録 |
SOAP |
x |
x |
x |
|
フェデレーション終了 |
HTTPリダイレクト |
x |
x |
x |
|
フェデレーション終了 |
HTTP Post |
x |
||
|
フェデレーション終了 |
SOAP |
x |
x |
x |
|
属性取得 |
SOAP |
x |
SAMLとLibertyプロトコルの下では、プロバイダがアーティファクト・プロファイルまたはPOSTプロファイルを使用してOracle Identity Federationアサーションを交換するかどうかを指定できます。これらのプロファイルは、アサーションを安全に交換するための方法の違いを表しています。
この項では、次の内容を説明します。
アーティファクト・プロファイルを考慮する場合には次のことを検討してください。
アーティファクト・プロファイルは、XML署名を使用するPOSTプロファイルほどリソース集約的ではありません。
アイデンティティ・プロバイダのSAMLコンポーネントはDMZに置く必要があります。
アーティファクト・プロファイルのリクエスト処理
図2-3は、アーティファクト・プロファイルの下でリクエストが処理されるプロセスを示しています。
処理フローは次のような道筋をたどります。
ユーザーがOracle Identity Federation（IdPとして動作）でリクエストを実行します。
Oracle Identity Federationがユーザーを認証し、SPに認識されているIdPの識別子を含むアーティファクトを作成します。
送信されるメッセージは、検索用のキーとなるアーティファクトとともに、サーバーのリポジトリに格納されます。
|
注意: インストールにより異なりますが、リポジトリはメモリーとリレーショナル・データベースのどちらにも置けます。レプリケートされた高可用性Oracle Identity Federationサーバーを使用する場合、リポジトリはデータベースにある必要があります。 |
サーバーはユーザーを、そのアーティファクトを持つピア・サイトにリダイレクトします。アーティファクト・プロファイルは、メッセージを運ぶために使用されます。
ピア・サイトはアーティファクトをデコードし、Oracle Identity Federationが元のサイトであることを導き出します。
ピア・サイトはIdPのOracle Identity Federationと連絡を取り、アーティファクトを送信して、サーバーにそれを間接参照するように求めます。
Oracle Identity Federationは、アーティファクトを使用してリポジトリからメッセージを取得します。
Oracle Identity Federationが処理のためにピア・サイトにメッセージを送信します。
|
注意: この使用例は、IdPが開始したシングル・サインオンを解説したものです。リクエストがSPによって開始された場合は、ユーザーはサービス・プロバイダで直接リソースをリクエストします。 |
ユーザー・エントリやユーザー・フェデレーション・レコードと比べると、アーティファクト・オブジェクトは一時的なデータとみなすことができます。この一時的な性質のため、アーティファクトは持続時間が限定されており、一定の時間が経過するとリポジトリから削除されます。
プロキシを使用するアーティファクト・プロファイル
図2-4に示したように、アーティファクト・プロファイルを使用する場合、Oracle Identity Federationに、IdPサーバーやSPサーバーのプロキシを構成することができます。このセキュア環境で、プロキシはDMZにあります。
処理フローは次のとおりです。
ユーザーがOracle Identity Federation IdPサーバーでリクエストを発行します。
Oracle Identity Federationがユーザーを認証し、IdPサーバーの短い識別子を含むアーティファクトを作成します。サーバーは、アーティファクトを持つユーザーを、SPプロキシ・サーバー上の受信者サービスにリダイレクトします。
ユーザーのブラウザが、SPのDMZにあるプロキシ上のサービス・プロバイダの受信者サービスのURLに、アーティファクトを含んでいるリクエストを送信します。
プロキシはリクエストをOracle Identity Federation SPサーバーに転送します。
SPはIdPのDMZにあるプロキシ上のIdPのレスポンダ・サービスと連絡を取り、アーティファクトを送信して、IdPにそれを間接参照するように求めます。
プロキシはリクエストをIdPに転送します。
IdPはアーティファクトを使用してリポジトリからメッセージを取得し、SPに送信します。
SPサーバーはユーザー・セッションを作成し、ユーザーのブラウザを目的のリソースにリダイレクトします。
テスト目的で、開いているポートを経由して通信するようにピア・プロバイダを構成することができます。ただし、本番環境ではセキュアなSSLポートをお薦めします。また、IdPとSPの管理者は、各自のCA証明書を互いに交換してインストールしている必要があります。この証明書は、それぞれのフェデレーション・サーバーの間で交換されるリクエストとレスポンスを暗号化および復号化するために使用されます。
SAML POSTプロファイルを使用して、アイデンティティ・プロバイダはHTTPS経由でサービス・プロバイダにアサーション全体を送信します。テスト時に、プロキシを使用しないようにOracle Identity Federationを構成する場合があります。
|
注意: アサーションはHTTP経由でも送信できます。ただし、通信のセキュリティを確保するために、本番環境では常にHTTPSを使用することをお薦めします。 |
POSTプロファイルを考慮する場合には次のことを検討してください。
POSTプロファイルでは、IdPのSAMLコンポーネントをDMZに置く必要はありません。
SAMLコンポーネントはファイアウォールの背後に置くことができます。
POSTプロファイルにはXML署名の使用が必要です。また、署名と検証には大量のリソースが必要です。
多数のリクエストやレスポンスを送受信する計画がある場合のパフォーマンス上のヒントは、「サイジングのガイドライン」を参照してください。
POSTプロファイルのリクエスト処理
図2-5は、POSTプロファイルの下でリクエストが処理されるプロセスを示します。
処理フローは次のとおりです。
ユーザーがリクエストを開始します。認証されるまでリクエストを処理できません。
Oracle Identity Federationはアイデンティティ・プロバイダとして動作し、ユーザーを認証して、レスポンスを含むHTMLフォームを返します。このフォームは、IDアサーションと、サービス・プロバイダのURLで構成されます。レスポンスは、Oracle Identity FederationのIdPの秘密署名キーを使用して署名されます。
ブラウザは、このフォームをサービス・プロバイダの受信者サービスのURLにpostします。受信者サービスは、IdPの署名キーに関連付けられた公開証明書を使用して、署名されたレスポンスを検証します。
サービス・プロバイダはアサーションを抽出し、アサーションのためにユーザー・セッションを作成します。
サービス・プロバイダは、ユーザーのブラウザに、リクエストされたリソースへのリダイレクトを送信します。
ユーザーのブラウザは、サービス・プロバイダによって作成されたユーザー・セッション経由で、ターゲット・リソースにリクエストを送信します。
プロキシを使用するPOSTプロファイル
セキュアなデプロイメントでは、POSTプロファイルはSSL経由でサービス・プロバイダにアサーション全体を送信します。IdPとSPは、SSLポートを通るHTTPS経由で通信するように構成されます。図2-6は、本番でPOSTプロファイルを使用するための望ましい手法を示しています。Oracle Identity Federationは、DMZにあるSPとして動作しています。
処理フローは次のとおりです。
Oracle Identity FederationがIdPとして動作している状態で、ユーザーがリソースをリクエストします。SPであるOracle Identity Federationサーバーは、DMZにあるプロキシ・サーバー経由でアクセスされます。
IdPサーバーはユーザーを認証して、レスポンスとしてアサーションとターゲット・リソースのURLが含まれるHTMLフォームを送信します。
レスポンスは、Oracle Identity FederationのIdPの秘密署名キーを使用して署名されます。
ユーザーのブラウザは、SPのプロキシ受信者サービスURLにフォームをpostします。
プロキシはフォームをSPの受信者サービスに転送します。
Oracle Identity Federation SPは署名を検証してアサーションを抽出し、アサーションのためにユーザー・セッションを作成して、ユーザーのブラウザにリソースへのリダイレクトを送信します。
ブラウザは新規ユーザー・セッションを経由して、ターゲット・リソースにリクエストを送信します。リクエストはサービス・プロバイダのDMZにある追加のプロキシによって処理されることがあります。
SAMLは、SAMLメッセージとメッセージ交換のプライバシ、整合性、正統性および秘匿性を確保するために使用できる多数のセキュリティ機能があります。
この項では、メッセージのセキュリティに関する考慮事項の簡単な概要を説明します。セキュリティに関するリスクと対策の詳細な分析は、次の場所にある、「Security and Privacy Considerations for OASIS SAML V2.0」というタイトルの、OASIS SAMLセキュリティ関連考慮事項の仕様書を参照してください。
http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf
Oracle Identity Federationは、SAMLデプロイメントで使用できる一連のセキュリティ関連のテクノロジとテクニックをサポートしています。これには、次の内容が含まれます。
ピア認証とセキュアな通信のためのSSL/TLS
メッセージ・レベルの整合性と認証のためのXML-SIG
メッセージ・レベル機密保護のためのXML-ENC
メッセージ・レベルのセキュリティに加え、すべてのSAMLメッセージ・フローで、セキュアなSSL/TLSチャネルを使用することをお薦めします。アイデンティティ・プロバイダとサービス・プロバイダの間の通信はすべて、双方向認証（クライアント証明書とサーバー証明書）を使用する必要があります。
SAMLプロファイルは、通信プロトコルでSAMLアサーションとリクエスト/レスポンス・メッセージをセキュアに使用する方法に関する、具体的な推奨事項です。ここでは、SAML SSOのアーティファクト・プロファイルとPOSTプロファイルのセキュリティ要件を示します。
SAMLアーティファクト・プロファイルを使用するセキュアな通信
SAMLアーティファクト・プロファイルを使用するセキュアな通信には、次のことが必要です。
IdPからユーザーのブラウザへのリダイレクション、およびブラウザからSPへのリダイレクションでIdPがSPと通信する場合はSSLが必須です。
SPのリクエスタ・サービスには証明書が必要です。SAML 1.0/1.1では、SPリクエスタは、IdPに認識されているユーザー名とパスワードを使用したHTTP Basic認証を使用できます。
SAML POSTプロファイルを使用するセキュアな通信
SAML POSTプロファイルを使用するセキュアな通信には、次のことが必要です。
ブラウザからサービス・プロバイダへのユーザー・リクエストの転送にはセキュアHTTP（HTTPS）が必要です。
アイデンティティ・プロバイダは、サービス・プロバイダに送信するレスポンスに署名する際にはXML署名を使用する必要があります。
サービス・プロバイダはレスポンスのXML署名を検証する必要があります。
SAML属性共有プロファイルは、リソース・リクエストの認可を提供するために追加のユーザー属性が必要であるときに、サービス・プロバイダが、SAMLアサーションでなくSSLクライアントX.509証明書を使用してユーザーを認証するために使用されます。
Oracle Identity Federationは、Oracle Access Managerとともに使用してピア・サイトでのSAML2.0実装との相互運用を可能にするために、属性共有プロファイルを提供しています。コンポーネントとそのロールの詳細、およびOracle Identity FederationとOracle Access Managerの構成方法の詳細は、「属性共有の構成」を参照してください。
WS-Federationは、実際の認証を実行するアイデンティティ・プロバイダを使用して1つ以上のサービス・プロバイダにサインインするために使用できます。
ログアウトするには、WS-Federationサインアウトを開始するIdPサイトでリンクをクリックします。Oracle Identity Federationは、セッションCookieを使用して、ユーザーがサインインした各SPを追跡しています。サーバーはユーザーのブラウザにHTMLサインアウト・ページを返します。各SPはサインアウト・クリーンアップを処理し、Oracle Identity Federationのために作成されたセッションをサインアウトします。
Oracle Identity Federationの機能の多くは、ユーザーが認証されていることを必要とします。このような操作には、次のものがあります。
シングル・サインオン、フェデレーション作成、フェデレーション終了およびNameID登録などのIdPプロトコル操作
フェデレーション作成、フェデレーション終了およびNameID登録などのSPプロトコル操作
認証の効力について見通しを得るために、フェデレーション・サーバーを、次のような別個のモジュールを含むものとして考えることができます。
Oracle Identity FederationがLiberty 1.x、SAML 1.0/1.1およびSAML 2.0プロトコルをサポートします。
認証モジュールが、ユーザー認証およびIdMソリューションとの統合をサポートします。
この他、Oracle Access Managerは、Webシングル・サインオン、ユーザーのセルフサービスと登録、ポリシー管理および委任管理など、広汎なID管理機能を提供します。
この項では、様々な構成のこれらのモジュールにより可能になる認証フローを検討します。
Oracle Identity Federationの認証モジュールは、ユーザー認証で次の2つの別の役割を果すことができます。
認証モジュールはローカル認証メカニズムとして動作します。このモードでは、認証モジュールは使用可能な認証システムを使用してローカルに認証することができます。
Oracle Identity Federationは、認証モジュールに認証リクエストを伝えます。デプロイメントにより異なりますが、認証モジュールは、直接RDBMSまたはLDAPリポジトリと情報をやり取りすることも、Oracle Application Server Single Sign-OnなどのIdMソリューションに認証を委任することもあります。
Oracle Identity Federation認証モジュールは認証状態を伝播させるために動作します。このモードでは、サービス・プロバイダであるOracle Identity Federationが、フェデレーション・プロトコルを使用して、ユーザーがピアアイデンティティ・プロバイダで認証されるようにします。Oracle Identity Federationは次にユーザーを認証モジュールに転送します。このモジュールは、認証済ユーザー・セッションを、SPにデプロイされたIdMソリューションに伝播および作成します。これにより、リクエストされた保護リソースへのアクセスが順に可能になります。
|
注意: SPモードでは、IdMソリューションが存在する必要があります。ローカル認証IdPモードでは、そうしたソリューションは不要です。 |
このデプロイメントでは、認証モジュールが次のような多くのリポジトリおよびIdMソリューションと直接、情報をやり取りして、Oracle Identity FederationがIdPモードで認証できるようにします。
RDBMSリポジトリ
LDAPリポジトリ
Oracle Access Manager
CA eTrust SiteMinder
このようなデプロイメントに関わるローカル認証のフローは次のとおりです。
ユーザーがOracle Identity Federationにアクセスします（手順1）。
ローカル認証の場合、Oracle Identity Federationがユーザーを認証モジュールに転送します（手順3）。
認証モジュールは資格証明の入力をユーザーに求めます（手順6）。
ユーザーが資格証明に入ります（手順5）。
認証モジュールは、ユーザーを認証するためにリポジトリと情報をやり取りします（手順7）。
認証モジュールは、ユーザーをユーザーのIDとともにOracle Identity Federationに転送します（手順6、1）。
Oracle Identity Federationが認証されたユーザーと通信します（手順2）。
このデプロイメントでは、認証モジュールがOracleAS Single Sign-On IdMソリューションに認証を委任して、Oracle Identity FederationがIdPモードで認証できるようにします。
IdMデプロイメントに関わるローカル認証のフローは次のとおりです。
ユーザーがOracle Identity Federationにアクセスします（手順1）。
ローカル認証の場合、Oracle Identity Federationがユーザーを認証モジュールに転送します（手順2）。
認証のために、認証モジュールがユーザーをIdMサーバーにリダイレクトします（手順3、4）。
IdMサーバーはユーザーを認証し、ユーザーを認証モジュールにリダイレクトして戻します（手順5、6）。
認証モジュールは、ユーザーをユーザーのIDとともにOracle Identity Federationに転送します（手順7）。
Oracle Identity Federationが認証されたユーザーと通信します（手順8）。
このモードで、Oracle Identity Federationはフェデレーション・プロトコルを使用してユーザーを識別し、Oracle Access ManagerまたはCA eTrust SiteMinder上に認証済セッションを作成するように認証モジュールにリクエストします。これによりユーザーはリクエストされたリソースにアクセス可能になります。リクエストされたリソースは、WebGate（Oracle Access Manager IdMデプロイメント）またはCA eTrust SiteMinder Web Agent（CA eTrust SiteMinderデプロイメント）によって保護されています。
リクエストはピアIdPに発信され、Oracle Identity FederationはSPモードで認証します。
Oracle Access ManagerまたはCA eTrust SiteMinderを使用してピア・プロバイダでユーザーを認証するフローは次のとおりです。
ユーザーはピアIdPにいます（手順1）。
IdPはユーザーを認証アサーションとともに、SPであるOracle Identity Federationにリダイレクトします（手順2、3）。
Oracle Identity Federationがアサーションを処理し、ローカルのOracle Identity Federationセッションを作成して、ユーザーをIDとともに認証モジュールに転送します（手順4）。
認証モジュールはOracle Access Manager/CA eTrust SiteMinderサーバーと情報をやり取りし、Oracle Access Manager/CA eTrust SiteMinderの認証済セッションを作成します（手順5）。
認証モジュールがユーザーを保護されたリソースにリダイレクトします（手順6）。
WebGateまたはCA eTrust SiteMinder Webエージェントが、保護されたリソースへのアクセスをユーザーに許可します（手順7）。
このモードで、Oracle Identity Federationはフェデレーション・プロトコルを使用してユーザーを識別し、ユーザーがリクエストされたリソースにアクセスできるように、OracleAS Single Sign-Onに認証済セッションを作成するように認証モジュールにリクエストします。リクエストされたリソースはmod_ossoによって保護されています。
リクエストはピアIdPに発信され、Oracle Identity FederationはSPモードで認証します。
OracleAS Single Sign-Onを使用して、ピア・プロバイダでユーザーを認証するフローは次のとおりです。
ユーザーはピアIdPにいます（手順1）。
IdPはユーザーを認証アサーションとともに、SPであるOracle Identity Federationにリダイレクトします（手順2、3）。
Oracle Identity Federationがアサーションを処理し、ローカルのOracle Identity Federationセッションを作成して、ユーザーをIDとともに認証モジュールに転送します（手順4）。
認証モジュールが、ユーザーをユーザーIDとともにOracleAS Single Sign-Onにリダイレクトします（手順5、6）。
OracleAS Single Sign-Onが、ローカルの認証済セッションを作成し、mod_ossoによって保護されたリソースへのアクセスを許可します（手順7、8）。
|
注意: Oracle Identity FederationとOracleAS Single Sign-Onがリソースを保護しており、どちらかのコンポーネントを認証メカニズムにできる環境の詳細は、『Oracle Application Server Single Sign-On管理者ガイド』の「Oracle Identity Federationとの統合」を参照してください。 |
この項では、Oracle Identity Federationでデータ・ストアを使用する場合のインストール要件について説明します。内容は次のとおりです。
永続フェデレーション・データ・ストアに使用するデータ・リポジトリを選択する必要があります。Oracle Identity Federationでは、Oracle Internet Directory、Sun Java System Directory ServerおよびMicrosoft Active Directoryなど、業界標準のLDAPリポジトリを使用できます。電子メール・アドレス、X.509 DN、KerberosまたはWindows名前識別子などの、不透明でない名前識別子を使用する、SAML 2.0のNoneオプション（リポジトリなし）もサポートしています。
|
注意: SAML1.xとWS-Federationにはフェデレーション・データ・ストアは不要です。 |
接続情報
Oracle Identity Federationをインストールする前に、リポジトリに関する次の情報を収集してください。
接続URL（ホスト名とポートで構成されるLDAPサーバーURLのスペース区切りリスト）。
バインドDN。
これは、Oracle Identity FederationサーバーがLDAPサーバーに接続するために使用するDNです。次に例を示します。
cn=fedid,dc=mycompany,dc=com
パスワード。
ユーザー・フェデレーション・レコード・コンテキスト。
これは、このOracle Identity Federationサーバーのすべてのフェデレーション・レコードをその下に格納するノードです。
LDAPコンテナ・オブジェクト・クラス。
これは、LDAPコンテナがまだない場合に、それを作成する際にOracle Identity Federationが使用するユーザー・フェデレーション・レコード・コンテキストのタイプです。フィールドが空の場合、値はapplicationprocessに設定されます。Microsoft Active Directoryの場合、たとえばコンテナにこのフィールドが設定される必要があります。このフィールドの適切な設定は、使用されているユーザー・フェデレーション・レコード・コンテキストにより異なります。（ユーザー・フェデレーション・レコード・コンテキストについては、この項の後の方で説明します）。
様々なタイプのディレクトリ・サーバーの場合のLDAPコンテナ・オブジェクト・クラスの例を次に示します。
Oracle Internet Directory: 空
Sun Java System Directory Server: 空
Microsoft Active Directory: container
一意のフェデレーションID属性。
これは、フェデレーション・レコードを一意に識別するために使用されるLDAP属性です。この属性は、Federation RecordタイプのLDAPオブジェクト・クラス、またはその最上位の親で定義される必要があります。空の場合は、デフォルトのフェデレーションID属性はフェデレーション・レコードのDNとして使用されます。
様々なタイプのディレクトリ・サーバーの場合の、一意のフェデレーションID属性の例を示します。
Oracle Internet Directory: 空
Sun Java System Directory Server: 空
Microsoft Active Directory: 空
最大接続数。これは、Oracle Identity FederationによってLDAPサーバーに作成される同時接続数の最大値です。
接続待機タイムアウト。これは、Oracle Identity FederationによってLDAPサーバーに開かれた接続数が最大値に達した場合に、接続が利用可能になるまで待機する秒数の最大値です。
ユーザー・フェデレーション・レコード・コンテキストとLDAPコンテナ・オブジェクト・クラスの関係
ユーザー・フェデレーション・レコード・コンテキストとLDAPコンテナ・オブジェクト・クラスには互換性がある必要があります。ユーザー・フェデレーション・レコード・コンテキストでは、フェデレーション・レコードが格納されるコンテナのDNを管理者が指定します。そのDNは、コンテナの親（あらかじめ存在する必要があります。たとえばdc=us,dc=oracle,dc=com）、およびそのオブジェクト・クラスの一部であるフェデレーション・レコード・コンテキストの属性（たとえばcn=orclfed）を含みます。そうしたDNの例は、たとえばcn=orclfed,dc=us,dc=oracle,dc=comのようになります。
この例の要件は、cnがLDAPコンテナ・オブジェクト・クラス・フィールドに設定されているオブジェクト・クラス（設定されていない場合はapplicationprocessオブジェクト・クラス）の属性である必要があるということです。
DNがou=fed,dc=us,dc=oracle,dc=comであるようなフェデレーション・レコード・コンテキストを持つことを管理者が選択する場合、管理者は、LDAPコンテナ・オブジェクト・クラス・フィールドを、属性がouであるオブジェクト・クラス（たとえば、organizationalUnit）に設定する必要があります。
要約すると、ユーザー・フェデレーション・レコード・コンテキストは、フェデレーション・レコードが格納されるLDAPコンテナ・エントリを参照しており、DNで使用されるLDAPコンテナの属性は、使用されるLDAPコンテナ・オブジェクト・クラスで定義される必要があります。たとえば、DNがou=fed,dc=us,dc=oracle,dc=comの場合、LDAPコンテナ・オブジェクト・クラスはou属性を定義する必要があります。DNがcn=fed,dc=us,dc=oracle,dc=comの場合は、LDAPコンテナ・オブジェクト・クラスはcn属性を定義する必要があります。
LDAPスキーマに関する注意
FederationサーバーによりLDAPサーバーにレコードが作成されるようにするには、Oracle Identity Federationが定義する属性およびオブジェクト・クラスが含まれるようにLDAPスキーマをアップグレードする必要があります。
LDAPスキーマのアップグレードは、インストール時（拡張インストール・モードを使用）またはインストール後に行います。
インストール時のスキーマのアップグレード
インストール時にアップグレードするには、次の手順を実行します。
「拡張インストール」モードを選択します。
「構成オプションの選択」ページで、「LDAPサーバー内のフェデレーション・データ」ボックスを選択します。これにより、フェデレーション・レコードが、スキーマのアップグレードが必要なLDAPサーバーに格納されるように指定されます。
「フェデレーション・データ・ストアの指定」ページで、LDAP接続情報を入力します。これで、スキーマがインストール・プロセスの一部としてアップグレードされます。
インストール後のスキーマのアップグレード
インストール後にアップグレードを行うには、Oracle Identity Federationのインストールに、ldapmodifyツールを使用してLDAPサーバーのスキーマをアップグレードできるLDIFファイルが含まれていることを確認してください。
使用するLDIFファイルは、使用するLDAPサーバーの種類によって異なります。
Oracle Internet Directoryを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldifです。
Sun One Directory Serverを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaIPlanet.ldifです。
Microsoft Active Directory Serverを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaAD.ldifです。この場合、LDIFファイルを編集して%DOMAIN_DN%という文字列を使用中のActive Directoryのドメインの接尾辞と置き換える必要があります。
たとえば、接尾辞はdc=mydomain,dc=mycompany,dc=comです。
IBM Tivoli Directory Server（IBM TDS）6.0を使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaTivoli.ldifです。
ldapmodifyを使用して、LDAPスキーマをLDIFファイルでアップグレードできます。次に例を示します。
ldapmodify -c -D BIND_DN_USERNAME -w PASSWORD -f $Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldif -h LDAP_HOSTNAME -p LDAP_PORT -x
ユーザー・データ・ストアではデータ・リポジトリを選択する必要があります。Oracle Identity Federationでは、次のような業界標準のリポジトリを使用できます。
LDAP（Oracle Internet Directory、Sun Java System Directory ServerおよびMicrosoft Active Directory）
RDBMS
Oracle Access Manager
OracleAS Single Sign-On
CA eTrust SiteMinder
データ・リポジトリのロールは、Oracle Identity Federationがアイデンティティ・プロバイダ（IdP）とサービス・プロバイダ（SP）のどちらに構成されるかにより異なります。
IdPの場合、Oracle Identity Federationはリポジトリを使用して、ユーザーIDを検証し、プロトコル・アサーションを構築します。
SPの場合、次のようになります。
Oracle Identity Federationはリポジトリを使用して、受信したアサーションの情報を宛先のユーザーIDにマップし、その後で保護されたリソースへのアクセスを認可します。
新規フェデレーションを作成する場合、Oracle Identity Federationはリポジトリを使用してユーザーを識別し、新しいフェデレーションをそのユーザーのアカウントにリンクします。
LDAPリポジトリの場合の接続情報
ユーザー・データ用に、Oracle Access Manager、OracleAS Single Sign-OnおよびCA eTrust SiteMinderなどのLDAPディレクトリを使用するIdM製品には接続情報が必要です。
Oracle Identity Federationをインストールする前に、リポジトリに関する次の情報を収集してください。
接続URL: LDAPのURLのスペース区切りリスト。
バインドDN。
パスワード。
ユーザーID属性: ルックアップまたは認証手順でユーザーをマップするために使用する属性名。
ディレクトリ・サーバーのタイプごとのユーザーID属性の例を次に示します。
Oracle Internet Directory: uid
Sun Java System Directory Server: uid
Microsoft Active Directory: sAMAccountName
ユーザー説明属性。
このフィールドは、人間が読むことができるフェデレーション所有者識別子として使用するユーザー属性を参照します。この情報はフェデレーション・レコードに格納されます。
ディレクトリ・サーバーのタイプごとのユーザー説明属性の例を次に示します。
Oracle Internet Directory: uid
Sun Java System Directory Server: uid
Microsoft Active Directory: sAMAccountName
個人オブジェクト・クラス: LDAPサーバーでユーザーを表すLDAPオブジェクト・クラス。
様々なタイプのディレクトリ・サーバーの場合の個人オブジェクト・クラスの例を次に示します。
Oracle Internet Directory: inetOrgPerson
Sun Java System Directory Server: inetOrgPerson
Microsoft Active Directory: user
ベースDN: LDAPユーザー検索が実行されるノード。次に例を示します。
dc=us,dc=oracle,dc=com
最大接続数: Oracle Identity FederationによってLDAPサーバーに作成される同時接続数の最大値です。
接続待機タイムアウト: Oracle Identity FederationによってLDAPサーバーに開かれた接続数が最大値に達した場合に、接続が利用可能になるまで待機する秒数の最大値です。
RDBMSリポジトリの場合の接続情報
CA eTrust SiteMinderはユーザー・リポジトリにデータベースを使用するため、接続情報が必要です。
Oracle Identity Federationをインストールする前に、リポジトリに関する次の情報を収集してください。
JNDI名: ユーザーを認証またはロケーティングするためにOracle Application Serverに構成されている、RDBMSを参照するデータソースを参照します。Oracle Identity Federationをインストールした後で、このデータソースを定義しないとユーザーを認証できません。
ユーザー名。
パスワード。
ログイン表: 認証とルックアップのために使用される、ユーザー情報を含むRDBMS表。
ログインID列: ユーザー識別子を含むログイン表のRDBMS列。
ログイン・パスワード列: ユーザー・パスワードを含むログイン表のRDBMS列。
パスワード・ダイジェスト・アルゴリズム: RDBMS表に格納されている値に対して結果を照合する前に入力パスワードに適用するハッシュ・アルゴリズム。
ユーザー説明属性: このフィールドは、人間が読むことができるフェデレーション所有者識別子として使用するユーザー属性を参照します。この情報はフェデレーション・レコードに格納されます。
Oracle Identity Federationには次のコンポーネントが必要です。
Java 2 SDK Standard Edition (J2SE) Version 1.4.2（インストールにバンドル）。
Oracle Containers for J2EE - OC4J（インストールにバンドル）。
ユーザーIDデータ・ストア。通常はLDAPディレクトリですが、オプションでデータベース・ストアのこともあります。
ユーザー・フェデレーション・データ・ストア用に次のリポジトリのいずれか。
Oracle Internet Directory
Microsoft Active Directory
Sun Java System Directory Server
|
注意: Oracle Identity Federationでは、ユーザー・フェデレーション・データ・ストアがすべての場合に必ず必要というわけではありません。Liberty 1.xとSAML 2.0の不透明で永続的な識別子の場合は必要ですが、SAML 1.x、WS-FederationおよびSAML 2.0の不透明でない識別子（電子メール・アドレス、subject DNなど）の場合はオプションです。 |
RDBMS一時データ・ストア用にOracle9i Database Serverリリース10.1.0.3.0以上。
プロキシ実装用にOracle HTTP Server。Oracle Identity Federationでサポートされる唯一のプロキシ・サーバーで、インストールにバンドルされています。
Oracle Identity Federationがサポートするプラットフォームとコンポーネントの詳細は、Oracle Application Server/OC4J認定マトリックスを参照してください。
Oracle Identity Federationを活用するフェデレーテッド・アイデンティティ・システムのデプロイを計画する場合、アーキテクチャに関係するパフォーマンス関連の考慮事項、選択肢およびトレードオフを把握する必要があります。
この項では、フェデレーテッド環境においてパフォーマンスに影響を与える様々な要因について検討し、スタンドアロンのOracle Identity Federationサーバーを使用する本番システム向けのハードウェア要件を見積もる際に役立つガイドラインを提供します。内容は次のとおりです。
Oracle Identity Federationをデプロイする前に、フェデレーテッド認証設定におけるOracle Identity Federationのアーキテクチャとその役割を定義する必要があります。次の事項を決定する必要があります。
様々な信頼できるパートナでどのフェデレーション仕様が使用されるか。次のような選択肢があります。
SAML 2.0。SAML 1.xと比較すると、フローが追加されることによってパフォーマンス上の考慮事項がより重要になる可能性があります。
Liberty ID-FF 1.1および1.2。
SAML 1.0および1.1。
WS-Federation。
パートナとのフェデレーションにどのプロファイルを使用するか。オプションには、ブラウザPOSTプロファイルまたはアーティファクト・プロファイル、WS-Federationパッシブ・リクエスタ・プロファイル、属性共有、その他があります。
どのトランスポート・セキュリティ・プロトコルおよび証明書を使用するか。アサーションは署名されるか。
Oracle Identity Federationが果す役割は何か。オプションは次のとおりです。
アイデンティティ・プロバイダ（IdP）（ソース・ドメイン）
サービス・プロバイダ（SP）（宛先ドメイン）
IdPおよびSPの両方
どのタイプ（およびどのベンダー）の認可IDリポジトリがインストールされるか。
Oracle Identity Federationをサービス・プロバイダ（SP）としてデプロイする場合は、保護されたリソースへのアクセスを認可するために、IDおよびアクセス管理（IAM）システムをデプロイするかどうかを考慮します。ソリューションの全体的なパフォーマンスは、IAMシステムのパフォーマンスに著しく依存します。
|
注意: Oracle Identity Federationは、アクセス管理システムを必要としない、軽量のフェデレーション・エンドポイントの作成を可能にする統合フレームワークを提供します。 |
Oracle Identity Federationにプロキシ・サーバーをインストールするかどうか。インストールする場合、DMZまたはファイアウォールの内部など、Oracle Identity Federationおよびプロキシ・サーバーが置かれる場所に配慮してください。
アーキテクチャがどのように高可用性のシナリオを提供するか。具体的には、次のとおりです。
Oracle Application Server高可用性トポロジを活用して、コールド・フェイルオーバー・クラスタをサポートするかどうか
ロード・バランシングおよびフェイルオーバー構成において、複数のフェデレーション・サーバーがアサーション・データを使用できるように、一般的なアサーション・ストア・データベースを設定するかどうか
Oracle Identity Federationの全体的なスループットおよびパフォーマンスは、次のような様々な要因によって左右されます。
サポートされているプロファイル（アーティファクトまたはPOSTなど）
使用されるセキュリティ機能（証明書、デジタル署名または暗号化アサーション（あるいはその両方））
トランザクションの処理に関係する、ファイアウォール、プロキシ・サーバー、LDAPディレクトリ、データベース、およびIAMシステムなどの個々のコンポーネントの使用
以降の副項では、これらの内容について詳しく説明します。
SAMLの仕様は、デプロイされる2つの主要なプロファイル、SAMLブラウザPOSTプロファイルおよびアーティファクト・プロファイルを含む、多数のプロファイルをサポートします。一般的に、SAMLブラウザPOSTプロファイルを使用すると、IdPおよびSP間での必要なラウンドトリップが少ないため、POSTプロファイルはアーティファクト・プロファイルよりもパフォーマンスに優れています。ただし、一般的にアーティファクト・プロファイルのほうがSAMLアサーションの交換においてはより安全な方法のため、セキュリティ上のトレードオフの可能性が生じます。
LDAPディレクトリ、RDBMSおよびバックエンドIAMシステムを使用する場合、本番環境のパフォーマンスに影響を与える恐れがあるため、該当するコンポーネントのトランザクションの処理スピードに注意する必要があります。次の点に注意してください。
データベース接続プールの設定を制御するオプションを提供するように、RDBMSパラメータを設定できます。
バックアップされたIDおよびアクセス管理システムとして、Oracle Access Managerを使用する場合、次に示すアクセス・サーバーのサイジング考慮事項と同様、AccessGateのパフォーマンス上の考慮事項が適用されます。
http://www.oracle.com/pls/wocprod/docs/page/ocom/technology/products/id_mgmt/pdf/wp-oracle-idm-sizing-considerations.pdf
SAML 2.0アサーションでは、デジタル署名/暗号化を使用するかどうかによってパフォーマンスが左右されます。これらの機能を削除するとパフォーマンスは向上しますが、IdPおよびSPの通信がインターネット上で行われる場合は、削除しないことをお薦めします。
LDAPサーバー
RDBMS（一時セッション・データおよび構成向け）
リモート・プロバイダ（Oracle Identity FederationサーバーがSOAPプロトコルを使用して相互に直接通信する場合）
「IDMデータ・ストア」→> 「ユーザー・データ・ストア」および「フェデレーション・データ・ストア」内の設定も確認します。
「Oracle Identity Federationのパフォーマンス管理」を確認してください。
パフォーマンスおよび高可用性を向上させるには、複数のOracle Identity Federationサーバーのスケーリングおよびロード・バランシングを行うことも考慮してください。ロード・バランシング・ソリューションを実装すると、使用するサイトをバックアップおよびフェイルオーバーによって保護できます。
詳細は、「高可用性」および「Oracle Identity Federationでのロード・バランサの設定」を参照してください。
本番環境における他のサーバーの存在も考慮します。具体的には、次のように考慮します。
Oracle Application Serverをチューニング、およびOracle Identity Federationへの適切な接続制限を設定します。次のことが可能です。
メモリーの使用量、プロセスの数などの典型的な構成パラメータを使用してOracle Application Serverをチューニングします。詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。
Oracle Identity FederationがリモートのHTTPサーバーおよびRDBMSサーバーと通信する際に使用するHTTP/JDBC接続の最大数を指定します。詳細は、「同時接続制限の設定」および「JDBC接続制限の設定」を参照してください。
Oracle Identity Federationが活用するOracle HTTPサーバーをチューニングします。詳細は、「Oracle HTTP Serverのチューニング」を参照してください。
図2-11は、サービス・プロバイダ向けの一般的なOracle Identity Federationデプロイメントのアーキテクチャを示しており、ここではOracle Identity Federationは、バックエンドのアクセス管理システムとしてOracle Access Managerに依存しています。この図では、複数のパートナがDMZを介して、ロード・バランシングが行われたOracle Identity Federationプロキシ・サーバーのペアにアクセスしています。これらのプロキシ・サーバーは、Oracle Identity Federationサーバーのペアのフロントエンドです。
2000人の同時ユーザーをサポートする環境においては、基本のOracle Identity Federationデプロイメントについて、次のハードウェアおよび機器をお薦めします。
Oracle Identity Federation用にサポートされるすべてのサーバークラスのマシンおよびオペレーティング・システム。Oracle Identity Federation向けに認定されたプラットフォームのリストは、次の場所のOracle Application Server 10gR3（10.1.4.0.1）認定マトリクスを参照してください。
http://www.oracle.com/technology/software/products/ias/files/idm_certification_101401.html
フェイルオーバーのシナリオでは、必要なマシン数が倍になります。冗長性を確保するため、2つ以上のOracle Identity Federationサーバーを別個のマシン上で使用します。
サーバーのフットプリント:
2〜4GBのメモリー（4GBを推奨）
マシンごとに2つ以上のCPU
プロキシ・サーバーを使用する場合は、ベンダー固有のサイジングの推奨に従ってください。
図2-12は、SPモードでのOracle Identity Federationデプロイメントに対して推奨されるトポロジを示しています。ここでは、Oracle HTTPサーバーがWebGateによって保護されたプロバイダ・アプリケーションを提供します。
リファレンス・サーバーのフットプリントおよび前述のトポロジの推奨を使用することによって、次のパフォーマンス結果が得られます。
テスト1
Transient Store: RDBMS CPUs: 4 Directory: Oracle Internet Directory 7 OC4J_FED instances both SP and IdP -Xmx2048 -Dfed.jdbc.min.conn=50 -Dfed.jdbc.min.conn=300 SP OIF -> ko40g OID IdP OIF -> ko30g OID SP and IdP User data store ldap connection pool = 300 SP and IdP Federation data store = None (SAML) SP and IdP OIF transient data in rdbms SP and IdP HTTP Servers: MinSpareServers 50 MaxSpareServers 250 StartServers 250 MaxClients 500 AccessGate: MinSpareServers 5 MaxSpareServers 10 StartServers 100 MaxClients 100 AccessSvr1 -> ko30g OID AccessSvr2 -> ko40g OID OID1 and OID2 on port 389:
結果: 125 TPS
テスト2
Transient Store: Memory CPUs: 4 Directory: Oracle Internet Directory 5 OC4J_FED instances both SP and IdP -Xmx2048 -Dfed.jdbc.min.conn=50 -Dfed.jdbc.min.conn=300 SP OIF -> ko40g OID IdP OIF -> ko30g OID SP and IdP User data store ldap connection pool = 300 SP and IdP Federation data store = None (SAML) SP and IdP OIF transient data in memory SP and IdP HTTP Server: MinSpareServers 50 MaxSpareServers 250 StartServers 250 MaxClients 500 AccessGate: MinSpareServers 5 MaxSpareServers 10 StartServers 100 MaxClients 100 AccessSvr1 -> ko30g OID AccessSvr2 -> ko40g OID OID1 and OID2 on port 389: orclserverprocs 4 orclmaxcc 4
結果: 240 TPS
|
注意: このテストでは、RDBMSからメモリー内の一時ストアに切り替えたことで、パフォーマンスが大幅に向上しました。 |
次のチェックリストはOracle Identity Federationインストールを計画するための主要な項目を要約したもので、デプロイメントを行うための第1歩となります。
表2-3 実装チェックリスト
| 計画項目 | 推奨値/提案値 | 注意 |
|---|---|---|
|
アーキテクチャ/基本構成 |
||
|
設定するロール |
IdPとSPのいずれかまたは両方。 |
|
|
トポロジ |
ハブ・アンド・スポークまたはピアツーピア。 |
|
|
プロトコル |
Liberty 1.1、Liberty 1.2、SAML 2.0、またはこれらの任意の組合せ。SAML 1.0、SAML 1.1およびWS-Federation。 |
|
|
リポジトリ |
ユーザー・データおよびフェデレーション永続データのリポジトリを指定します。 |
|
|
LDAPサーバー・ホスト名 |
たとえば |
|
|
LDAPサーバーのポート番号 |
たとえば |
|
|
LDAPサーバーのアクセス資格証明 |
たとえば |
|
|
ベースDN |
たとえば |
|
|
フェデレーション・レコード・コンテキスト |
たとえば |
|
|
フェデレーション・スキーマの更新脚注1 |
この情報はインストール時に必要です。 |
|
|
一時データ・ストア |
一時データのリポジトリを、RDBMSにするか、メモリー内にするか指定します。 |
|
|
IdPプロファイルおよびバインディング |
有効な組合せ1つに1行を使用します。 |
|
|
SPプロファイルおよびバインディング |
有効な組合せ1つに1行を使用します。 |
|
|
SSL暗号化 |
||
|
有効/無効 |
||
|
Javaキーストア |
SSLを使用する場合、Javaキーストアの位置を指定します。 |
|
|
SSL設定の詳細は、「Oracle Identity FederationでのSSLの使用」を参照してください。 |
||
|
証明書 |
||
|
署名 |
署名キーのペアに対するPKCS #12ウォレットの位置を指定します。 |
|
|
暗号化 |
暗号化キーのペアに対するPKCS #12ウォレットの位置を指定します。 |
|
|
パフォーマンス計画 |
||
|
トポロジ、リファレンス・サーバーのフットプリント |
パフォーマンス上のヒントおよび推奨事項は、「サイジングのガイドライン」を参照してください。 |
脚注 1 フェデレーション・スキーマ更新の場合、接続URL、バインドDN、パスワード、ユーザー・フェデレーション・レコード・コンテキスト、LDAPコンテナ・オブジェクト・クラス（Microsoft Active Directory）および一意のフェデレーションID属性を収集します。
