| Oracle® Fusion Middleware Oracle Identity Federation管理者ガイド 11g リリース1(11.1.1) B66693-01 |
|
 前 |
 次 |
この章では、インストール・オプションをよく理解できるように、Oracle Identity Federationのデプロイメントに関する考慮事項を説明します。これらの項目が含まれます。
Oracle Identity Federationのデプロイメントを計画する場合、サーバー・アーキテクチャ、運用環境、およびフェデレーテッド交換ネットワークでサーバーが持つロールについて把握する必要があります。この項では、Oracle Identity Federationのデプロイメントにおけるアーキテクチャについて、次のような事項を概説します。
前述したとおり、フェデレーテッド・ネットワークでのOracle Identity Federationのインスタンスは、アイデンティティ・プロバイダ(IdP)とサービス・プロバイダ(SP)のいずれか、または両方として動作できます。
アイデンティティ・プロバイダ・ロール
ユーザーがフェデレーテッド・ネットワーク内の保護されたリソースにアクセスすると、そのリソース用のサービス・プロバイダによって、ユーザーは認証用のアイデンティティ・プロバイダとして動作するOracle Identity Federationに誘導されます。Oracle Identity Federationは認証エンジンを使用して資格証明を取得し、ユーザーを認証します。これでOracle Identity FederationがユーザーのIDをリソース(SP)に対して宣言することができるようになり、リソースではユーザーの認証が実施され、要求されたアプリケーションが提供されます。
サービス・プロバイダ・ロール
ユーザーがOracle Single Sign-Onなどの認証エンジンで保護されたリソースにアクセスすると、ユーザーはOracle Identity Federationにリダイレクトされます。サービス・プロバイダ・ロールでは、Oracle Identity Federationは、グローバル認証用ポータルなどのアイデンティティ・プロバイダにユーザーをリダイレクトします。これによってIdPポータルは資格証明を取得し、ユーザーを認証して、Oracle Identity Federationにリダイレクトを返します。このOracle Identity FederationはIdPからアサートされたIDを取得します。Oracle Identity Federationは(認証された)ユーザーを認証エンジンにリダイレクトし、その認証エンジンが保護されたリソースへのアクセス権を付与します。
フェデレーション・トポロジ
フェデレーションは任意の数のアイデンティティ・プロバイダとサービス・プロバイダで構成できます。一般的なフェデレーション・トポロジの一つに、ハブ・アンド・スポーク・モデルと呼ばれるものがあります。このトポロジでは、1つのサービス・プロバイダが複数のアイデンティティ・プロバイダから認証を受け入れるか、1つのアイデンティティ・プロバイダが複数のサービス・プロバイダに対して認証を実施します。
DMZにどのコンポーネントを置くか、プロキシ・サーバーを使用するかどうかを決定する必要があります。Oracle Identity Federationをファイアウォールの背後に置いた場合、プロキシがリクエストとレスポンスをフェデレーション・サーバーに転送することによって、インターネットなどの外部ネットワークからサーバーへの透過的なアクセスを可能にする必要があります。
Oracle Identity Federationの構成は、実装するプロファイルの種類により異なります。
|
関連項目: Oracle Identity Federationでのプロキシ・サーバーの設定の詳細は、付録B「Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用」を参照してください。 |
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暗号化は、インストール時にサーバー・インスタンスごとに有効または無効にできるオプションです。
初回の設定とテストでは、アイデンティティ・プロバイダおよびサービス・プロバイダはデフォルトの自己署名証明書を使用できます。しかし、本番に移行する前に、インストールされたプロバイダがサード・パーティのCA証明書を使用するように設定されていることを確認する場合があります。
Oracle Identity Federationには、信頼できるCAのリストと証明書失効リスト(CRL)を格納できるリポジトリがあります。
サーバーで証明書が有効になっている場合は、Oracle Identity Federationにより、SAMLおよびWS-Federationの各プロトコルで、着信するシグネチャを検証するために使用されているすべての証明書が検証されます。
証明書を検証する際、サーバーは証明書または信頼できる証明書とみなせるその発行者を見つけようと試み、証明書がCRLにないことを確認します。
|
関連項目:
|
Oracle Identity Federationをインストールする場合、サーバーがサポートするフェデレーション・プロトコルを決定する必要があります。Oracle Identity Federationでは、次のプロトコルを使用できます。
SAML 1.0
SAML 1.1
SAML 2.0
WS-Federation
OpenID
Oracleアイデンティティ・フェデレーション管理者は、サーバーで使用するフェデレーション・プロトコルを決定する必要があります。
詳細は、第1.1.4項「フェデレーション・プロトコル」を参照してください。
この項では、プロファイルとバインディングを説明します。内容は次のとおりです。
フェデレーション・サーバーのインスタンスがサポートするプロトコルを選択したら、実装するプロトコル・プロファイル、セキュリティ転送バインディングおよびその他の機能を選択する必要があります。この項では、Oracle Identity Federationでサポートされているプロトコルについて概説します。
表2-1は、Oracle Identity Federationでサポートされている、SAML 2.0プロトコル・プロファイルとセキュリティ転送バインディングの組合せを示しています。
表2-1 SAML 2.0の場合のOracle Identity Federationのプロファイルおよびバインディング
| 機能 | プロファイル/ バインディング |
SAML 2.0 |
|---|---|---|
|
シングル・サインオン |
アーティファクト |
x |
|
シングル・サインオン |
HTTP Post |
x |
|
Logout |
HTTPリダイレクト |
x |
|
Logout |
HTTP Post |
x |
|
NameID登録 |
HTTPリダイレクト |
x |
|
NameID登録 |
HTTP Post |
x |
|
NameID登録 |
SOAP |
x |
|
フェデレーション終了 |
HTTPリダイレクト |
x |
|
フェデレーション終了 |
HTTP Post |
x |
|
フェデレーション終了 |
SOAP |
x |
|
属性取得 |
SOAP |
x |
表2-2は、Oracle Identity Federationでサポートされている、SAML 1.xおよびWS-Federation (WS-Fed)のプロトコル・プロファイルとセキュリティ転送バインディングの組合せを示しています。
Oracle Identity Federationは、OpenIDバージョン2.0をサポートしています。
認証
Oracle Identity Federationは、基本的なOpenID認証リクエスト機能をサポートしています。
アソシエーション
Oracle Identity Federationは、次に示すような、メッセージの署名および検証にHMAC共有秘密鍵を使用するプロバイダ・フェデレーションをサポートしています。
HMAC-SHA1
HMAC-SHA256
Oracle Identity Federationは、次のセッション・アソシエーション・タイプをサポートしています。
暗号化なし
Diffie-Hellman SHA1
Diffie-Hellman SHA256
検出
Oracle Identity Federationは、次をサポートしています。
OpenIDプロバイダ(OP)およびリライイング・パーティ(RP)に対するメタデータの公開
RPによるOPのXRDS検出
RPエンドポイント検証を実装することにより、RPになりすましてOpenIDアサーションを取得するURLリダイレクタを防ぎます。OPによるRPエンドポイント検証は、次のように実装されます。
RPのXRDS検出。レルムURLでホストされるXRDS文書にエンドポイントが記述されているかどうかを確認します。
OpenIDの仕様に記載されているように、レルムを使用した検証。レルムにはURIまたは一致するドメイン(*.foo.comなど)のいずれかを指定できます。検証では、サーバーがレルムからドメインを抽出し、RPエンドポイントへの照合を試みます。検証に使用する有効なドメインには、少なくとも2つの要素が含まれている必要があります(.foo.comは許容されますが、.comは許容されません)。また、サーバーは破棄すべきドメインの指定方法も提供します(*.co.ukなど)。
アカウント・リンク
Oracle Identity Federationは、OpenID主張識別子とローカル・ユーザー・アカウントの間の永続的なアカウント・リンクをサポートするために、フェデレーション・データ・ストアを使用します。
アサーション
Oracle Identity Federationは、SP側でのアサーションからユーザーへのレコード・マッピングをサポートしています。
偽名
Oracle Identity Federationは、不透明で永続的な名前識別子をOpenIDアサーションで使用します。つまり、次のことを意味します。
フェデレーション・データ・ストアは、IdP側に必要です。
フェデレーション・データ・ストアは、SP側ではオプションです。SPがアサーションをユーザーにマップする際にフェデレーテッドIDを使用するように構成されている場合は、フェデレーション・データ・ストアが必要です。
プロファイルおよび拡張
表2-3は、Oracle Identity Federationでサポートされている、プロトコル・プロファイルと拡張を示しています。
この項では、選択したプロトコルに実装するプロファイルを選択する際に留意すべき考慮事項を説明します。
SAMLプロトコルでは、プロバイダがアーティファクト・プロファイルまたはPOSTプロファイルを使用してOracle Identity Federationアサーションを交換するかどうかを指定できます。これらのプロファイルは、アサーションを安全に交換するための方法の違いを表しています。
OpenIDプロトコルでは、ICAMプロファイル、AX拡張またはPAPE拡張を選択できます。
この項では、次の内容を説明します。
アーティファクト・プロファイルを考慮する場合には次のことを検討してください。
アーティファクト・プロファイルは、XML署名を使用するPOSTプロファイルほどリソース集約的ではありません。
アイデンティティ・プロバイダのSAMLコンポーネントはDMZに置く必要があります。
アーティファクト・プロファイルのリクエスト処理
図2-2は、アーティファクト・プロファイルでリクエストが処理されるプロセスを示しています。
処理フローは次のような道筋をたどります。
ユーザーが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-3に示したように、アーティファクト・プロファイルを使用する場合、Oracle Identity Federationに、IdPサーバーやSPサーバーのプロキシを構成することができます。このセキュア環境で、プロキシはDMZにあります。
|
関連項目: Oracle Identity Federationでのプロキシ・サーバーの設定の詳細は、付録B「Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用」を参照してください。 |
プロセス・フローは次のようになります。
ユーザーが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署名の使用が必要です。また、署名と検証には大量のリソースが必要です。
多数のリクエストやレスポンスを送受信する計画がある場合のパフォーマンス上のヒントは、第2.6項「サイジングのガイドライン」を参照してください。
POSTプロファイルのリクエスト処理
図2-4は、POSTプロファイルの下でリクエストが処理されるプロセスを示します。
プロセス・フローは次のようになります。
ユーザーがリクエストを開始します。認証されるまでリクエストを処理できません。
Oracle Identity Federationはアイデンティティ・プロバイダとして動作し、ユーザーを認証して、レスポンスを含むHTMLフォームを返します。このフォームは、IDアサーションと、サービス・プロバイダのURLで構成されます。レスポンスは、Oracle Identity FederationのIdPの秘密署名キーを使用して署名されます。
ブラウザは、このフォームをサービス・プロバイダの受信者サービスのURLにpostします。受信者サービスは、IdPの署名キーに関連付けられた公開証明書を使用して、署名されたレスポンスを検証します。
サービス・プロバイダはアサーションを抽出し、アサーションのためにユーザー・セッションを作成します。
サービス・プロバイダは、ユーザーのブラウザに、リクエストされたリソースへのリダイレクトを送信します。
ユーザーのブラウザは、サービス・プロバイダによって作成されたユーザー・セッションを介して、ターゲット・リソースへのリクエストを送信します。
プロキシを使用するPOSTプロファイル
セキュアなデプロイメントでは、POSTプロファイルはSSL経由でサービス・プロバイダにアサーション全体を送信します。IdPとSPは、SSLポートを通るHTTPS経由で通信するように構成されます。図2-5は、本番でPOSTプロファイルを使用するための望ましい手法を示しています。Oracle Identity Federationは、DMZにあるSPとして動作しています。
|
関連項目: Oracle Identity Federationでのプロキシ・サーバーの設定の詳細は、付録B「Oracle Identity FederationのプロキシとしてのOracle HTTP Serverの使用」を参照してください。 |
プロセス・フローは次のようになります。
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
SHA-1を使用した署名生成
SHA-1またはSHA-256を使用した署名検証
メッセージ・レベル機密保護のためのXML-ENC
メッセージ・レベルのセキュリティに加え、すべてのSAMLメッセージ・フローで、セキュアなSSL/TLSチャネルを使用することをお薦めします。アイデンティティ・プロバイダとサービス・プロバイダの間の通信はすべて、双方向認証(クライアント証明書とサーバー証明書)を使用する必要があります。
SAMLプロファイルは、通信プロトコルでSAMLアサーションとリクエスト/レスポンス・メッセージをセキュアに使用する方法に関する、具体的な推奨事項です。ここでは、SAML SSOのアーティファクト・プロファイルとPOSTプロファイルのセキュリティ要件を示します。
SAMLアーティファクト・プロファイルを使用するセキュアな通信
SAMLアーティファクト・プロファイルを使用するセキュアな通信には、次のことが必要です。
IdPからユーザーのブラウザへのリダイレクション、およびブラウザからSPへのリダイレクションにはSSLが必須です。
IdPおよびSPで直接通信を行うために使用されるSOAPチャネルは、SSLまたはHTTP Basic認証のいずれかを使用して保護する必要があります。
|
注意: SPは、IdPに認識されているユーザー名とパスワードを使用したHTTP Basic認証を使用することもできます。 |
SAML POSTプロファイルを使用するセキュアな通信
SAML POSTプロファイルを使用するセキュアな通信には、次のことが必要です。
ブラウザからサービス・プロバイダへのユーザー・リクエストの転送にはセキュアHTTP(HTTPS)が必要です。
アイデンティティ・プロバイダは、サービス・プロバイダに送信するレスポンスに署名する際にはXML署名を使用する必要があります。
サービス・プロバイダはレスポンスのXML署名を検証する必要があります。
SAML属性共有プロファイルは、リソース・リクエストの認可を提供するために追加のユーザー属性が必要であるときに、サービス・プロバイダが、SAMLアサーションでなくSSLクライアントX.509証明書を使用してユーザーを認証するために使用されます。
Oracle Identity Federationは、Oracle Access Managerとともに使用してピア・サイトでのSAML実装との相互運用を可能にするために、属性共有プロファイルを提供しています。コンポーネントとそのロールの詳細、およびOracle Identity FederationとOracle Access Managerの構成方法の詳細は、第5.6.4.3項「属性共有を使用するOracle Access Managerポリシーの構成」を参照してください。
WS-Federationは、実際の認証を実行するアイデンティティ・プロバイダを使用して1つ以上のサービス・プロバイダにサインインするために使用できます。
ログアウトするには、WS-Federationサインアウトを開始するIdPサイトでリンクをクリックします。Oracle Identity Federationは、セッションCookieを使用して、ユーザーがサインインした各SPを追跡しています。サーバーはユーザーのブラウザにHTMLサインアウト・ページを返します。各SPはサインアウト・クリーンアップを処理し、Oracle Identity Federationのために作成されたセッションをサインアウトします。
この項では、OpenIDの様々なプロファイルと拡張に対するOracle Identity Federationのサポートについて説明します。
AXはOpenID 2.0の拡張で、ユーザー属性をリクエストしたり、返したりすることができます。OIFは、AXバージョン1.0をサポートしています。
IdPにおけるサポートは次のとおりです。
IdPでのプロファイルのサポートが有効になります。ただし、各SPに対しては有効になりません。属性を送信するかどうかを指定する必要があります。
属性の定義は、SPパートナ固有のページにある既存の画面によって行われます。
SPにおけるサポートは次のとおりです。
属性の定義は、IdPパートナ固有のページにある既存の画面によって行われます。
属性定義のページで、SSOプロトコルの実行時にIdPからリクエストする属性を指定できます。
カスタムSPエンジンまたは前処理エンジンは、SSOプロトコルの実行時にIdPからリクエストする必要のある属性を実行時に指定できます。
Provider Authentication Policy Extension (PAPE)
PAPEはOpenID 2.0の拡張で、保証レベルなど、特定の認証タイプや強度をRPがリクエストできるようにします。Oracle Identity Federationは、PAPEバージョン1.0をサポートしています。
IdPおよびOPにおけるサポートは次のとおりです。
IdPは、PAPE拡張が有効かどうかをXRDS文書で公開します。
有効な場合、IdPはユーザーの認証に使用される認証メカニズムをSPへのレスポンスに組み込みます。
SP/RPにおけるサポートは次のとおりです。
IdPがPAPEをサポートし、特定の認証メカニズムをリクエストするように構成されている場合、IdPでのユーザー認証に使用するメカニズムはSPが指定します。
|
注意: Oracle Identity Federationの認証メカニズムはOpenIDの認証方式に変換されます。 |
米国政府Federal Identity, Credentialing and Access Management (ICAM)プロファイル
Oracle Identity Federationは、OpenID 2.0の導入に対して米国政府が示した、次のプライバシ・ポリシー要件とセキュリティ要件をサポートしています。
非個人識別情報(参照URI: http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf)。有効かつプロトコル交換で指定されている場合は、IdPはSPへのレスポンスに個人情報を組み込むことができません。
Private Personal Identifier(参照URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier)。有効かつプロトコル交換で指定されている場合は、IdPはRPに固有の不透明なClaimedIDを返す必要があります。
OpenIDのGSAプロファイル(参照URI: http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf)。有効かつプロトコル交換で指定されている場合は、IdPはOpenID SSOプロトコルの実行時にGSAプロファイルのルールに従う必要があります。
NIST認証レベル(参照URI: http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf)。有効な場合、IdPはNISTの保証レベル情報をSPへのレスポンスに組み込みます。
|
注意: これらのプロファイルは、Oracle Identity Federationで有効にできますが、フェデレーション・サーバーが要件に準拠していることを確認する必要があります。 |
図2-6は、OpenIDプロファイルでのリクエスト処理を示しています。
Oracle Identity Federationの機能の多くは、ユーザーが認証されていることを必要とします。このような操作には、次のものがあります。
シングル・サインオン、フェデレーション作成、フェデレーション終了およびNameID登録などのIdPプロトコル操作
フェデレーション作成、フェデレーション終了およびNameID登録などのSPプロトコル操作
認証の効力について見通しを得るために、フェデレーション・サーバーを、次のような別個のモジュールを含むものとして考えることができます。
Oracle Identity FederationがWS-Federation、Liberty 1.x、SAML 1.0/1.1、SAML 2.0およびOpenIDプロトコルをサポートします。
認証モジュールが、ユーザー認証およびIdMソリューションとの統合をサポートします。
これらの操作をサポートするために、Oracle Access Managerは、Webシングル・サインオン、ユーザーのセルフサービスと登録、ポリシー管理および委任管理など、広汎なID管理機能を提供します。
この項では、様々な構成のこれらのモジュールにより可能になる認証フローを検討します。
Oracle Identity Federationは、ユーザー・フェデレーション操作を実行するときには次の2つのモジュールと相互作用します。
認証エンジンはローカル認証メカニズムとして動作します。このモードでは、認証モジュールは使用可能な認証システムを使用してローカルに認証することができます。
Oracle Identity Federationは、認証モジュールに認証リクエストを伝えます。デプロイメントにより異なりますが、認証モジュールは、直接RDBMSまたはLDAPリポジトリと情報をやり取りすることも、Oracle Single Sign-OnなどのIdMソリューションに認証を委任することもあります。
Oracle Identity Federation SP統合エンジンは認証状態を伝播させるために動作します。このモードでは、サービス・プロバイダであるOracle Identity Federationが、フェデレーション・プロトコルを使用して、ユーザーがピア・アイデンティティ・プロバイダで認証されるようにします。Oracle Identity Federationは、ユーザーを認証モジュールに転送します。このモジュールは、SPにデプロイされたIdMソリューションに認証済のユーザー・セッションを伝播し作成します。これにより、リクエストされた保護リソースへのアクセスが順に可能になります。
このデプロイメントでは、認証モジュールが次のような様々なリポジトリやIdMソリューションと情報を直接やり取りして、Oracle Identity Federationがユーザーをローカルに認証できるようにします。
RDBMSリポジトリ
LDAPリポジトリ
このようなデプロイメントに関わるローカル認証のフローは次のとおりです。
ユーザーがOracle Identity Federationにアクセスします(手順1)。
ローカル認証の場合、Oracle Identity Federationがユーザーを認証モジュールに転送します(手順3)。
次の場合、ユーザーが資格証明を入力します(手順5)。
認証モジュールが資格証明の入力をユーザーに求めます(手順6)。
認証モジュールは、ユーザーを認証するためにリポジトリと情報をやり取りします(手順7)。
認証モジュールは、ユーザーをユーザーのIDとともにOracle Identity Federationに転送します(手順6、1)。
Oracle Identity Federationが認証されたユーザーと通信します(手順2)。
このデプロイメントでは、認証モジュールがOracle Single Sign-On IdMソリューションまたはOracle Access Managerに認証を委任して、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上に認証済セッションを作成するように認証モジュールにリクエストします。これによりユーザーはリクエストされたリソースにアクセス可能になります。リクエストされたリソースは、WebGate(Oracle Access Manager IdMデプロイメント)によって保護されています。
リクエストはピアIdPに発信され、Oracle Identity FederationはSPモードで認証します。
Oracle Access Managerを使用して、ピア・プロバイダでユーザーを認証するフローは次のとおりです。
ユーザーはピアIdPにいます(手順1)。
IdPはユーザーを認証アサーションとともに、SPであるOracle Identity Federationにリダイレクトします(手順2、3)。
Oracle Identity Federationがアサーションを処理し、ローカルのOracle Identity Federationセッションを作成して、ユーザーをIDとともに認証モジュールに転送します(手順4)。
認証モジュールはOracle Access Managerと情報をやり取りし、の認証済セッションを作成します(手順5)。
認証モジュールがユーザーを保護されたリソースにリダイレクトします(手順6)。
WebGate Webエージェントが、保護されたリソースへのアクセスをユーザーに許可します(手順7)。
このモードで、Oracle Identity Federationはフェデレーション・プロトコルを使用してユーザーを識別し、ユーザーがリクエストされたリソースにアクセスできるように、Oracle Single Sign-Onに認証済セッションを作成するように認証モジュールにリクエストします。リクエストされたリソースはmod_ossoによって保護されています。
リクエストはピアIdPに発信され、Oracle Identity FederationはSPモードで認証します。
Oracle Single Sign-Onを使用して、ピア・プロバイダでユーザーを認証するフローは次のとおりです。
ユーザーはピアIdPにいます(手順1)。
IdPはユーザーを認証アサーションとともに、SPであるOracle Identity Federationにリダイレクトします(手順2、3)。
Oracle Identity Federationがアサーションを処理し、ローカルのOracle Identity Federationセッションを作成して、ユーザーをIDとともに認証モジュールに転送します(手順4)。
認証モジュールが、ユーザーをユーザーIDとともにOracle Single Sign-Onにリダイレクトします(手順5、6)。
Oracle Single Sign-Onが、ローカルの認証済セッションを作成し、mod_ossoによって保護されたリソースへのアクセスを許可します(手順7、8)。
|
注意: Oracle Identity FederationとOracle Single Sign-Onがリソースを保護しており、どちらかのコンポーネントを認証メカニズムにできる環境の詳細は、Oracle Enterprise Single Sign-On Suite Plus管理者ガイドのOracle Identity Federationとの統合に関する項を参照してください。 |
この項では、Oracle Identity Federationでデータ・ストアを使用する場合のインストール要件について説明します。内容は次のとおりです。
永続フェデレーション・データ・ストアに使用するデータ・リポジトリを選択する必要があります。Oracle Identity Federationでは、次のような業界標準のLDAPリポジトリを使用できます。
Oracle Internet Directory
Sun Java System Directory Server
Microsoft Active Directory
IBM Tivoli
XMLストア、データベース、さらには電子メール・アドレス、X.509 DN、KerberosまたはWindows名前識別子などの、不透明でない名前識別子を使用する、SAMLおよびWS-FederationのNoneオプション(リポジトリなし)もサポートしています。
接続情報
Oracle Identity Federationをインストールする前に、リポジトリに関する次の情報を収集してください。
接続URL(ホスト名とポートで構成されるLDAPサーバーURLのスペース区切りリスト)。
バインドDN。
これは、Oracle Identity FederationサーバーがLDAPサーバーに接続するために使用するDNです。次に例を示します。
cn=fedid,dc=mycompany,dc=com
Password
ユーザー・フェデレーション・レコード・コンテキスト。
これは、このOracle Identity Federationサーバーのすべてのフェデレーション・レコードをその下に格納するノードです。
LDAPコンテナ・オブジェクト・クラス。
これは、LDAPコンテナがまだない場合に、それを作成する際にOracle Identity Federationが使用するユーザー・フェデレーション・レコード・コンテキストのタイプです。このフィールドが空白の場合は、applicationprocessに値が設定されます。Microsoft Active Directoryの場合、たとえばコンテナにこのフィールドが設定される必要があります。このフィールドの適切な設定は、使用されているユーザー・フェデレーション・レコード・コンテキストにより異なります。(ユーザー・フェデレーション・レコード・コンテキストについては、この項の後の方で説明します)。
様々なタイプのディレクトリ・サーバーの場合のLDAPコンテナ・オブジェクト・クラスの例を次に示します。
Oracle Internet Directory: 空
Oracle Directory Server Enterprise Edition: 空
Microsoft Active Directory: container
一意のフェデレーションID属性。
これは、フェデレーション・レコードを一意に識別するために使用されるLDAP属性です。この属性は、Federation RecordタイプのLDAPオブジェクト・クラス、またはその最上位の親で定義される必要があります。空の場合は、デフォルトのフェデレーションID属性はフェデレーション・レコードのDNとして使用されます。
様々なタイプのディレクトリ・サーバーの場合の、一意のフェデレーションID属性の例を示します。
Oracle Internet Directory: 空
Oracle Directory Server Enterprise Edition: 空
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スキーマに関する注意
フェデレーション・サーバーにより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です。
Oracle Directory Server Enterprise Edition 5.xを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaSunOne5.ldifです。
Oracle Directory Server Enterprise Edition 6.xを使用する場合は、$Oracle_Home/fed/setup/ldap/userFedSchemaSunOne6.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 Identity Federationがアイデンティティ・プロバイダ(IdP)とサービス・プロバイダ(SP)のどちらに構成されるかにより異なります。
IdPの場合、Oracle Identity Federationはリポジトリを使用して、ユーザーIDを検証し、プロトコル・アサーションを構築します。
SPの場合、次のようになります。
Oracle Identity Federationはリポジトリを使用して、受信したアサーションの情報を宛先のユーザーIDにマップし、その後で保護されたリソースへのアクセスを認可します。
新たにフェデレーションを作成する場合、Oracle Identity Federationは、リポジトリを使用してユーザーを特定し、新しいフェデレーションをそのユーザーのアカウントにリンクします。
LDAPリポジトリの場合の接続情報
Oracle Identity Federationをインストールする前に、リポジトリに関する次の情報を収集してください。
接続URL: LDAPのURLのスペース区切りリスト。
バインドDN。
Password
ユーザーID属性: ルックアップまたは認証手順でユーザーをマップするために使用する属性名。
ディレクトリ・サーバーのタイプごとのユーザーID属性の例を次に示します。
Oracle Internet Directory: uid
Oracle Directory Server Enterprise Edition: uid
Microsoft Active Directory: sAMAccountName
ユーザー説明属性。
このフィールドは、人間が読むことができるフェデレーション所有者識別子として使用するユーザー属性を参照します。この情報はフェデレーション・レコードに格納されます。
ディレクトリ・サーバーのタイプごとのユーザー説明属性の例を次に示します。
Oracle Internet Directory: uid
Oracle Directory Server Enterprise Edition: uid
Microsoft Active Directory: sAMAccountName
個人オブジェクト・クラス: LDAPサーバーでユーザーを表すLDAPオブジェクト・クラス。
様々なタイプのディレクトリ・サーバーの場合の個人オブジェクト・クラスの例を次に示します。
Oracle Internet Directory: inetOrgPerson
Oracle Directory Server Enterprise Edition: inetOrgPerson
Microsoft Active Directory: user
ベースDN: LDAPユーザー検索が実行されるノード。次に例を示します。
dc=us,dc=oracle,dc=com
最大接続数: Oracle Identity FederationによってLDAPサーバーに作成される同時接続数の最大値です。
接続待機タイムアウト: Oracle Identity FederationによってLDAPサーバーに開かれた接続数が最大値に達した場合に、接続が利用可能になるまで待機する秒数の最大値です。
RDBMSリポジトリの場合の接続情報
Oracle Identity Federationをインストールする前に、リポジトリに関する次の情報を収集してください。
JNDI名: ユーザーを認証またはロケーティングするためにOracle WebLogic Serverに構成されている、RDBMSを参照するデータソースを参照します。Oracle Identity Federationをインストールした後で、このデータソースを定義しないとユーザーを認証できません。
ログイン表: 認証とルックアップのために使用される、ユーザー情報を含むRDBMS表。
ユーザーID列: ユーザー識別子を含むログイン表のRDBMS列。
ユーザー説明属性: このフィールドは、人間が読むことができるフェデレーション所有者識別子として使用するユーザー属性を参照します。この情報はフェデレーション・レコードに格納されます。
Oracle Identity Federationは、フェデレーション・セッション/プロトコルの状態に使用する一時セッション・データ・ストアやメッセージ・データ・ストアもメンテナンスします。このデータは、メモリー内の表またはリレーショナル・データベースに格納できます。
高可用性とクラスタ化のサポートを使用するには、RDBMSのセッション・データ・ストアおよびメッセージ・データ・ストアが必要です。
|
注意: Liberty 1.xのサポートは非推奨です。 |
Oracle Identity Federationには、次のコンポーネントが必要です。
Java 2 SDK Standard Edition (J2SE) Version 1.4.2(インストールにバンドル)。
Oracle WebLogic Server
ユーザーIDデータ・ストア。通常はLDAPディレクトリですが、オプションでデータベース・ストアにすることもできます。
|
関連項目: サポートされるストアの一覧など、詳細は、『Oracle Fusion Middlewareセキュリティ概要』を参照してください。 |
ユーザー・フェデレーション・データ・ストア用に次のリポジトリのいずれか。
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の不透明でない識別子(電子メール・アドレス、サブジェクトDNなど)では任意です。 |
Oracle Database for the RDBMS一時データ・ストア用に次のバージョンのOracle Databaseのいずれか。
Oracle Database 10.2.0.4以上
Oracle Database 11.1.0.7以上
Oracle Database 11.2.x
|
注意: 最新のバージョン情報については、認定マトリクスを確認してください。 |
プロキシ実装用のOracle HTTP Server。これはOracle Identity Federationでサポートされる唯一のプロキシ・サーバーで、インストールにバンドルされています。
Oracle Identity Federationを活用するフェデレーテッド・アイデンティティ・システムのデプロイを計画する場合、アーキテクチャに関係するパフォーマンス関連の考慮事項、選択肢およびトレードオフを把握する必要があります。
この項では、フェデレーテッド環境においてパフォーマンスに影響を与える様々な要因について検討し、スタンドアロンのOracle Identity Federationサーバーを使用する本番システム向けのハードウェア要件を見積もる際に役立つガイドラインを提供します。トピックは次のとおりです。
Oracle Identity Federationをデプロイする前に、フェデレーテッド認証設定におけるOracle Identity Federationのアーキテクチャとその役割を定義する必要があります。次の事項を決定する必要があります。
様々な信頼できるパートナでどのフェデレーション仕様が使用されるか。次のような選択肢があります。
SAML 2.0。SAML 1.xと比較すると、フローが追加されることによってパフォーマンス上の考慮事項がより重要になる可能性があります。
SAML 1.0および1.1
WS-Federation
パートナとのフェデレーションにどのプロファイルを使用するか。オプションには、ブラウザPOSTプロファイルまたはアーティファクト・プロファイル、WS-Federationパッシブ・リクエスタ・プロファイル、属性共有、その他があります。
どのトランスポート・セキュリティ・プロトコルおよび証明書を使用するか。アサーションは署名されるか。
Oracle Identity Federationが果す役割は何か。オプションは次のとおりです。
アイデンティティ・プロバイダ(IdP)(ソース・ドメイン)
サービス・プロバイダ(SP)(宛先ドメイン)
IdPおよびSPの両方
どのタイプ(およびどのベンダー)の認可IDリポジトリがインストールされるか。
|
注意: 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を使用する場合、次に示すアクセス・サーバーのサイジング考慮事項と同様、アクセス・ゲートのパフォーマンス上の考慮事項が適用されます。
http://www.oracle.com/technology/products/id_mgmt/pdf/wp-oracle-idm-sizing-considerations.pdf
パフォーマンスを向上させるために、一時データ・ストアをメモリー内に置くようにします。
SAMLアサーションでは、デジタル署名/暗号化を使用するかどうかによってパフォーマンスが左右されます。これらの機能を削除するとパフォーマンスは向上しますが、IdPおよびSPの通信がインターネット上で行われる場合は、削除しないことをお薦めします。
LDAPサーバー
RDBMS(一時セッション・データおよび構成向け)
リモート・プロバイダ(Oracle Identity FederationがSOAPプロトコルを使用して相互に直接通信する場合)
パフォーマンスおよび高可用性を向上させるには、複数のOracle Identity Federationサーバーのスケーリングおよびロード・バランシングを行うことも考慮してください。ロード・バランシング・ソリューションを実装すると、使用するサイトをバックアップおよびフェイルオーバーによって保護できます。
詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
本番環境における他のサーバーの存在も考慮します。具体的には、次のように考慮します。
Oracle WebLogic Serverをチューニング、およびOracle Identity Federationへの適切な接続制限を設定します。次のことが可能です。
メモリーの使用量、プロセスの数などの典型的な構成パラメータを使用してOracle WebLogic Serverをチューニングします。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』を参照してください。
Oracle Identity FederationがリモートのHTTPサーバーおよびRDBMSサーバーと通信する際に使用するHTTP/JDBC接続の最大数を指定します。詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。
Oracle Identity Federationが活用するOracle HTTPサーバーをチューニングします。
|
関連項目: チューニングおよびパフォーマンスのガイドラインは次を参照してください。
|
Oracle Identity Federationは、リクエストを処理する際にHTTPセッション状態を使用します。Oracle WebLogic Serverのセッション永続性を構成するには、『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「セッションとセッション永続性の使用」の章を参照してください。
デフォルトでは、メモリーベースのストレージが使用されます。Oracle WebLogic Serverの実行中に十分なヒープサイズを確保できない場合、高負荷の状況でサーバーのメモリーが不足するおそれがあります。
ファイアウォール、プロキシ・サーバーなどの追加のセキュリティ対策の導入や、SSL認証の使用によりフェデレーテッド・トランザクションに追加のステップが加わると、パフォーマンスに影響が及ぶ場合があります。
図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向けに認定されたプラットフォームのリストは、認定マトリクスを参照してください。
フェイルオーバーのシナリオでは、必要なマシン数が倍になります。冗長性を確保するため、2つ以上のOracle Identity Federationサーバーを別個のマシン上で使用します。
サーバーのフットプリント:
2から4GBのメモリー(4GBを推奨)
マシンごとに2つ以上のCPU
プロキシ・サーバーを使用する場合は、ベンダー固有のサイジングの推奨に従ってください。
図2-12は、SPモードでのOracle Identity Federationデプロイメントに対して推奨されるトポロジを示しています。ここでは、Oracle HTTPサーバーがWebGateによって保護されたプロバイダ・アプリケーションを提供します。
次のチェックリストはOracle Identity Federationインストールを計画するための主要な項目を要約したもので、デプロイメントを行うための第1歩となります。
|
注意: Liberty 1.xのサポートは非推奨です。 |
表2-4 実装チェックリスト
| 計画項目 | 推奨値/提案値 | 注意 |
|---|---|---|
|
アーキテクチャ/基本構成 |
||
|
設定するロール |
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にするか、メモリー内にするか指定します。 |
|
|
構成データ・ストア |
一時データのリポジトリを、RDBMSにするか、ファイルにするか指定します。 |
|
|
IdPのプロファイルとバインディング |
有効な組合せ1つに1行を使用します。 |
|
|
SPのプロファイルとバインディング |
有効な組合せ1つに1行を使用します。 |
|
|
SSL暗号化 |
||
|
有効/無効 |
||
|
SSL用Javaキーストア |
SSL設定の詳細は、第8.1項「Oracle Identity FederationでのSSLの構成」を参照してください。 |
|
|
証明書 |
||
|
署名 |
署名キーのペアに対するPKCS #12ウォレットの位置を指定します。 |
|
|
暗号化 |
暗号化キーのペアに対するPKCS #12ウォレットの位置を指定します。 |
|
|
パフォーマンス計画 |
||
|
トポロジ、リファレンス・サーバーのフットプリント |
パフォーマンス上のヒントおよび推奨事項は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。 |
脚注 1 フェデレーション・スキーマ更新の場合、接続URL、バインドDN、パスワード、ユーザー・フェデレーション・レコード・コンテキスト、LDAPコンテナ・オブジェクト・クラス(Microsoft Active Directory)および一意のフェデレーションID属性を収集します。
