| Oracle® Fusion Middleware Oracle Identity Federation管理者ガイド 11g リリース1(11.1.1) B66693-01 |
|
 前 |
 次 |
この章では、Oracle Identity Federationの構成タスクについて説明します。内容は次のとおりです。
Oracle Identity Federation管理者はサーバーの管理と運用に必要なデータを、サード・パーティ(他のプロバイダの管理者)、サード・パーティとのアグリーメント、ローカル構成の決定事項など、様々な情報源から取得します。管理者は、フェデレーション・サーバーのロードとメンテナンスを担当します。
大きく分けて、フェデレーション・サーバーは2つのカテゴリの詳細構成をメンテナンスします。
サーバー構成データ: 実行時のフェデレーション・サーバー・インスタンスの動作を規定するプロパティなど
ユーザー・フェデレーション・データ: 個別ユーザーのフェデレーテッドIDや使用方法の情報
|
注意: Liberty 1.xのサポートは非推奨です。 |
各Oracle Identity Federationインスタンスは2つのタイプの構成データをメンテナンスします。
プロトコル・データ。次のものが含まれます。
サーバー・インスタンス全体のプロパティ(ホスト名とポート、SSLが有効かどうか、署名および暗号化PKCS#12/JKSキーストアなど)。
サーバー・インスタンスがアイデンティティ・プロバイダとして動作しているときに、有効なフェデレーション・プロトコルをサポートする方法(セッション・タイムアウト、再認証タイムアウト、デフォルトのプロバイダIDなど)。
サーバー・インスタンスがサービス・プロバイダとして動作しているときに、有効なフェデレーション・プロトコルをサポートする方法。このケースでメンテナンスされるデータは、サーバーがアイデンティティ・プロバイダとして動作するときに格納されるデータに非常に類似しています。
このサーバーの信頼できるプロバイダであるピア・プロバイダに関する情報。信頼できるプロバイダの構成データには、次のものが含まれます。
アサーションで使用する名前IDフォーマット
認証レスポンスとともに送信する属性
アサーションと認証リクエストの署名要件
優先バインディング
アサーションとアーティファクトの有効期間
その他の時間関連パラメータ(同期していないサーバーの間の許容時間差など)
アカウント・リンキング・パラメータ
構成設定とサーバーが生成するプロバイダ・メタデータの間に関係が存在する場合があることに注意してください。メタデータに影響を与える設定と与えない設定があります。たとえば、「セッション・タイムアウト」値の変更はメタデータに影響を与えませんが、「SOAPポート」の変更には、管理者が、他の信頼できるプロバイダにメタデータを再公開することが必要です。同様に、管理者はピア・プロバイダのメタデータに対する変更を認識している必要があります。
メタデータ・プロパティ
メタデータの署名
有効期間
サーバー・プロパティ
サーバー・ホスト名
サーバー・ポート
SOAPポート
IdpEnabled
SpEnabled
SSL有効
署名PKCS #12/JKSキーストア
暗号化PKCS #12/JKSキーストア
共通のIdPプロパティ
プロバイダID
SAML 2.0有効
共通のSPプロパティ
プロバイダID
SAML 2.0有効
属性リクエスタ・サービスの有効化
SAML 2.0 IdPプロパティ
プロトコル・プロファイルの有効化
フェデレーション終了有効
名前ID登録有効
属性レスポンダ有効
SAML 2.0 SPプロパティ
プロトコル・プロファイルの有効化
フェデレーション終了有効
名前ID登録有効
|
注意: Fusion Middleware Controlからメタデータを取得するには、「セキュリティおよび信頼」→「プロバイダ・メタデータ」の順に移動します。 |
IdPメタデータのURL: http(s)://hostname:port/fed/idp/metadata?version=version
SPメタデータのURL: http(s)://hostname:port/fed/sp/metadata?version=version
versionにはsaml20、saml11、saml10、lib11またはlib12を指定できます。
データ・ストアには各ユーザーのアイデンティティ・フェデレーション・データが格納されます。データ・ストアにはLDAPディレクトリまたはRDBMSを使用できます。ユーザーの基本参照情報の他、ユーザーに関連付けられた一意の各アイデンティティ・フェデレーションごとにレコードがあります。フェデレーション・レコードは次のものにより定義されます。
リモート・プロバイダ
名前識別子のタイプ(たとえば、電子メール・アドレスやDN)
プロトコル(たとえば、SAML 2.0)
これは、これらの3つの属性の組合せが一意であるかぎり、同一のリモート・プロバイダに対してユーザーが複数のアイデンティティ・フェデレーション・レコードを持つことができることを意味します。たとえば、ユーザーの最初のレコードがProviderX/myemail1/SAML 2.0の組合せ、2番目のレコードがProviderX/myemail2/SAML 2.0の組合せで識別されることがありえます。
同期
前述のとおり、フェデレーション・レコードはユーザーごとに独立して格納され、一意のユーザー属性(DN、ユーザー名など)を使用してユーザー・データ・ストアのユーザー・レコードにリンクします。
ユーザーの一意属性値を変更するイベント、たとえば従業員がオフィスで新しい場所に移動し、DNが更新されたような場合などは、ユーザーのフェデレーションを削除して再確立する必要があります。
ユーザー・ストアのユーザーの属性値が変更された場合は、Fusion Middleware Controlの「アイデンティティ」ページなどからユーザーのフェデレーション・レコードを更新できます。
プロビジョニング解除
同様に、ユーザーのレコードが削除されてもフェデレーション・データは残ります。これは、ユーザーがプロビジョニング解除される場合、管理者がユーザーのフェデレーション・データを確実に削除する必要があることを意味します。
|
注意: この状況でフェデレーション・データを削除しない場合、セキュリティ上の問題が発生する可能性があります。たとえば、新しいユーザーがそれ以後に同一の一意属性値（たとえば、同一のDNまたはユーザー名）でプロビジョニングされたとします。以前のユーザーのアカウント・リンクが残されていた場合、それを新しいユーザーが引き継いでしまう可能性があります。 |
フェデレーション・データは次の方法で削除できます。
LDAPサーバーまたはデータベースの管理ツールを使用します。Oracle Internet Directoryに格納されたデータの詳細は、『Oracle Identity Managementユーザー・リファレンス』を参照してください。
Oracle Identity Federationに用意されているコマンドライン・ユーティリティを使用します。詳細は、第9章「Oracle Identity Federationコマンドライン・ツール」を参照してください。
サーバー・プロパティには次のものがあります。
サーバーに対して次のタイプのプロパティが構成されます。
基本的な接続パラメータ
暗号化設定
ログアウト・オプション
接続パラメータ
次のパラメータを構成できます。
ホスト
Oracle Identity Federationインスタンスのホスト名です。
|
注意: このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。 |
サーバーのホストまたはポートを変更する場合は、仮想ホスト名またはプロキシ・サーバー・ホスト名を定義するか、サーバーのホスト・プロパティを変更します。
ポート
Oracle Identity Federationがリスニングするポートです。
|
注意:
|
「SSL有効」ボックスを選択すると、Secure Sockets Layer(SSL)暗号化が有効になり、サーバーでHTTPSモードでのリスニングが可能になります。
|
注意:
|
「強制SSL」ボックスを選択すると、サーバーとの通信が強制的にHTTPSモードで行われます。HTTPSモードで実行されている場合、Oracle Identity Federationでは着信接続がSSLで実行されているかチェックされます。HTTPSモード以外の場合、サーバーはSSLをサポートしているURLにユーザーをリダイレクトします。このURLは、ホスト名およびポートの各プロパティ、およびリクエストされたURLで作成されています。
SOAPポート
Oracle Identity FederationがSOAPメッセージをリスニングするポートです。
|
注意:
|
「SSL有効」ボックスを選択すると、Secure Sockets Layer(SSL)暗号化が有効になり、サーバーでHTTPSモードでのリスニングが可能になります。
|
注意:
|
「強制SSL」ボックスを選択すると、サーバーとの通信が強制的にHTTPSモードで行われます。HTTPSモードで実行されている場合、Oracle Identity Federationでは着信接続がSSLで実行されているかチェックされます。HTTPSモード以外の場合、サーバーはSSLをサポートしているURLにユーザーをリダイレクトします。このURLは、ホスト名およびポートの各プロパティ、およびリクエストされたURLで作成されています。
「クライアント証明書が必要」を選択すると、すべての着信SOAP接続で強制的にSSLクライアント認証が行われます。
サーバー・クロック・ドリフト
Oracle Identity Federationと、そのピア・サーバーとの間で許容される時間の誤差です。デフォルトは600秒です。
セッション・タイムアウト
このパラメータは、認証されたセッションがアクティブである期間を秒単位で指定するために使用されます。アクティブな期間を過ぎるとセッションは非アクティブになり、ユーザーは再認証を受ける必要があります。デフォルト値は7200秒です。
このパラメータがどのように使用されるかはサーバーのロールと問題のセッションの性質に依存します。
シナリオ1: ローカルに認証されたユーザー
ユーザーをローカルに認証できるのは次の場合です。
Oracle Identity FederationがIdPとして動作している場合
Oracle Identity FederationがSPで、新しいフェデレーションが作成されたため、ユーザーに対して資格証明を求める必要がある場合
この場合、認証されたセッションの有効期間は、「セッション・タイムアウト」パラメータの値に設定されます。
シナリオ2: 既存のフェデレーション
Oracle Identity Federationが既存のフェデレーションに対してSPとして動作している場合、サーバーは、ユーザーと認証情報が含まれているSAMLアサーションをIdPから受信します。アサーションにはReauthenticateOnOrAfter属性が含まれることがあります。この属性は、この属性が指定する期間が過ぎたら、このユーザーは再認証が必要であることをOracle Identity Federationに対して示しています。
この場合、SPとして動作するOracle Identity Federationサーバーが、認証されたセッションの有効期間を、Session Timeoutパラメータと、ReauthenticateOnOrAfterアサーション属性の、いずれか少ない方に設定します。
|
注意: Oracle Identity Federationがユーザー・データ・ストアとしてOracle Access Managerを使用する場合、セッション・タイムアウトはユーザー・セッションに影響しません。Oracle Access Managerでは、セッション・タイムアウトは、アクセスされたリソースを保護しているAccessGateの構成によって決定されます。 |
リクエスト・タイムアウト
Oracle Identity Federationから送信するリクエストの有効期間です(単位は秒)。デフォルトは120秒です。
暗号化設定
「デフォルトXMLデータ暗号化アルゴリズム」で、次の使用可能な暗号化アルゴリズムのいずれかを選択します。
AES-128 CBC
Triple DES CBC
AES-192 CBC
AES-256 CBC
|
注意: AES-128 CBC以外の暗号化方式では、JCE暗号化パッケージのインストールが必要です。第8.3項「Oracle WebLogic ServerでのJCEポリシー・ファイルの設定」を参照してください。 |
ログアウト・オプション
次のログアウト・オプションのいずれかを構成できます。
エラーでの失敗
グローバル・ログアウト・フローでエラーが発生すると、Oracle Identity Federationは操作を中断してエラーをスローするか、ログアウト操作を継続して終了させます。
ステータス・リターン
戻る: 有効な場合に、/fed/user/logout URLにアクセスしてOracle Identity Federationのログアウト操作が開始されると、サーバーはログアウト操作の終了時にユーザーをreturnURLにリダイレクトし、ログアウト操作の結果を示す問合せパラメータをそのURLに追加します。
問合せパラメータ名はorafed_slostatusです。また、指定できる値は次のとおりです。
0: 成功
1: 失敗
ローカルのみログアウト
有効な場合は、Oracle Identity Federationは、ユーザーのログアウト処理実行時に、WS-Fed/SAMLログアウト・プロトコルを呼び出しません。かわりに、認証エンジンと、IDおよびアクセス管理フレームワークからのユーザーのログアウトのみが記録され、Oracle Identity Federationセッションが破棄されます。
パラレル・ログアウト
デフォルトでは、Oracle Identity FederationはSAML/WS-Fedグローバル・ログアウト操作実行時に、ログアウトが必要なすべてのプロバイダに対してユーザーを順次にリダイレクトします。この操作には時間がかかることがあります。また、プロバイダからの応答が得られず、任意のポイントでログアウト・フローが失敗すると、ログアウト・フローは終了しません。「パラレル・ログアウト」を有効にすると、ユーザーにはOracle Identity Federationによってフレームが含まれるページが表示され、それぞれのフレームが1つの特定のプロバイダに対してSAML/WS-Fedログアウト処理を実行します。これにより、ログアウト・フローのグローバル・パフォーマンスを向上させ、処理の中断を最小限に抑えることができます。
アウトバウンドSOAP接続
次のパラメータを構成できます。
最大SOAP接続数
サーバーごとの最大SOAP接続数
Oracle Identity Federationは、各種バインディング、中でもSOAPバインディンを使用して、リモートSAMLサーバーと通信できます。Oracle Identity Federationは、SOAPプロトコルを使用してリモート・サーバーにメッセージを送信する必要がある場合、接続を直接オープンしてSOAPメッセージを送信します。
Oracle Identity Federationでは、SOAPメッセージの送信時にオープンできる最大同時接続数、および特定のプロバイダへのSOAPメッセージの送信時にオープンできる最大同時接続数を構成できます。
HTTPプロキシ設定
このセクションは、送信SOAP接続でプロキシを使用するようにOracle Identity Federationを構成するために使用します。
プロキシ・ホスト: プロキシ・ホスト名。
プロキシ・ポート: プロキシ・ポート番号。
ユーザー名: プロキシへの接続時に使用するユーザー名。
パスワード: プロキシへの接続時に使用するパスワード。
非プロキシ・ホスト: プロキシを使用しないホストのリスト。複数のホストを指定する場合は、「;」で区切ります。
IdPの有効化
サーバーをIdPとして有効にするには:
「アイデンティティ・プロバイダの有効化」ボックスを選択します。
「プロバイダID」を指定します。
Oracle Identity FederationインスタンスのURIです。URLの場合は、実際のリソースを参照している必要があります。
|
注意: このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。 |
アサーション設定
次のようにアサーション・パラメータを指定します。
署名付アサーションの送信
アイデンティティ・プロバイダが発行するアサーションに署名を付けるかどうかを決定します。
アサーション有効期間
アイデンティティ・プロバイダが発行したアサーションの有効期間です(単位は秒)。有効期間外に処理されたアサーションは無効とみなされます。デフォルトは300秒です。
再認証までの時間
これがその有効期間で、これを過ぎるとサービス・プロバイダはユーザーを再度認証する必要があります(単位は秒)。アイデンティティ・プロバイダによる認証ステートメントを含んでいるアサーションが有効なのはこの期間だけで、それを過ぎるとユーザーは認証されていないものとみなされます。デフォルトは3600秒です。
プロトコル設定
次のようにプロトコル設定を指定します。
アーティファクト・タイムアウト
Oracle Identity Federationによって作成されるアーティファクト・オブジェクトの有効期間です(単位は秒)。デフォルトは300秒です。
XML署名に署名証明書を含める
選択した場合、送信メッセージのXMLデジタル署名要素にOracle Identity Federationの署名証明書が追加されます。これは、メッセージに含まれる署名証明書がOracle Identity Federationによって作成された署名であることをリモート・プロバイダで検証する必要がある場合に有用です。
共通ドメイン
アイデンティティ・フェデレーション・ネットワークに複数のアイデンティティ・プロバイダが含まれるとき、サービス・プロバイダは、プリンシパルが使用するアイデンティティ・プロバイダを決定するための方法を必要とします。そのため、フェデレーション・ネットワーク内でIdPとSPに共通のドメインを使用して、このドメインで書かれ、ユーザーがログインしているすべてのIdPが記載されたCookieがユーザーのブラウザに送信されます。このようなドメインは共通ドメインと呼ばれ、IdPを識別するCookieは共通ドメインCookieまたは導入Cookieと呼ばれます。
このIdPが概要Cookieを設定するように指定するには、「共通ドメインの有効化」を選択します。ローカル認証が行われるたびに、Oracle Identity Federationはユーザーを共通ドメインにリダイレクトし、ここでサーバーがその識別子をユーザーのブラウザの概要Cookieに追加できます。
共通ドメインを設定する場合、次のパラメータは必須です。
共通ドメインURL
アイデンティティ・フェデレーション・ネットワークに複数のアイデンティティ・プロバイダが含まれている場合、すべてのプロバイダに共通のドメインが、サービス・プロバイダがプリンシパルで使用されているアイデンティティ・プロバイダを判別するためのひとつの方法となります。認証が行われるたびに、ユーザーのブラウザ上のCookie（このドメインで書き込まれたもの）がIdP識別子で更新され、このCookieにすべてのユーザーのIdPがリストされサービス・プロバイダから読み取ることができます。
Oracle Identity FederationがIdP導入Cookieを読み取ったり設定したりする場所のURLを入力します。サーバーはこのURL上でリスニングし、リクエストを受け入れ、ユーザーのブラウザ上の導入Cookieを更新します。
共通ドメインを有効にする場合にのみ、この値を設定します。
名前
IdP概要Cookieに使用される共通ドメインです。概要Cookieでは、Cookieパラメータとして設定されます。この値は、ドット（.）で始まる、.domain.suffixの形式にする必要があります。デフォルト値は、.DOMAIN_TO_BE_SETです。
Cookie存続期間(日)
IdPが発行する共通ドメインCookieの存続期間(単位は日)です。このフィールドが0に設定されている場合(デフォルト)、共通ドメインCookieはセッションCookieです。
SSOユーザー・オプトイン/オプトアウト
そのユーザーにフェデレーテッド・シングル・サインオンの実行権限が付与(または拒否)されているかどうかを、ユーザーのディレクトリ・レコードの属性値に基づいて判断します。
ユーザー・セッション属性の欠落時に再認証
Oracle Identity FederationがIdPとして動作する場合、セッションに保存される属性を使用してアサーションに移入できます。セッション属性は次のように設定されます。
Oracle Identity Federationユーザー・セッションに格納される属性がカスタム認証エンジンによって提供される場合は、認証時に設定されます。
Oracle Identity Federationがサービス・プロバイダとして動作する場合は、アサーションの内容(名前ID、属性など)をユーザー・セッションに保存できます。デフォルトではそれらのデータは保存されません。
アサーションが作成されると、ユーザー・セッションから取得してアサーションに組み込む必要のある属性がOracle Identity Federation/IdPによってリストされます。アサーションに必要な一部の属性がユーザーセッションにない場合は、その属性を切り捨てるか、認証フレームワークを呼び出してそれらの属性をカスタム認証エンジンから取得できるようにOracle Identity Federationを構成できます。
この項では、IdPプロトコル固有のプロパティを構成する方法について説明します。
アサーション・プロパティ
このページのこの部分は、SAML 2.0プロトコルのアサーション名前識別子フォーマットをメンテナンスするために使用します。
次の情報を表で指定します。
有効: Oracle Identity FederationインスタンスがIdPモードでSAML 2.0名前識別子の値として使用するフォーマットを有効にするには、希望のフォーマットに対応するボックスを選択します。
デフォルト: ラジオ・ボタンを使用してデフォルトの名前IDフォーマットを選択します。
ユーザー・セッションから値を取得: このボックスを選択すると、対応する名前IDがマップされている属性を、ユーザーの認証時に作成されたセッション内で検索するように指定できます。
名前IDフォーマット: この列には使用可能な名前識別子フォーマットが表示されます。フォーマットは次のとおりです。
ユーザー属性マッピング: 選択した名前IDフォーマットの属性名を入力します。Oracle Identity Federationは、この属性名を使用して、ユーザー・データ・ストア(または「ユーザー・セッションから値を取得」が選択されている場合はユーザー・セッション)から、このフォーマットの名前IDを検索します。
|
注意: 「アサーション・サブジェクト名前IDフォーマット」表のユーザー属性を「orafed-userid」に設定すると、NameID要素を移入する際にユーザーIDを使用できます。これは、IdP用のユーザー・ストアが構成されておらず、使用可能なユーザー・ストア属性がない場合に特に役立ちます。 |
|
注意: この表は、送信アサーションの作成時に使用されます。Oracle Identity Federation/IdPは、名前IDフォーマットに応じて次のことを行います。
|
カスタム・フォーマット名: カスタム名前IDフォーマットを使用するアサーションの作成時に、名前IDで使用されるフォーマットです。
名前IDとしてのユーザーID
「アサーション・サブジェクト名前IDフォーマット」表のユーザー属性を「orafed-userid」に設定すると、NameID要素を移入する際にユーザーIDを使用できます。この機能は、IdP用のユーザー・ストアが構成されておらず、使用可能なユーザー・ストア属性がない場合に特に役立ちます。
その他のアサーションフィールド
表の下にあるフィールドは次のとおりです。
フェデレーション作成ユーザー承諾URL
ユーザーが新しいフェデレーションに同意する必要がある場合、これはユーザーがリダイレクトされる先のURLです。このための承諾ページをデザインする必要があります。
ユーザー承諾を強制
このボックスを選択すると、新しいフェデレーションを設定する際に承諾が必要になります。このボックスが選択されている場合、フェデレーション・サーバーにリダイレクトされたユーザーが続行するためには、リンクを明示的に承諾または拒否する必要があります。
暗号化された属性の送信
このボックスを選択すると、Oracle Identity Federationが暗号化された属性をピア・プロバイダに送信できるようになります。
暗号化された名前IDの送信
このボックスを選択すると、Oracle Identity Federationが暗号化された名前識別子をピア・プロバイダに送信できるようになります。
暗号化されたアサーションの送信
このボックスを選択すると、Oracle Identity Federationが暗号化されたアサーションをピア・プロバイダに送信できるようになります。
署名付きアサーションの送信
このボックスを選択すると、Oracle Identity Federationが署名付きのアサーションをピア・プロバイダに送信できるようになります。SAML 2.0プロトコルを使用する場合、アイデンティティ・プロバイダ - 共通タブで指定した値はこのページで指定した値で上書きされます。アイデンティティ・プロバイダ - 共通の値を上書きしたくない場合は、四角に入力できないように青い円をクリックすると、上の図で示したように四角を指す矢印が表示されます。
ユーザー承諾ページについて
ユーザーが新しいフェデレーションに同意する必要がある場合、ユーザーがリダイレクトされる承認ページを設計する必要があります。
サーバーはこのURLにいくつかの問合せパラメータを渡します。
表5-2 ユーザー承諾URLに渡されるパラメータ(SPグローバル)
| パラメータ | 説明 |
|---|---|
|
providerid |
ピア・プロバイダのID。 |
|
description |
ピア・プロバイダIDの説明。 |
|
returnurl |
承諾意思決定がなされた場合にユーザーをリダイレクトする先のURL。 |
|
refid |
returnurlに問合せパラメータとして渡されます。サーバーが承諾URLにリダイレクトされる前に実行していた操作をOracle Identity Federationが再開するには、このパラメータが必要です。 |
承諾URLページが戻り先URLにユーザーを導く際には(リンク、フォームの送信などの手段で)、表に説明があるrefidパラメータと、ユーザーが承諾したかどうかを示す承諾パラメータ(値はtrueまたはfalse)の、2つの問合せパラメータを渡す必要があります。
<%
String prefix = request.getContextPath();
String redirectURL = request.getParameter("returnurl");
String refID = request.getParameter("refid");
String providerID = request.getParameter("providerid");
String desc = request.getParameter("description");
%>
<HTML>
<BODY>
Do you consent to create a federation with <%=providerID%> (<%=desc%>):<br>
<form method="POST" action="<%=redirectURL%>">
<input type="checkbox" name="userconsent" value="true"/>I agree<br>
<input type="submit" value="OK" />
<input type="hidden" name="refid" value="<%=refID%>"/>
</form>
</BODY>
</HTML>
プロトコル設定
SAML 2.0プロトコルの有効化: このボックスを選択すると、SAML 2.0プロトコルが有効になります。
シングル・サインオン・プロトコルの有効化: このボックスを選択すると、シングル・サインオン・プロトコルが有効になります。
名前ID管理プロトコルの有効化: 終了
このボックスを選択すると、フェデレーション終了機能が有効になります。
|
注意: このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。 |
名前ID管理プロトコルの有効化: 登録: このボックスを選択すると、NameID登録が有効になります。
属性問合せレスポンダの有効化
このボックスを選択すると、アイデンティティ・プロバイダを属性認証局として動作させることができます。
|
注意: このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。 |
属性レスポンスのアイデンティティ・フェデレーションの使用
このボックスは、このアイデンティティ・プロバイダ内で属性リクエストのユーザーをフェデレーテッド・アイデンティティを使用して検索する場合に選択します。この設定を使用する場合、ユーザーはフェデレーションIDを持っている必要があります。また、名前IDの値とフォーマットがAttributeQueryで指定されているサブジェクトの値とフォーマットに一致する必要があります。
このボックスを選択すると、属性認証局はまずフェデレーション・ストア内でユーザーを検索しようとします。レコードが見つからない場合は、ユーザー・データ・ストアの属性値によってユーザーを特定します。
このプロパティは、「Oracle Identity Federation設定」タブの「信頼できるプロバイダの編集」ページで上書きすることもできます。
認証問合せレスポンダの有効化
SAMLプロトコルでは、アイデンティティ・プロバイダを認証局として動作させることができます。サービス・プロバイダは認証問合せを認証局に送信することにより、「認証のためにこのオブジェクトに発行されたアサーションの内容」を問い合せることができます。認証局は、指定されたサブジェクトを認証するために以前に発行されたアサーションを指定して応答します。
このボックスを選択すると、アイデンティティ・プロバイダを認証局として動作させることができます。
|
注意: このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。 |
アサーションIDレスポンダの有効化
SAMLプロトコルでは、アイデンティティ・プロバイダをアサーションID認証局として動作させることができます。信頼できるサービス・プロバイダは、アイデンティティ・プロバイダが以前発行したアサーションの一意IDを提供するアサーションID認証局に対してアサーションIDのリクエストを送信できます。アサーションID認証局は、アサーションをリクエストのIDとともにアサーションを指定して応答します。
アイデンティティ・プロバイダをアサーションID認証局として動作させるには、このボックスを選択します。
|
注意: このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。 |
プロトコル・バインディングの有効化
ドロップダウンで、有効化するすべてのプロトコル・バインディングを選択します。
デフォルト・バインディング
アイデンティティ・プロバイダがリクエストまたはレスポンス(SSOレスポンスを除く)を送信する際に、優先バインディングが(名前ID管理プロトコル・メッセージなどで)指定されていない場合に、デフォルトとして使用するバインディングを選択します。
デフォルトSSOレスポンス・バインディング
アイデンティティ・プロバイダがSSOレスポンスを送信する際に、優先バインディングがAuthnRequestで指定されていない場合に、デフォルトとして使用するバインディングを選択します。
署名付を送信/要求するメッセージ
Oracle Identity FederationがIdPモードで送信するときに署名が必要なメッセージ、およびOracle Identity FederationがIdPモードで受信するときに署名付を要求するメッセージを指定します。
|
注意: 署名付AuthnRequestの要求プロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。 |
このページは、Oracle Identity Federationがアイデンティティ・プロバイダとして動作する場合に、SAML 1.0/SAML 1.1プロトコルを使用するよう構成する場合に使用します。このページには、アサーション設定用およびプロトコル設定用の表がそれぞれあります。
アサーション設定
この表には、構成可能な名前IDフォーマットが表示されます。次の情報を指定します。
有効: このボックスを選択すると、対応する名前IDフォーマットが有効になります。
デフォルト: ラジオ・ボタンを使用してデフォルトの名前IDフォーマットを選択します。
ユーザー・セッションから値を取得: このボックスを選択すると、対応する名前IDがマップされている属性を、ユーザーの認証時に作成されたセッション内で検索するように指定できます。
名前IDフォーマット: この列には使用可能な名前識別子フォーマットが表示されます。フォーマットは次のとおりです。
ユーザー属性マッピング: 選択した名前IDフォーマットの属性名を入力します。Oracle Identity Federationは、この属性名を使用して、ユーザー・データ・ストア(または「ユーザー・セッションから値を取得」が選択されている場合はユーザー・セッション)から、このフォーマットの名前IDを検索します。
署名付アサーションの送信: このボックスを選択すると、Oracle Identity Federationが署名付きのアサーションをピア・プロバイダに送信できるようになります。SAML 1.0またはSAML 1.1プロトコルを使用する場合、アイデンティティ・プロバイダ - 共通タブで指定した値はこのページで指定した値で上書きされます。アイデンティティ・プロバイダ - 共通の値を上書きしたくない場合は、四角に入力できないように青い円をクリックすると、上の図で示したように四角を指す矢印が表示されます。
プロトコル設定
この表は、プロトコル設定および関連属性を指定するために使用します。
次の情報を指定します。
プロトコル: 「SAML 1.1プロトコルの有効化」ボックスおよび「SAML 1.0プロトコルの有効化」ボックスのいずれかまたは両方を選択します。
シングル・サインオン・プロトコルの有効化: このボックスを選択すると、シングル・サインオン・プロトコルが有効になります。
属性問合せレスポンダの有効化: このボックスを選択すると、アイデンティティ・プロバイダを属性認証局として動作させることができます。
認証問合せレスポンダの有効化
SAMLプロトコルでは、アイデンティティ・プロバイダを認証局として動作させることができます。サービス・プロバイダは認証問合せを認証局に送信することにより、「認証のためにこのオブジェクトに発行されたアサーションの内容」を問い合せることができます。認証局は、指定されたサブジェクトを認証するために以前に発行されたアサーションを指定して応答します。
このボックスを選択すると、アイデンティティ・プロバイダを認証局として動作させることができます。
アサーションIDレスポンダの有効化
SAMLプロトコルでは、アイデンティティ・プロバイダをアサーションID認証局として動作させることができます。信頼できるサービス・プロバイダは、アイデンティティ・プロバイダが以前発行したアサーションの一意IDを提供するアサーションID認証局に対してアサーションIDのリクエストを送信できます。アサーションID認証局は、アサーションをリクエストのIDとともにアサーションを指定して応答します。
アイデンティティ・プロバイダをアサーションID認証局として動作させるには、このボックスを選択します。
デフォルトSSOレスポンス・バインディング: アイデンティティ・プロバイダがSSOレスポンスを送信する際に、優先バインディングがAuthnRequestで指定されていない場合に、デフォルトとして使用するバインディングを選択します。
署名付を送信/要求するメッセージ: Oracle Identity FederationがIdPモードで送信するときに署名が必要なメッセージ、およびOracle Identity FederationがIdPモードで受信するときに署名付を要求するメッセージを指定します。
このページは、Oracle Identity Federationがアイデンティティ・プロバイダとして動作する場合に、WS-Federation 1.1プロトコルを使用するよう構成する場合に使用します。
次の情報を指定します。
WSフェデレーション1.1プロトコルの有効化: このボックスを選択すると、プロトコルが有効になります。
SSOトークン・タイプ: ドロップダウン・ボックスを使用して、シングル・サインオン・トークン・タイプを選択します。
Microsoft Webブラウザ・フェデレーテッドSSOプロファイルの使用: このボックスを選択すると、Oracle Identity FederationでMicrosoft WS-Fedプロトコル仕様を使用できます。
このページは、OpenIDプロトコルをIdPモードで構成する場合に使用します。
フィールドは次のとおりです。
OpenID 2.0プロトコルの有効化: このボックスを選択すると、OpenID 2.0プロトコルが有効になります。
XRDSメタデータを使用したReturnTo URLの検証: このボックスを選択すると、XRDSを使用してReturnTo URL(認証が処理された後でサーバーがリダイレクトするURL)を検証できます。
レルムを使用したReturnTo URLの検証: このボックスを選択すると、OpenID認証リクエストで指定されたReturnTo URLを、IdPがレルムを使用して検証するように指定できます。
有効なセッション・タイプ: レルムを使用してReturnURLを検証する場合は、各ボックスを選択して特定のセッション・タイプを有効にするか、Allを選択してすべてのセッション・タイプを有効にします。
デフォルトのセッション・タイプ: レルムを使用してReturnURLを検証する場合は、ドロップダウンを使用してデフォルトのセッション・タイプを選択します。任意の有効なセッション・タイプを選択できます。
有効なアソシエーション・セッション・タイプ: 次に示す、OpenIDプロバイダでサポートされている有効なアソシエーション・タイプが表示されます。
暗号化なし
Diffie-Hellman SHA1
Diffie-Hellman SHA256
デフォルトのアソシエーション・セッション・タイプ: デフォルトのアソシエーション・セッション・タイプを指定します。
|
注意: セッション・タイプやアソシエーション・タイプを変更した場合は、Oracle Identity Federationサーバーを再起動する必要があります。 |
アソシエーション・タイムアウト(秒): アソシエーションの有効期間です(単位は秒)。
新しいフェデレーテッド・アイデンティティを作成するためにユーザー承諾を強制: このボックスを選択すると、新しいフェデレーションを設定する際に承諾が必要になります。
すべてのシングル・サインオン操作に対してユーザー承諾を強制: このボックスを選択すると、SSOに対して承諾が必要になります。
属性交換のあるシングル・サインオン操作に対してユーザー承諾を強制: このボックスを選択すると、ユーザーはOracle Identity Federation/IdPとRPの間でSSO処理が実行されるときには常に承諾を求められます。これによりユーザー属性がRPにリリースされます。
この機能に関連するフィールドは次のとおりです。
ユーザー承諾強制のWebコンテキスト: Oracle Identity Federationの組込みのOpenID承諾ページのかわりに使用されるOpenID承諾ページのWebコンテキストを入力します。入力した場合、Oracle WebLogic Serverにあるユーザー実装のページを参照します。
ユーザー承諾強制のWebパス
Provider Authentication Policy Extension (PAPE) 1.0の有効化: このボックスを選択すると、PAPE 1.0拡張が有効になります。この機能では、次の中から1つ以上を指定できます。
米国政府Level of Assuranceポリシーのサポート
Private Personal Identifier (PPID)ポリシーのサポート
米国政府OpenID Trust Level 1ポリシーのサポート
No Personally Identifiable Information (No PII)ポリシーのサポート
Oracle Identity Federationでは次のようにOpenID RPを定義できます。
特定の設定を定義できるフェデレーテッド・パートナ
一般的な属性マッピングを使用した未知のRP
一般OpenID RPを定義するには「作成」をクリックします。
この項では、Oracle Identity Federationにおいてサービス・プロバイダ(SP)のプロトコル固有のプロパティを編集および更新する方法を説明します。内容は次のとおりです。
この表では、すべてのプロトコルに共通のSPプロパティを構成します。
アサーション設定
アサーションのユーザー・アカウントへのマップを有効化: このボックスは、Oracle Identity Federationでアサーションをユーザー・アカウントにマップする場合に選択します。カスタムSPエンジンを実装してマッピングを行う場合は無効にします。
匿名ユーザーID: 受信したアサーションをユーザー・アカウントにマップできない場合に、SPエンジンに渡すユーザーIDを入力します。マップできない場合は、ユーザー・アカウントへのアサーションのマッピングが無効化されているか、アサーション内の名前IDのフォーマットが「transient」になっています。
不明な条件を無視: このボックスを選択すると、アイデンティティ・プロバイダから送信されたアサーションでサービス・プロバイダが認識できない条件を無視できます。
署名付アサーションが必要: このボックスは、アイデンティティ・プロバイダから受信するアサーションに署名が必要な場合に選択します。
プロトコル設定
デフォルトSSOアイデンティティ・プロバイダ: SSO処理の開始時に、優先アイデンティティ・プロバイダが指定されていない場合に、リクエストのデフォルトの送信先となるアイデンティティ・プロバイダを選択します。
非送信請求SSOリレー状態: Oracle Identity Federation SPが必須でないアサーションを受信すると、ユーザーはSSO処理に続いてアサーションで指定されたリレー状態に送られます。アサーションのリレー状態フィールドが空の場合、ユーザーのリダイレクトには非送信請求SSOリレー状態が使用されます。
XML署名に署名証明書を含める: XMLメッセージの署名時に、Oracle Identity Federationで署名に署名証明書を含める場合はこのボックスを選択します。
アイデンティティ・プロバイダ検出サービスの有効化
Oracle Identity Federationには、アイデンティティ・プロバイダ検出サービスと呼ばれるサービスがあります。このサービスでは、ユーザーをカスタム・ページにリダイレクトし、認証を受けるアイデンティティ・プロバイダをそのページでユーザーに選択させることができます。
アイデンティティ・プロバイダ検出サービスを有効にするには、このボックスを選択して、カスタム・ページのサービスURLを入力します。ユーザーはこのカスタム・ページで、使用するアイデンティティ・プロバイダを選択できます。
共通ドメインCookieサービスの有効化
IDフェデレーション・ネットワークに複数のアイデンティティ・プロバイダが含まれる場合、プリンシパルで使用されるアイデンティティ・プロバイダを決定する方法が、サービス・プロバイダで必要です。そのため、フェデレーション・ネットワーク内でIdPとSPに共通のドメインを使用して、このドメインで書かれ、ユーザーがログインしているすべてのIdPが記載されたCookieがユーザーのブラウザに送信されます。このようなドメインは共通ドメインと呼ばれ、IdPを識別するCookieは共通ドメインCookieまたは導入Cookieと呼ばれます。
このSPで導入Cookieを読み取るように指定するには、このボックスを選択して、Oracle Identity Federationは導入Cookieを読み取るサービスURLを入力します。
属性リクエスタ・サービスの有効化: このボックスを選択すると、このサービス・プロバイダを属性リクエスタとして動作させることができます。
|
注意: このプロパティはサーバー・メタデータに影響します。このプロパティを更新する場合は、すべての信頼できるプロバイダに、更新したメタデータを配布します。 |
属性リクエスタ・サービスの構成
デフォルト属性認証局: リクエストで属性認証局が指定されていない場合に、属性問合せのデフォルトの送信先となる属性認証局を選択します。
DNパターンから属性レスポンダへのマッピング: この表は、属性認証局にユーザーDNのパターンをマップするために使用します。任意のユーザーの属性問合せを送信すると、Oracle Identity FederationがユーザーのDNを確認し、DNとこの表のパターンを照合して、対応する属性認証局に属性問合せを送信します。ユーザーのDNと一致するパターンがない場合は、デフォルトの属性認証局が使用されます。
デフォルトでは、DNパターンの大/小文字は区別され、ユーザーDNとDNパターンの比較時には大/小文字が考慮されます。比較時に大/小文字を区別するには、WLST構成コマンドを次のように使用します。
setConfigProperty ('dnidpmapping','caseinsensitive','true','boolean')
比較時に大/小文字を区別する場合はtrueを、区別しない場合はfalseを使用します。
SSO認証メカニズムのアイデンティティ・プロバイダ
この表では、アイデンティティ・プロバイダに認証メカニズムをマップします。SSO処理の開始時にアイデンティティ・プロバイダが指定されていない場合、Oracle Identity Federationはこの表を確認して、リクエストされた認証メカニズムをアイデンティティ・プロバイダにマップし、このアイデンティティ・プロバイダに対してAuthnRequestを送信します。認証メカニズムをアイデンティティ・プロバイダにマップできない場合は、デフォルトのSSOアイデンティティ・プロバイダが使用されます。
このタブは、SAML 2.0プロトコルに従ってサービス・プロバイダ・モードで動作するOracle Identity Federationのプロパティをメンテナンスする場合に使用します。
アサーション設定
関連付けられたボックスを選択して、アサーション・マッピングの方法を次の中から選択します。
フェデレーテッド・アイデンティティ
属性問合せ
サブジェクトの名前ID
フェデレーテッド・アイデンティティを使用してユーザーをマップする場合は、「自動アカウント・リンクの有効化」というボックスを選択します。
属性問合せを使用してユーザーをマップする場合は、関連付けられているボックスに問合せ文字列を入力します。
サブジェクトの名前IDを使用してユーザーをマップする場合は、ボックスを選択して、「アサーション・サブジェクト名前IDフォーマット」という表から該当する名前IDフォーマットを選択します。表で次の情報を指定します。
Oracle Identity FederationインスタンスがSPモードでサポートするフォーマットを有効にするには、希望のフォーマットに対応する「有効」ボックスを選択します。
名前IDフォーマット: この列には、使用可能なSAML 2.0名前IDフォーマットが表示されます。
ユーザー属性マッピング: 選択した名前IDフォーマットの属性名を入力します。Oracle Identity Federationは、この属性名を使用して、ユーザー・データ・ストアから、このフォーマットの名前IDを検索します。
名前識別子のフォーマットは次のとおりです。
カスタム・フォーマット名: アサーションの処理時に、カスタム名前IDフォーマット・タイプにマップされるフォーマットの名前です。
また、Oracle Identity Federationでのマッピング・エラーの処理方法を指定する場合は、「ユーザー・マッピング失敗時のエラー」を選択します。
プロトコル設定
次の情報を指定します。
SAML 2.0プロトコルの有効化: このボックスを選択すると、SPに対してこのプロトコルが有効になります。
シングル・サインオン・プロトコルの有効化: このボックスを選択すると、シングル・サインオンプロトコルが有効になります。
名前ID管理プロトコルの有効化: 登録: このボックスを選択すると、NameID登録が有効になります。
フェデレーション終了プロトコルの有効化: このボックスを選択すると、フェデレーション終了プロトコルが有効になります。
この機能の説明は、第1.2.4.8項「フェデレーション終了プロファイル」を参照してください。
暗号化名前IDの送信: このボックスを選択すると、Oracle Identity Federationが暗号化された名前識別子をピア・プロバイダに送信できるようになります。
暗号化属性の送信: このボックスを選択すると、Oracle Identity Federationが暗号化された属性をピア・プロバイダに送信できるようになります。
フェデレーション作成を許可: このボックスを選択すると、フェデレーションの作成が可能になります。これは、永続名前IDフォーマットをリクエストするようにSPを構成する(後述を参照)場合は必須です。
ユーザー承諾を強制: このボックスを選択すると、新しいフェデレーションを設定する際に承諾が必要になります。フェデレーション・サーバーにリダイレクトされたユーザーが続行するためには、リンクを明示的に承諾または拒否する必要があります。
ユーザー承諾URL: フェデレーションの承諾を取得するためにユーザーに表示されるURLを入力します。
サーバーはこのURLにいくつかの問合せパラメータを渡します。
プロトコル・バインディングの有効化: ドロップダウン・リストを使用して、有効なバインディングを指定します。
デフォルト・バインディング: ピア・プロバイダにメッセージを送信する際に、可能な場合、使用する優先バインディングを指定します。有効な値は次のとおりです。
HTTPリダイレクト
HTTP POST
HTTP POSTシンプル署名
SOAP
デフォルトSSOリクエスト・バインディング: 認証リクエストをアイデンティティ・プロバイダに送信する際に、可能であればサービス・プロバイダが使用する優先バインディングを指定します。このサーバー・インスタンスがサービス・プロバイダとして動作している場合のみ使用します。有効な値は次のとおりです。
HTTPリダイレクト
HTTP POST
HTTP POSTシンプル署名
デフォルトSSOレスポンス・バインディング: アサーションをサービス・プロバイダに送信する際に、可能であればアイデンティティ・プロバイダが使用する優先バインディングを指定します。有効な値は次のとおりです。
アーティファクト
HTTP POST
HTTP POSTシンプル署名
デフォルト認証リクエスト名前IDフォーマット: リスト・ボックスを使用して認証リクエスト用のデフォルトの名前IDフォーマットを選択します。選択肢は次のとおりです。
X.509サブジェクト名
電子メール・アドレス
Windowsドメイン修飾名
Kerberosプリンシパル名
永続識別子
一時/単発識別子
未指定
SPにデフォルト認証リクエスト名前IDフォーマットが指定されていない場合、IdPはアサーションの作成時にデフォルト・アサーション名前IDフォーマット(たとえば、電子メール名前IDフォーマット)を使用します。
リクエスト認証コンテキスト・メカニズム: このリスト・ボックスでは、このサービス・プロバイダがアイデンティティ・プロバイダへのAuthnRequestで指定する認証メカニズムを選択します。
リクエスト認証コンテキストの比較:このリスト・ボックスでは、このサービス・プロバイダがアイデンティティ・プロバイダに送信するAuthnRequestで指定する認証コンテキストの比較を選択します。
署名付を送信/要求するメッセージ
この表は、サービス・プロバイダを構成して、プロバイダが署名付で送信するメッセージ・タイプや署名を要求するメッセージ・タイプを指定するために使用します。
|
注意:
|
このタブは、Oracle Identity Federation SAML 1.xのドメインの構成の詳細を指定するために使用します。
アサーション設定
次のマッピングの選択肢のいずれかを選択します。
属性問合せによるユーザーのマップ: このボックスを選択して、属性問合せを入力します。
名前IDによるユーザーのマップ: このボックスを選択して、「アサーション・サブジェクト名前IDフォーマット」という表から該当する名前IDフォーマットを選択します。
また、Oracle Identity Federationでのマッピング・エラーの処理方法を指定する場合は、「ユーザー・マッピング失敗時のエラー」を選択します。
「アサーション・サブジェクト名前IDフォーマット」表の使用
サブジェクトの名前IDによるアサーション・マッピングを選択した場合は、表で次の情報を指定します。
Oracle Identity FederationインスタンスがSPモードでSAML 1.1/1.0名前識別子フォーマットとしてサポートするフォーマットを有効にするには、希望のフォーマットに対応する「有効」ボックスを選択します。
名前IDフォーマット: この列には、使用可能なSAML 1.x名前IDフォーマットが表示されます。
ユーザー属性マッピング: 選択した名前IDフォーマットの属性名を入力します。Oracle Identity Federationは、この属性名を使用して、ユーザー・データ・ストアから、このフォーマットの名前IDを検索します。
名前識別子のフォーマットは次のとおりです。
プロトコル設定
次の情報を指定します。
SAML 1.1プロトコルの有効化: このボックスを選択すると、SPに対してこのプロトコルが有効になります。
SAML 1.0プロトコルの有効化: このボックスを選択すると、SPに対してこのプロトコルが有効になります。
プロトコル・バインディングの有効化: ドロップダウンを使用して、使用するバインディングを選択します。
署名付を送信/要求するメッセージ: この表は、サービス・プロバイダを構成して、プロバイダが署名付で送信するメッセージ・タイプを指定するために使用します。
|
注意: 「適用」をクリックすると構成の変更は保存されますが、変更内容をこのページで有効にするには、プロトコルのボックスを少なくとも1つは選択する必要があります。 |
このページは、Oracle Identity Federationがサービス・プロバイダとして動作する場合に、WS-Federation 1.1プロトコルを使用するよう構成する場合に使用します。
次の情報を指定します。
WSフェデレーション1.1プロトコルの有効化: このボックスを選択すると、プロバイダに対してWS-Federation 1.1プロトコルが有効になります。
リクエスト認証コンテキスト・メカニズム: このドロップダウンでは、認証リクエストでアイデンティティ・プロバイダに送信される認証メカニズムを選択します。
変更を保存するには「適用」を、画面を前の値に戻すには「元に戻す」をクリックします。
このページは、OpenIDプロトコルをSPモードで構成する場合に使用します。
アサーション設定
アサーション設定のフィールドは次のとおりです。
フェデレーテッド・アイデンティティによるユーザーのマップ: このボックスは、RPが着信アサーションをユーザー・レコードにマップする際にフェデレーテッド・アイデンティティを使用するように指定する場合に選択します。選択しない場合は、アサーション・データに基づいてユーザーが検索されます。
自動アカウント・リンクの有効化: このボックスは、フェデレーテッド・アイデンティティが存在しない場合に、RP/SPが着信アサーションをユーザー・レコードにマップするように指定する場合に選択します。マッピングではアサーション・データを使用します。
属性問合せによるユーザーのマップ: LDAP/RDBMS問合せによるアサーションとユーザーのマッピングを有効にするには、ボックスを選択して、関連付けられている「属性問合せ」フィールドを使用します。
ユーザー・マッピング失敗時のエラー: このボックスを選択すると、アサーション・データを使用して着信アサーションをユーザー・レコードにマッピングする際に失敗した場合は、401エラーが表示されます。選択しない場合は、RPはユーザーの認証、識別、プロビジョニングのために認証エンジンを呼び出し、呼出しが認証エンジンから戻った後で処理を再開します。(注意: 呼び出される認証エンジンは、フローを開始したSPに対して構成されている認証メカニズムで決まります)。
署名付アサーションが必要: RP/SPが着信アサーションに署名付を要求するかどうかを指定します。
プロトコル設定
プロトコル設定のフィールドは次のとおりです。
OpenID 2.0プロトコルの有効化: このボックスを選択すると、OpenID 2.0プロトコルが有効になります。
OpenIDプロバイダ検出の実行: このボックスは、RPがSSO処理を開始する際に、検出URLからOPを検出するように指定する場合に選択します。検出によって、OPでサポートされる機能が決まり、それに応じて認証リクエストが作成されます。検出が無効の場合は、OpenIDプロバイダのSSO URLを指定する必要があります。また、認証リクエスト・フォーマットはRP構成のみに基づきます。
ユーザー承諾を強制: このボックスを選択すると、IdP/OP、RP/SPおよびユーザーの間で新しいフェデレーション(つまり、新しいClaimedID)が作成されるときにユーザーは承諾を求められます。
デフォルト認証メカニズム: アサーションでPAPE認証ポリシーを使用する場合に、ローカル認証メカニズムを保持して、IdP/OPでユーザーを認証する際の認証方式として使用します。
有効なセッション・タイプ: ドロップダウンを使用して、アソシエーションの交換時に使用する有効なセッション・タイプをリストします。使用可能な値は次のとおりです。
暗号化なし
dh-sha1
dh-sha256
有効なアソシエーション・セッション・タイプ: ドロップダウンを使用して、OPでサポートされている有効なアソシエーション・タイプを指定します。使用可能な値は次のとおりです。
hmac-sha1
hmac-sha256
デフォルトのアソシエーション・セッション・タイプ: デフォルトのアソシエーション・セッション・タイプを、有効なタイプから指定します。
|
注意: セッション・タイプやアソシエーション・タイプを変更した場合は、Oracle Identity Federationサーバーを再起動する必要があります。 |
ユーザー承諾を強制: このボックスを選択すると、OP、RPおよびユーザーの間で新しいフェデレーション(つまり、新しいClaimedID)が作成されるときにユーザーは承諾を求められます。
ユーザー承諾強制のWebコンテキスト: Oracle Identity Federationの組込みのOpenID承諾ページのかわりに使用されるOpenID承諾ページのWebコンテキストを入力します。
アソシエーション開始時のDiffie-Hellmanパラメータの生成: このボックスは、タイプDH-SHA1またはDH-SHA256のアソシエーション開始時にDiffie-Hellmanパラメータを生成する場合に選択します。選択しない場合は、デフォルト値が使用されます。
Provider Authentication Policy Extension (PAPE) 1.0の有効化: このボックスを選択すると、PAPE 1.0拡張が有効になります。この機能では、次の中から1つ以上を指定できます。
米国政府Level of Assuranceポリシーのサポート
Private Personal Identifier (PPID)ポリシーのサポート
米国政府OpenID Trust Level 1ポリシーのサポート
No Personally Identifiable Information (No PII)ポリシーのサポート
属性共有は、X.509認証ベースのシステムにSAML属性共有プロファイルを実装する、Oracle Access ManagerとOracle Identity Federationの組合せ機能です。このプロファイルでは、保護されたリソースやサービスをリクエストするユーザーは、SSLクライアントのX.509証明書によって認証されますが、認可は、SAMLプロトコルを使用してユーザーの本拠である組織から取得されたユーザー属性で実行されます。ユーザーの本拠である組織がアイデンティティ・プロバイダ(IdP)、認証と認可を実行する組織がサービス・プロバイダ(SP)です。
この項では、Oracle Access ManagerとOracle Identity Federationで属性共有を構成する方法を説明します。内容は次のとおりです。
属性共有では、いくつかのOracle Access ManagerおよびOracle Identity Federationのコンポーネントを使用します。手順では、これらのコンポーネントがすでにインストールされ、通常動作するように構成されていると想定しています。
サービス・プロバイダのコンポーネント
SPコンポーネントには次のものがあります。
Access Manager WebGateを持つWebサーバー: 保護されたURLのHTTPリクエストでは、SSLクライアント証明書認証を実行し、Oracle Access Managerサーバーからのアクセス決定を実施します。
Oracle Access Manager: WebGateの認証と認可を実行します。属性共有機能では次のカスタム・プラグインを使用します。
authz_attribute認証プラグイン: 証明書のSubjectDNをauthz_attribute認可プラグインに渡します。
authz_attribute認可プラグイン: 属性リクエスタ・サービスを使用してユーザーのSubjectDNの属性値を取得し、その属性値でルール式を評価して、アクセスを許可するかどうかを決定します。
|
注意: 認証プラグインと認可プラグインは、同一のauthz_attributeライブラリを使用します。 |
Oracle Identity Federation属性リクエスタ・サービス: ユーザーのSubjectDNによって決定されたIdP属性レスポンダ・サービスにSAML 1.xまたはSAML 2.0属性問合せを送信し、取得した属性をauthz_attributeプラグインに返します。
IdPコンポーネント
Oracle Identity Federation属性レスポンダ・サービスまたは他のSAML 1.x/SAML 2.0準拠フェデレーション製品: SP属性リクエスタ・サービスからSAML属性問合せを受信し、指定ユーザーの属性を取得して（ローカル・ポリシー制御に従い）、属性を含むレスポンスを属性リクエスタ・サービスに返します。
ローカル・ユーザーによって保護されたリソースは、SAML属性検索で認可されたリモート・ユーザー権限の他に、サービス・プロバイダのOracle Access Managerユーザー・ディレクトリ内で定義された属性を使用してアクセスされることもあります。ここで説明したように構成されたローカル・ユーザーはauthz_attribute認証プラグインによって検出され、プラグインはFailureステータスを返します。後で説明する認証スキームは、このステータスを使用してユーザーのローカル・セッションを作成するため、ローカルLDAPフィルタを持つ認可ルールを適用できます。
Oracle Access Managerプラグインを構成するには、次の手順を実行します。
|
関連項目: Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。 |
AccessサーバーをインストールしたユーザーとしてAccessサーバー・ホストにログインします。
INSTALLDIR/oblix/config/attributePlug-inディレクトリがない場合は作成します。
INSTALLDIR/oblix/config/attributePlug-inディレクトリのconfig.xmlファイルを、ここに示したconfig.xmlファイルをテンプレートとして使用して編集または作成します。
必要に応じて、config.xmlファイルの属性と要素を編集します。
変更を有効にするためにアクセス・サーバーを再起動します。
config.xmlのサンプル
次にサンプルのconfig.xmlファイルを示します。
<Config LogLevel="audit" WaitTime="30" SizeLimit="0" MaxConnections="5"
InitialConnections="2"
Authn="basic" Username="coreid-as-ashost-6021" Password="xyzzy"
KeyPassword="abcde"
CacheTimeout="3600" MaxCachedUsers="1000" HeaderKeyLength="128"
RequestFormat="values">
<Mapping Local="true">
<DN>O=Company,C=US</DN>
</Mapping>
<Mapping URL="https://fed1.company.com:7499/fed/ar/soap">
<DN>O=PeerA,C=US</DN>
<DN>O=PeerB,C=US</DN>
</Mapping>
<Mapping URL="https://fed2.company.com:7499/fed/ar/soap"
RequestFormat="all">
<DN>O=PeerC,C=US</DN>
<DN>O=PeerD,C=US</DN>
</Mapping>
<Mapping URL="https://fed3.company.com:7499/fed/ar/soap">
<DN>C=US</DN>
</Mapping>
</Config>
構成パラメータ
構成パラメータは次のとおりです。
LogLevel: INSTALL_DIR/oblix/logs/authz_attribute_plug-in_log.txtに記録される情報の量を制御します。
off: エラーのみ記録します(デフォルト)。
audit: 認証リクエスト1件につき1行記録し、アクセス決定、ユーザーの証明書サブジェクトDNまたはローカル・ディレクトリDN、およびHTTP処理と、リクエストされたURLのローカル部分を示します。
debug: 問題のデバッグの役に立つ広汎な情報を記録します。
HTTP接続パラメータ(Oracle Identity Federation属性リクエスタ・サービスへのauthz_attributeプラグイン)。構成要素は次のとおりです。
WaitTime: レスポンスを待つ時間です(単位は秒)。デフォルトは30秒です。
SizeLimit: Oracleメッセージが送受信したHTTPメッセージの最大サイズです(デフォルトは無制限を表す0)。
MaxConnections: HTTP同時最大接続数です(デフォルトは5)。
InitialConnections: 初期に開かれた現在のHTTP接続数です(デフォルトは2)。
Oracle Identity Federation属性リクエスタ・サービスへのauthz_attributeプラグインの認証パラメータ。次のとおりです。
Authn: 認証方式
none: 認証なし
basic: ユーザー名とパスワードを使用するHTTP Basic認証(デフォルト)
cert: SSLクライアント証明書認証。key.pem、cert.pemおよびKeyPasswordを使用
Username: Basic認証のユーザー名です。
Password: Basic認証のパスワードです。
KeyPassword: SSLクライアント証明書認証の、key.pemのパスワードです。
属性値キャッシュ・パラメータ。次のとおりです。
CAcheTimeout: キャッシュされた属性値を保持する秒数。この時間が過ぎると値の更新を要求します(デフォルトは3600秒、つまり1時間。0はキャッシング無効)。
MaxCAchedUsers: キャッシュされた属性を持つユーザーの最大人数。キャッシュがいっぱいになると、期限内だが、使用された時期が最も古いエントリを取り消します(デフォルトは1000)。
属性リクエスタ・サービスURLへのサブジェクトDNのマッピング。各属性リクエスタ・サービスについて、次を指定します。
URL: サービス用。形式は%HTTP_PROTOCOL%://%OIF_HOST%:%OIF_PORT%/fed/ar/soap。各部分は次のとおりです。
%HTTP_PROTOCOL%: httpまたはhttps
%OIF_HOST%:%OIF_PORT%: Oracle Identity Federationのホストとポート
例: https://fed1.company.com:7499/fed/ar/soap
Local: trueの場合、一致しているユーザーはローカルで、属性リクエスタ・サービスは使用されません。trueの場合、URLパラメータは無視されます。
DN: ユーザーのSubject DNと照合するDNパターンを指定している1つ以上の要素。パターンは、DNの一番右の部分です。例: O=PeerA,C=US
属性問合せプロパティ: RequestFormatパラメータは、属性、および属性レスポンスで返される値を決定します。RequestFormatは認可ルールより優先されます。たとえば、認可ルールは属性と値の両方を指定しているが、RequestFormatが名前を指定している場合は、問合せでは値が省略されます。RequestFormatを指定するオプションは次のとおりです。
RequestFormat="values"
AttributeQueryには、認可ルールのruleExpressionから取得された属性名と値が含まれます。属性レスポンダは、AttributeQueryにあるユーザー属性と値のみを返します。これがデフォルトの設定です。この設定は、属性値のキャッシュに使用されるメモリーの量を最小にします(値をリクエストされるのは、認可で必要な場合のみ)。代償として、属性リクエストの回数が増大します。
RequestFormat="names"
AttributeQueryには、属性名は含まれますが、ruleExpressionから取得した属性名は含まれません。属性レスポンダは、名前付き属性のそのユーザーのすべての値を返します。ただし、属性値へのアクセスを制御しているあらゆるレスポンダ・ポリシーに従います。この設定は、「values」設定と「all」設定の中間に位置し、キャッシュ・メモリー使用量と属性リクエスト数のトレードオフを提供します。注意: この設定では、認可のためにどの属性値が必要か、AttributeQueryはIdPに明示しないため、セキュリティ上の理由で「values」設定より望ましい場合があります。
RequestFormat="all"
AttributeQueryには、属性名や値が含まれていません。属性レスポンダは、属性値へのアクセスを制御しているあらゆるレスポンダ・ポリシーに従うユーザーに、すべての属性と値を返します。この設定では、属性リクエストの回数は減少しますが、属性値が認可に使用される前に(使用されない場合もある)属性値のキャッシュに使用されるメモリー量は増大します。この設定は、属性レスポンダ・ポリシーが、SPが求める属性のみを返すように構成された場合に、最適に機能します。注意: この設定では、認可のためにどの属性が必要か、AttributeQueryはIdPに明示しないため、セキュリティ上の理由で「values」および「names」の設定より望ましい場合があります。
サンプルのconfig.xmlファイルに示されているように、RequestFormatパラメータは、デフォルトのリクエスト・フォーマットを設定する場合は<Config>要素に表示され、マッピングでカバーされるサブジェクトDNのリクエスト・フォーマットを設定する場合は<Mapping>要素に表示されます。
サンプル構成のマッピング例
以前に示したサンプルのconfig.xml構成ファイルの場合の、マッピング例を示します。
表5-7 config.xmlのマッピング例
| ユーザー・サブジェクトDN | URLへのマップ |
|---|---|
|
E=john.smith@company.com,CN=John Smith, OU=Development,O=Company,C=US |
ローカル |
|
E=betty.jones@peera.com.CN=Betty Jones,OU=Marketing,O=PeerA,C=US |
https://fed1.company.com:7499/fed/ar/soap |
|
E=sally.smith@peerd.com,CN=Sally Smith,OU=Marketing,O=PeerD,C=US |
https://fed2.company.com:7499/fed/ar/soap |
|
E=bill.jones@peerx.com,CN=Bill Jones,OU=Finance,O=PeerX,C=US |
https://fed3.company.com:7499/fed/ar/soap |
SSLとクライアント証明書認証の構成
HTTPSとSSLクライアント証明書認証を構成するには、次の手順を使用します。
HTTPSが、authz_attributeプラグインと、1つ以上の属性リクエスタ・サービスの間で使用される場合は、INSTALL_DIR/oblix/config/attributePlug-in/cacerts.pemに、信頼できるCAのリストを設定します。属性リクエスタ・サービスを認証する各CAごとに、PEMフォーマットされた証明書(-----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----を含む)をcacerts.pemに追加します。
SSLクライアント証明書認証が、authz_attributeプラグインと、1つ以上の属性リクエスタ・サービスの間で使用される場合は、key.pemファイルとcert.pemファイルを設定します。
次の手順に従って、Oracle Access Managerに含まれているopensslユーティリティを使用して、秘密鍵と証明書リクエストを生成します。
cd INSTALL_DIR/oblix/tools/openssl
openssl req -config openssl.cnf -newkey rsa:1024 -keyout../../config/attributePlug-in/key.pem -out../../config/attributePlug-in/req.pem
証明書を受信するには、CAにINSTALL_DIR/oblix/config/attributePlug-in/req.pemを送信します。
生成された証明書をINSTALL_DIR/oblix/config/attributePlug-in/cert.pemにコピーします。
プラグインがPEMファイルを確実に使用するようにするには、アクセス・サーバーを再起動します。
この項では、Oracle Access ManagerのスキームとポリシーをOracle Identity Federation用に構成する方法を説明します。これらの項目が含まれます。
次の手順を実行します。
|
関連項目: Webベースのユーザー・インタフェースの詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド10g』を参照してください。 |
マスター・アクセス管理者としてOracle Access Managerシステム・コンソールにログインします。「アクセス・システム構成」パネルの「認証管理」を選択します。
「追加」をクリックして、「新規認証スキームの定義」フォームに記入します。
名前: OIF属性共有。
説明: Oracle Identity Federation属性共有認可のためにSSLクライアント証明書認証を実行します。
レベル: 保護されたリソースの要件に基づいて設定します。あらゆるパスワード・スキームより高くします。
チャレンジ・メソッド: X509Cert。
チャレンジ・パラメータ: ssoCookie:Expires=Tue, 1 Nov 2005 00:00:00 GMT。
|
注意: このチャレンジ・パラメータは、保護されたリソースへのすべてのアクセスで、確実にこの認証方式が実行されるようにするために、ブラウザに強制的にObSSOCookieを破棄させ、Oracle Access Managerに再認証させます。 |
SSL必須: はい。
有効: いいえ(プラグインの構成前)。
「保存」をクリックして変更をコミットします。
「プラグイン」タブを選択し、「変更」をクリックします。表に示したプラグイン・パラメータを追加します。組込みプラグインを入力するには、ドロップダウン・リストからプラグイン名を選択します。カスタムのプラグインを入力するには、ドロップダウン・リストから「カスタム・プラグイン」を選択し、テキスト・ボックスにプラグイン名を入力します。プラグインをすべて追加したら、「保存」をクリックします。
| プラグイン名 | タイプ | プラグイン・パラメータ |
|---|---|---|
| authz_attribute | カスタム | (なし) |
| cert_decode | 組込み | (なし) |
| credential_mapping | 組込み | obMappingBase="MAPPING_BASE",obMappingFilter="(uid=OblixAnonymous)" |
| credential_mapping | 組込み | obMappingBase="MAPPING_BASE",obMappingFilter="(&(&(objectclass=PERSON_OBJECTCLASS) (USER_ATTRIBUTE=%certSubject.FIELD%))(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)))" |
次に例を示します。
| プラグイン名 | プラグイン・パラメータ |
|---|---|
| authz_attribute | |
| cert_decode | |
| credential_mapping | obMappingBase="o=Company,c=US", obMappingFilter="(uid=OblixAnonymous)" |
| credential_mapping | obMappingBase="o=Company,c=US", obMappingFilter="(&(&(objectclass=inetorgperson)(mail=%certSubject.E%)) (|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)))" |
「ステップ」パネルを選択します。次の手順を追加します。
| 手順名 | アクティブ・プラグイン | 目的 |
|---|---|---|
| SubjectDN | authz_attribute | 証明書からSubjectDNを抽出し、ユーザーがリモートとローカルのどちらであるかを判定します。 |
| RemoteUser | 最初のcredential_mapping | リモート・ユーザー用の匿名セッションを作成します。 |
| LocalUser | cert_decode、2番目のcredential_mapping | ローカル・ユーザー用のリアル・セッションを作成します。 |
「認証フロー」パネルを選択し、「変更」をクリックして、表に示したフローを設定します。注意: authz_attributeプラグインは、ユーザーがリモートである場合はSuccessを返し、ユーザーがローカルである場合はFailureを返します。
| 手順名 | 開始手順 | Successの場合の次の手順 | Failureの場合の次の手順 |
|---|---|---|---|
| デフォルトのステップ | いいえ | 停止 | 停止 |
| SubjectDN | はい | RemoteUser | LocalUser |
| RemoteUser | いいえ | 停止 | 停止 |
| LocalUser | いいえ | 停止 | 停止 |
「ステップ」パネルに戻り、使用しなかったデフォルト手順を削除します。
「一般」パネルに戻り、認証スキームを有効にします。
次の手順は、属性共有認可スキームを構成するために使用します。
|
関連項目: Webベースのユーザー・インタフェースの詳細は、Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイドを参照してください。 |
マスター・アクセス管理者としてOracle Access Managerシステム・コンソールにログインします。「アクセス・システム構成」パネルの「認可管理」を選択します。
「追加」をクリックして、「新規認可スキームの定義」フォームに記入します。
名前: OIF属性共有。
説明: Oracle Identity Federationを使用して、リモート・ユーザーがルール式を評価するための属性を取得するために使用します。
共有ライブラリ: oblix/lib/authz_attribute。
プラグインは管理コードです: いいえ。
管理コードのネームスペース:(なし)。
ユーザー・パラメータ: RA_SubjectDN(注意: authz_attributeプラグインによって設定されたSubjectDNヘッダーを取得する際に、「アクションのリバース」機能を使用します。)
必須パラメータ
名前: ruleExpression
値: (なし) (注意: 各アクセス・ポリシー認可ルールによりルール式が提供されます。)
「保存」をクリックして変更をコミットします。
次の手順は、属性共有プロファイルを使用するOracle Access Managerポリシーを構成するために使用します。
マスター・アクセス管理者または委任アクセス管理者としてOracle Access Managerにログインします。「ポリシー・ドメインの作成」を選択します。
「一般」パネル・フォームに次の内容を入力します。
名前: 適切な名前(たとえば、Oracle Identity Federation属性共有テスト)。
説明: 適切に入力します。
「保存」をクリックします。
リソース・パネルを選択して、1つ以上の保護するリソースのURL接頭辞を追加します(/attribute-testなど)。
「認可ルール」パネルを選択し、リモート・ユーザーに必要な属性の各セットごとに認可ルール(ルール式で表現)を追加します。
「カスタム認可スキーム」を選択し、「追加」をクリックします。
認可ルール・フォームに記入して、「保存」をクリックします。
名前: 適切な名前(たとえば、「Peer Marketing VP」)。
説明: 適切に入力します。
認可スキーム: OIF属性共有。
「プラグイン・パラメータ」パネルを選択し、「変更」をクリックして、表に示したruleExpressionパラメータを設定します。注意: 「=」、「!=」、「&」および「|」の左右にはスペースを配置できます。
| 要素 | 構文 | 意味 |
|---|---|---|
| none | 英数字と「-」、「_」および「.」の文字列 | ユーザーのアイデンティティ・プロバイダからリクエストする属性の名前。 |
| value | 文字列のいずれか1つか、anyまたはnull | 必須属性値です。Oracle COREid Access 7.0.4では、文字列はLatin-1文字に限定されます。Oracle Access Manager10.1.4以降では、文字列はUnicode文字を含むことができます。値anyは、属性のすべての値を取得し、照合します。NULL値は、xsi:nil="true"属性を持つSAML<属性>に一致します。 |
| comparison | name = value、name != value、または (式) | それぞれ、ユーザーが属性値を持っている場合/持っていない場合にtrue。 |
| and句 | comparison & comparison | 両方のcomparisonがtrueのときにtrueになります。 |
| or句 | comparison | comparison | どちらかのcomparisonがtrueのときにtrueになります。&は!よりも優先されます。 |
名前の例を次に示します。
title = "VP" & function = "Marketing"
title = "VP" | title = "Director"
title = "VP" & (function = "Marketing" | function = "Finance")
title = any & function = any
目的に応じて、認可ルール用の任意のタイミング条件またはアクションを設定します。
「一般」パネルに戻って、ルールを有効にします。
「認可ルール」パネルを選択して、ローカル・ユーザー属性に対する認可ルールを追加します。
「Oracle認可スキーム」を選択し、「追加」をクリックします。
認可ルール・フォームに記入します。
名前: 適切な名前(たとえば、「Company Marketing VP」)。
説明: 適切に入力します。
有効: はい。
優先を許可: いいえ。
「保存」をクリックします。
「アクセスの許可」パネルを選択し、「変更」をクリックして、ローカル属性用のLDAPフィルタを追加します。Oracle Access Manager Identity User ManagerのQuery Builderを使用できます(「構成」→「管理の委任」→「フィルタの作成」)。次に例を示します。
ldap:///o=Company,c=US??sub?(&(title=VP)(function=Marketing))
目的に応じて、認可ルール用の任意のタイミング条件またはアクションを設定します。
「一般」パネルに戻って、ルールを有効にします。
「デフォルト・ルール」パネルを選択して、デフォルト認証ルールを追加します。
名前: 適切に入力します。
説明: 適切に入力します。
認証スキーム: OIF属性共有。
「保存」をクリックします。
「認可条件式」パネルを選択して、デフォルト認証ルールを追加します。
上で定義されたとおりに適用可能なリモート認可ルールを選択し、「追加」(たとえば、Peer Marketing VP)をクリックします。
対応するローカル認可ルールがある場合は、「OR」を選択してローカル認可ルールを追加します。(たとえば、Peer Marketing VP | Company Marketing VP)。
「保存」をクリックします。
かわりに、保護されたURLのサブセットの認可式を使用して、ポリシー・ドメインにポリシーを追加できます。
次の手順は、サービス・プロバイダ・モードの属性リクエスタとしてOracle Identity Federationを構成するために使用します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
属性リクエスタ機能を有効にします。
「管理」→「サービス・プロバイダ」の順に移動します。
「属性リクエスタ・サービスの有効化」ボックスを選択し、「適用」をクリックします。
|
注意: 「属性リクエスタ・サービスの有効化」ボックスを選択すると、属性リクエスタ機能が有効になります。これにより、属性リクエスタ・サービスに関する情報を含むSPのメタデータも変更されます。ピア・プロバイダのサイトにあるメタデータを新しいバージョンで更新する必要があります。 |
SAML 1.xまたはSAML 2.0 IdPメタデータをアップロードするか、SAML 1.xプロバイダのエントリを手動で作成します。
「管理」→「フェデレーション」の順に移動します。
「追加」をクリックします。
SAML 1.xまたはSAML 2.0メタデータをアップロードする場合は、「メタデータのアップロード」を選択し、IdPメタデータの場所と追加説明を入力します。
SAML 1.xプロバイダを手動で追加する場合は、「信頼できるプロバイダの手動追加」を選択して、「プロバイダID」、プロバイダ・バーション(SAML 1.1またはSAML 1.0)を入力し、「アイデンティティ・プロバイダ/属性レスポンダ」を「プロバイダ・タイプ」として選択して、追加説明を入力します。
「OK」をクリックします。
DNからIdPへのマッピングを構成します。
「管理」→「サービス・プロバイダ」の順に移動します。
「属性リクエスタ・サービスの構成」をクリックします。
ドロップダウン・リストから「デフォルト属性認証局」を選択し、「適用」をクリックします。
マッピングを追加するには、次の操作を行います。
「追加」をクリックします。
DNまたはサブDNを入力します(たとえば、c=us)。
既存のIdPにこのDNまたはサブDNをマップします。
必要に応じて操作を繰返します。
「OK」をクリックします。
証明書検証を有効にして構成します。
「管理」→「セキュリティおよび信頼」の順に移動します。
「認証検証の有効化」を選択し、「適用」をクリックします。
信頼できるCAまたはCRLを追加するには、対応する表で「追加」をクリックし、CAまたはCRLの場所を選択します。(注意: 証明書検証が有効な場合は、署名を検証するために信頼できるCAが必要です)。
|
注意: DNからIdPへの構成および証明書検証の構成はオプションです。 |
SAML 2.0を使用する場合は、暗号化を有効にします。
「管理」→「サービス・プロバイダ」の順に移動します。
SAML 2.0タブの「プロトコル設定」で、次のようにします。
AttributeQueryの名前識別子を属性レスポンダに暗号化するには「暗号化された名前IDの送信」を選択します。
AttributeQueryの属性を属性レスポンダに暗号化するには「暗号化された属性の送信」を選択します。
「適用」をクリックします。
|
注意: 暗号化はオプションです。 |
属性リクエスタ・サービスはhttp://sp-hostname:port/fed/ar/soapから使用できます。
属性リクエスタ機能を有効にし、デフォルト属性認証局またはDNマッピングを設定した後、属性名マッピングおよび属性値マッピングを構成する必要があります。詳細は、第5.9.2項「マッピングおよびフィルタリングの構成」を参照してください。
その他の内容は次のとおりです。
プラグインとOracle Identity Federationの間でBasic認証を使用する場合は、Oracle Identity Federationインスタンス用のOHSのhttpd.confファイルに次の内容を追加する必要があります。
<LocationMatch "/fed/ar/soap">
AllowOverride None
AuthType Basic
AuthName "Restricted Files"
AuthUserFile /private/oifpassword
Require user alice
Order allow,deny
Allow from all
</LocationMatch>
htpasswdユーティリティを使用してユーザー・パスワード・ファイルを作成する必要もあります。上の例で、ユーザーとパスワードを含むAuthUserFileは/private/oifpasswordファイルを参照しており、このファイルでユーザーaliceが定義されています。
この例では、ユーザーaliceを追加することによってこのようなファイルを作成します。
$ORACLE_HOME/ohs/bin/htpasswd -c /private/oifpassword alice
Oracle HTTP Serverを使用せずにHTTP Basic認証を使用する場合は、第6.9.2項「HTTP Basic認証」を参照してください。
クライアント証明書認証を使用する場合は、第8.1項「Oracle Identity FederationでのSSLの構成」を参照してください。
次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
属性レスポンダ機能を有効にします。
「管理」→「アイデンティティ・プロバイダ」の順に移動します。
SAML 2.0または「SAML 1.x」タブで、「属性問合せレスポンダの有効化」を選択します。SAML 2.0を使用する場合に、IdPでフェデレーテッド・アイデンティティを使用して属性リクエストのユーザーを検索する場合は、「属性レスポンスのアイデンティティ・フェデレーションの使用」を選択します。この設定を使用する場合、ユーザーはフェデレーションIDを持っている必要があります。また、名前IDの値とフォーマットがAttributeQueryで指定されているサブジェクトの値とフォーマットに一致する必要があります。
「適用」をクリックします。
|
注意: 「属性レスポンダ有効」ボックスを選択すると、属性認証局機能が有効になります。これにより、属性認証局サービスに関する情報を含むIdPのメタデータも変更されます。ピア・プロバイダのサイトにあるメタデータを新しいバージョンで更新する必要があります。 |
名前IDフォーマットをマップします。
「管理」→「アイデンティティ・プロバイダ」の順に移動します。
SAML 2.0タブの「アサーション設定」で、使用するサブジェクト・フォーマットが有効で、ユーザー・リポジトリから正しいユーザー・エントリ属性にマップされていることを確認します。
dnを使用して、X.509サブジェクト名をエントリの識別名にマップするか、ユーザー・エントリの任意の属性を使用します。
|
注意: X.509サブジェクト名に選択された属性は、RFC2253で指定されたフォーマットに従って、クライアント証明書サブジェクトDNに正確に一致する必要があります。フォーマットに確信がない場合は、SPでテストを実行して、ログに記録される、SPから送信されたSubject NameIdentifierの値を確認します。 |
「適用」をクリックします。
SAML 1.xまたはSAML 2.0 IdPメタデータをアップロードするか、SAML 1.xプロバイダのエントリを手動で作成します。
「管理」→「フェデレーション」の順に移動します。
「追加」をクリックします。
SAML 1.xまたはSAML 2.0メタデータをアップロードする場合は、「メタデータのアップロード」を選択し、IdPメタデータの場所と追加説明を入力します。
SAML 1.xプロバイダを手動で追加する場合は、「信頼できるプロバイダの手動追加」を選択して、「プロバイダID」、プロバイダ・バーション(SAML 1.1またはSAML 1.0)を入力し、「サービス・プロバイダ」と「属性リクエスタ」を「プロバイダ・タイプ」として選択して、追加説明を入力します。
「適用」をクリックします。
SP属性リクエスタの属性マッピングを構成します。
「管理」→「フェデレーション」の順に移動します。
SPの「属性リクエスタ」エントリを選択して、「編集」をクリックします。
「手動更新」を選択し、「Oracle Identity Federation設定」で属性マッピングおよびフィルタの編集をクリックします。
属性マッピングを追加するには、次の操作を行います。
「追加」をクリックします。
ユーザー・リポジトリ属性名を「ユーザー属性名」列に入力します。
「アサーション属性名」に、属性を参照するために、AttributeQueryまたはアサーションで使用する識別子を入力します。
「フォーマットまたはネームスペース」を入力します(使用する場合)。これは、バージョンに応じてSAML属性のフォーマットまたはネームスペースを指定するために使用されるオプションのフィールドです。
- SAML 1.xの場合、このフィールドの値を使用してSAML属性のネームスペースを設定します。
- SAML 2.0の場合、この値を使用してSAML属性のNameFormatを設定します。このフィールドが空の場合、SAML属性のNameFormatはurn:oasis:names:tc:SAML:2.0:attrname-format:basicに設定されます。空でない場合、このフィールドに指定した値がNameFormatに保持されます。
他の属性のマッピングを追加するには、操作を繰り返します。
「OK」をクリックします。
|
注意: Oracle Identity Federationを使用するSPの場合、第5.6.4.3項「属性共有を使用するOracle Access Managerポリシーの構成」で設定したように、アサーション属性名はruleExpressionでの属性名により決定されます。属性名はIdPとSPで一致している必要があります。 |
証明書検証を有効にして構成します。
「管理」→「セキュリティおよび信頼」の順に移動します。
「認証検証の有効化」を選択し、「適用」をクリックします。
信頼できるCAまたはCRLを追加するには、対応する表で「追加」をクリックし、CAまたはCRLの場所を選択します。(注意: 証明書検証が有効な場合は、署名を検証するために信頼できるCAが必要です)。
|
注意: 証明書検証の構成はオプションです。 |
SAML 2.0を使用する場合は、暗号化を有効にします。
「管理」→「サービス・プロバイダ」の順に移動します。
SAML 2.0タブの「プロトコル設定>」で、次のようにします。
AttributeQueryの名前識別子を属性レスポンダに暗号化するには「暗号化された名前IDの送信」を選択します。
AttributeQueryの属性を属性レスポンダに暗号化するには「暗号化された属性の送信」を選択します。
「適用」をクリックします。
|
注意: 暗号化はオプションです。 |
属性レスポンダ機能を有効にした後、次を構成する必要があります。
送信対象の属性
属性名マッピング
属性値マッピング
属性値フィルタ
詳細は、第5.9項「属性マッピングおよびフィルタリングの構成」を参照してください。
サーバーのSSLを構成するには、第8.1項「Oracle Identity FederationでのSSLの構成」を参照してください。
シングル・サインオン処理時に、必要に応じて、アイデンティティ・プロバイダによりサービス・プロバイダが使用する認証アサーションに属性を含めることができます。
アサーションでの属性の送信を有効にするには、次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「フェデレーション」の順に移動します。
属性共有を構成するサービス・プロバイダを選択し、「編集」をクリックします。
「手動更新」を選択します。
「Oracle Identity Federation設定」タブで、「シングル・サインオンの属性の有効化」を選択します。
その下にあるボックスを選択して、アサーションで送信する属性の名前IDフォーマットを指定します。
「適用」をクリックします。
「シングル・サインオンの属性の有効化」ボックスを選択した後、次を構成する必要があります。
送信対象の属性
属性名マッピング
属性値マッピング
属性値フィルタ
詳細は、第5.9項「属性マッピングおよびフィルタリングの構成」を参照してください。
この項では、Oracle Identity Federationの属性リクエスタ・サービス・インタフェースについて説明します。内容は次のとおりです。
属性リクエスタ・サービスには、SOAP POSTプロトコルを使用したリクエスト/レスポンス・インタフェースが用意されています。このサービスは、X.509認証ベースの属性共有プロファイルをサポートしており、SAML <AttributeQuery>表記規則に従っています。
このサービスを起動して、samlp:AttributeQueryメッセージをリモートアイデンティティ・プロバイダに送信できます。
Webサービス・クライアントがAttributeRequestをOracle Identity Federation/属性リクエスタ・サーバーに送信するときに実行される手順は、次のとおりです。
Webサービス・クライアントは、SOAPプロトコルを使用してAttributeRequestメッセージを送信します。
Oracle Identity Federationは、リクエストで指定されたIdP、またはAttributeRequestに含まれるSubjectに基づいて、受信AttributeRequestメッセージを処理し、SAML AttributeQueryの送信先のIdPを選択します。
Oracle Identity Federationは、特定のリモートIdPに対して、AttributeRequestにリストされているオプションの属性値の属性値マッピングを適用します。
Oracle Identity Federationは、特定のリモートIdPに対して、AttributeRequestにリストされているオプションの属性の属性名マッピングを適用します。
Oracle Identity Federationは、AttributeQueryをリモートIdPに送信します。
Oracle Identity Federationは、IdPによって送信された属性とともに、アサーションが含まれるレスポンスを受信します。
Oracle Identity Federationは、特定のリモートIdPに対して、アサーションのAttributeStatementにリストされている属性名の属性名マッピングを適用します。
Oracle Identity Federationは、特定のリモートIdPに対して、アサーションのAttributeStatementにリストされている属性値の属性値マッピングを適用します。
Oracle Identity Federationは、AttributeResponseメッセージを構築し、これをSOAPレスポンス・メッセージでWebサービス・クライアントに戻します。
AttributeRequestメッセージにより、ユーザーの属性データに対するリクエストを発行します。AttributeRequestでは、次の入力を指定します。
Subject: ユーザーを表す文字列。これは必須入力です。
Subject Format: サブジェクト文字列がどのようにユーザーを表すかを指定するURI。指定しない場合は、フォーマット「oracle:security:nameid:format:x509」が使用されます。有効なフォーマットは次のとおりです。
oracle:security:nameid:format:x509: 名前IDがサブジェクトDNであることを示します。
oracle:security:nameid:format:entity: 名前IDが、SAMLサービスを提供するエンティティの識別子であることを示します。この名前IDフォーマットは、SAML 2.0プロトコルのみに適用されます。
oracle:security:nameid:format:emailaddress: 名前IDが電子メール・アドレスの形式であることを示します。
oracle:security:nameid:format:windowsdomainqualifiedname: 名前IDがWindowsドメイン修飾名であることを示します(Windowsドメイン修飾名は「DomainName\UserName」という形式の文字列です。DomainNameと「\」は省略できます)。
oracle:security:nameid:format:kerberos: 名前IDがname[/instance]@REALMというフォーマットを使用したKerberosプリンシパル名の形式であることを示します。この名前IDフォーマットは、SAML 2.0プロトコルのみに適用されます。
oracle:security:nameid:format:persistent: 名前IDが、IdPおよびSPに固有のユーザーの不透明な永続識別子であることを示します。この名前IDフォーマットは、SAML 2.0プロトコルのみに適用されます。
oracle:security:nameid:format:transient: 名前IDが、ユーザーの不透明で一時的な識別子であることを示します。この名前IDフォーマットは、SAML 2.0プロトコルのみに適用されます。
oracle:security:nameid:format:unspecified: 名前IDの解釈は、実装に準拠することを示します。
oracle:security:nameid:format:custom: 名前IDがカスタム値であることを示します。
oracle:security:nameid:format:userid: 名前IDが、Oracle Identity Federationによるユーザーの識別に使用されるユーザーIDであることを示します。
|
注意: 名前IDフォーマットを有効/無効にして、ユーザー・データ・ストアの属性にマップするには、次の手順に従います。
|
AttributeQueryが送信される属性認証局。属性認証局を指定しない場合、Oracle Identity FederationはAttributeQueryの送信先の属性認証局を次のように決定します。
Subject Formatが"oracle:security:nameid:format:x509"または指定されていない場合は、Subjectの値をアイデンティティ・プロバイダにマップします。SubjectDNに対するマッピングが見つからない場合は、デフォルト属性認証局をが使用されます。
それ以外の場合は、デフォルト属性認証局を使用します。
|
関連項目: デフォルト属性認証局およびSubjectDNとIdPのマッピングを構成する方法の手順は、第5.6.5項「SP属性リクエスタとしてのOracle Identity Federationの構成」を参照してください。 |
このユーザーについて取得する0個以上の属性。
各属性に対する0個以上の値。NULL値は<Value Null="true"/>で表すことができます。
AttributeRequestメッセージはSOAPEnvelopeおよびBodyでラップされ、HTTP POSTリクエストで送信されます。次にAttributeRequestメッセージの例を示します。
例1
次のリクエストでは、Subjectのフォーマットが指定されていないため、"oracle:security:nameid:format:x509"であるとみなされます。ターゲットIdPも指定されていないため、Oracle Identity Federationは、使用する属性認証局を決定するためにSubjectDNをIdPにマッピングします。
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<orafed-arxs:AttributeRequest xmlns:orafed-arxs=http:"//www.oracle.com/fed/ar/10gR3">
<orafed-arxs:Subject>cn=alice,cn=users,dc=us,dc=oracle,dc=com
</orafed-arxs:Subject>
<orafed-arxs:Attribute Name="mail">
<orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
<orafed-arxs:Value>bob@oracle.com</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="firstname">
<orafed-arxs:Value>Bobby</orafed-arxs:Value>
<orafed-arxs:Value>Charles</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="lastname">
</orafed-arxs:Attribute>
</orafed-arxs:AttributeRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
例2
次のリクエストでは、ターゲットIdPに"http://my-corp.com/fed/idp"が指定されているため、Oracle Identity Federationは、この属性認証局にAttributeQueryを送信します。また、Subject Formatが"oracle:security:nameid:format:userid"であるため、サブジェクト値「alice」は、属性をリクエストしたユーザーのユーザーIDであるとみなされます。
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<orafed-arxs:AttributeRequest xmlns:orafed-arxs=http://www.oracle.com/fed/ar/10gR3 TargetIDP="http://my-corp.com/fed/idp">
<orafed-arxs:Subject Format="oracle:security:nameid:format:userid">alice
</orafed-arxs:Subject>
<orafed-arxs:Attribute Name="mail">
<orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
<orafed-arxs:Value>bob@oracle.com</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="firstname">
<orafed-arxs:Value>Bobby</orafed-arxs:Value>
<orafed-arxs:Value>Charles</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="lastname">
</orafed-arxs:Attribute>
</orafed-arxs:AttributeRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
出力ルールは次のとおりです。
SAML <AttributeQuery>表記規則に従い、属性名を指定しない場合はすべてのユーザー属性が戻されます。
リクエスト内で1つ以上の属性名を指定すると、これらの属性のみが戻されます。
リクエストで値が指定されていない場合、属性認証局はリクエストにローカル属性値のみを返します(リクエストに値がある場合)。
属性はレスポンダのローカル・ポリシーに従って戻されます。
属性リクエスタ・サービスは、属性リクエストに続いてAttributeResponseメッセージをSOAPクライアントに戻します。
AttributeResponseの出力には、次が含まれます。
SAML 1.xまたはSAML 2.0問合せのステータス(SuccessまたはFailure、およびその理由)。クライアントは、この情報をロギング用に使用できます。
リクエストで指定したSubject
リクエストで指定したSubject Format
0(ゼロ)以上の<Attribute>要素(各要素が属性名と0(ゼロ)以上の値を提供します)
戻される属性値については、次の点に注意してください。
すべての値はUTF-8文字列です。
SAML AttributeQuery表記規則に従い、リクエスタによる属性の値の確認が許可されていない場合、Attribute要素はValue要素なしで戻されます。
NULLの属性値は<Value Null="true"/>で表されます。
AttributeResponseメッセージのCacheFor属性により、属性値をキャッシュできる時間を指定します。
AttributeResponseメッセージはSOAP EnvelopeおよびBodyでラップされ、HTTP 200 OKレスポンスで戻されます。次の属性レスポンスは、前述の例の属性リクエストに対応しています。
例1
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<orafed-arxs:AttributeResponse xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3" CacheFor="1199">
<orafed-arxs:Status>Success</orafed-arxs:Status>
<orafed-arxs:Subject>cn=alice,cn=users,dc=us,dc=oracle,dc=com
</orafed-arxs:Subject>
<orafed-arxs:Attribute Name="lastname">
<orafed-arxs:Value>Appleton</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="firstname"></orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="mail">
<orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
</orafed-arxs:Attribute>
</orafed-arxs:AttributeResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
例2
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<orafed-arxs:AttributeResponse xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3" CacheFor="1199">
<orafed-arxs:Status>Success</orafed-arxs:Status>
<orafed-arxs:Subject Format="oracle:security:nameid:format:userid">alice
</orafed-arxs:Subject>
<orafed-arxs:Attribute Name="lastname">
<orafed-arxs:Value>Appleton</orafed-arxs:Value>
</orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="firstname"></orafed-arxs:Attribute>
<orafed-arxs:Attribute Name="mail">
<orafed-arxs:Value>alice@oracle.com</orafed-arxs:Value>
</orafed-arxs:Attribute>
</orafed-arxs:AttributeResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
属性リクエスタ・サービス・インタフェースを正式に定義するWSDLは、次のとおりです。
<?xml version ="1.0" encoding="US-ASCII" ?>
<wsdl:definitions name="AttributeRequesterFed" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3"
xmlns:orafed-arwsdl="http://www.oracle.com/fed/ar/wsdl"
targetNamespace="http://www.oracle.com/fed/ar/wsdl">
<wsdl:types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.oracle.com/fed/ar/10gR3"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:complexType name="SubjectType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Format" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="Subject" type="orafed-arxs:SubjectType"/>
<xs:complexType name="ValueType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="Null" type="xs:boolean"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="Value" type="orafed-arxs:ValueType"/>
<xs:complexType name="AttributeType">
<xs:attribute name="Name" type="xs:ID"/>
<xs:sequence>
<xs:element ref="orafed-arxs:Value"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Attribute" type="orafed-arxs:AttributeType"/>
<xs:complexType name="AttributeRequestType">
<xs:attribute name="TargetIDP" type="xs:string"/>
<xs:sequence>
<xs:element ref="orafed-arxs:Subject"/>
<xs:element ref="orafed-arxs:Attribute" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="AttributeRequest" type="orafed-arxs:AttributeRequestType"/>
<xs:complexType name="AttributeResponseType">
<xs:sequence>
<xs:element name="Status" type="xs:string"/>
<xs:element ref="orafed-arxs:Subject"/>
<xs:element ref="orafed-arxs:Attribute" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="CacheFor" type="xs:unsignedInt"/>
</xs:complexType>
<xs:element name="AttributeResponse" type="orafed-arxs:AttributeResponseType"/>
</xs:schema>
</wsdl:types>
<wsdl:message name="AttributeRequestMessage">
<wsdl:part name="body" element="orafed-arxs:AttributeRequest"/>
</wsdl:message>
<wsdl:message name="AttributeResponseMessage">
<wsdl:part name="body" element="orafed-arxs:AttributeResponse"/>
</wsdl:message>
<wsdl:portType name="AttributeRequesterServicePortType">
<wsdl:operation name="AttributeRequestOp">
<wsdl:input message="orafed-arwsdl:AttributeRequestMessage"/>
<wsdl:output message="orafed-arwsdl:AttributeResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="AttributeRequesterServiceBinding" type="orafed-arwsdl:AttributeRequesterServicePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="AttributeRequestOp">
<soap:operation soapAction="http://www.oracle.com/fed/AttributeRequestOp" />
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="AttributeRequesterService">
<wsdl:port name="AttributeRequesterServicePort"
binding="orafed-arwsdl:AttributeRequesterServiceBinding">
<soap:address location="http://stadm04.us.oracle.com:7778/fed/ar/soap"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
typesおよびmessageセクションは、AttributeRequestおよびAttributeResponseメッセージの内容を定義します。
attribute要素のName属性には、組込みXMLスキーム・タイプIDが使用されます。このタイプにより、属性名の必要な構文(文字、数値、「_」、「-」および「.」)が概算されます。ただし、ID(XML NCNameタイプから導出)には、文字と拡張機能を組み合せた複数のUnicodeも含まれます。
bindingおよびserviceセクションは、SOAPおよびHTTP(S)を介してメッセージを送信する方法を指定します。
この項では、Oracle Identity Federationの属性マッピング機能を構成する方法について説明します。内容は次のとおりです。
サポート対象エンティティ
Oracle Identity Federationは、次に関する属性マッピングをサポートしています。
属性認証局
属性リクエスタ
アイデンティティ・プロバイダ(SSOアサーションで属性を送信する場合)
マッピング機能
Oracle Identity Federationには、次の属性マッピング機能が用意されています。
属性名マッピング: SAMLメッセージで使用される外部属性名にローカル属性名をマップします。
属性値マッピング: SAMLメッセージで使用される外部属性値にローカル属性値をマップします。
属性値フィルタリング: アサーション・メッセージで許容値のみを送信することによってローカル属性値にフィルタリングします。
|
注意: 11g リリース1(11.1.1)では、属性マッピングおよびフィルタリングはすべて、グローバル・レベルではなく、ピア・プロバイダ単位の構成としてのみ適用できます。 |
属性ソース
Oracle Identity Federationでは、属性を次のソースから送信アサーションにマップできます。
ユーザー・セッション
ユーザー・データ・ストア
Oracle Identity Federation構成の静的値
この項は次のトピックで構成されています。
管理者は、属性名マッピングを使用することにより、メッセージの送受信時にSAMLメッセージでローカル属性を定義するための名前を指定できます。
IdP/属性権限側では、マッピングの定義時に、属性を特定のピア・プロバイダに送信するようOracle Identity Federationを構成することもできます。つまり、名前マッピングを定義しない場合、Oracle Identity Federationは属性をピア・プロバイダに送信しないよう構成されます。
Oracle Identity Federationによって属性名マッピングが実行されるのは、Oracle Identity Federationが次のものとして動作する場合です。
属性認証局
属性リクエスタ
アイデンティティ・プロバイダ(SSOアサーションで属性を送信する場合)
属性名マッピングは、Fusion Middleware Controlコンソールを使用して構成します。詳細は、第5.9.2.1項「属性名マッピングの構成」を参照してください。
Oracle Identity Federation構成から静的属性値(DeploymentVersion=6.4など)を送信アサーションにマップできます。
この機能は、既存の属性名マッピング定義の次に示す2つのプロパティで実装されています。
from-config(ブール値)
attribute-value-fromconfig
from-configがtrueで、その属性を送信アサーションに含める必要がある場合は、attribute-value-fromconfigに格納されている値が送信アサーションに配置されます。
from-configがfalseの場合は、Fusion Middleware Controlで属性に設定した値が使用されます。
この手順には、属性マッピングのリストに対する属性名マッピング定義の作成、および次のプロパティの設定が含まれます。
属性の内部名。datastore-attrによって参照されます。
アサーションに表示される際の属性の名前。assertion-attrによって参照されます。
SAML属性のフォーマットまたはネームスペース(空白も可能)。format-attrによって参照されます。
その属性をSSOアサーションで送信するかどうかを示すフラグ。send-with-ssoによって参照されます。
属性値をOracle Identity Federationユーザー・セッションから取得するかどうかを示すフラグ。from-sessionによって参照されます。
属性値が静的かどうかを示すフラグ。from-configによって参照されます。
attribute-value-fromconfigによって参照されるプロパティ。静的値が含まれます。
静的属性マッピングを構成するWLSTコマンドは次のとおりです。
|
注意: 次の例のホスト:ポート、マップ名および静的値のサンプル値は、有効な値で置き換える必要があります。 |
http://myhost.domain.com:7499/fed/spというprovideridに対して、属性の属性名マッピング定義(ローカル名をcn、アサーション名をcommonNameに設定)を次のように作成します(まだ存在していない場合)。
createFederationPropertyMap('http://myhost.domain.com:7499/fed/sp',
'attributelist')
createFederationPropertyMapInMap('http://myhost.domain.com:7499/fed/sp','attributelist','cncommonName')
属性にプロパティがまだ存在しない場合は、次のガイドラインを使用して新しいプロパティを追加します。(このプロパティは、前の手順で作成した要素に追加されます。)
|
注意: 最初からマッピングを作成する場合は、属性「require-from-infocard」を含める必要があります。 |
| プロパティ | 設定値 |
|---|---|
| datastore-attr | cn |
| assertion-attr | commonName |
| format-attr | 空の値 |
| send-with-sso | true(常にSSOアサーションで属性を送信する)またはfalse(属性を送信しない) |
| from-session | true(Oracle Identity Federationユーザー・セッションから属性値を取得する)またはfalse(値を取得しない) |
| from-config | true(属性に静的値がある)またはfalse |
| attribute-value-fromconfig | 静的値(必要な場合) |
次に例を示します。
addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'datastore-attr', 'cn', 'string')
addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'assertion-attr', 'commonName', 'string')
addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'format-attr', '', 'string')
addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'send-with-sso', 'true', 'boolean')
addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'from-session', 'false', 'boolean')
addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'from-config', 'true', 'boolean')
addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'attribute-value-fromconfig', 'cn=users,dc=oracle,dc=com', 'string')
「require-from-infocard」プロパティを含む別の例を次に示します。
addFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp', 'attributelist', 'cncommonName', 'require-from-infocard', 'true', 'boolean')
プロパティとそれに対応する属性のマップを削除するには次のようにします。
removeFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp',
'attributelist','cncommonName','attribute-value-fromconfig')
removeFederationMapEntryInMap('http://myhost.domain.com:7499/fed/sp',
'attributelist','cncommonName','from-config')
removeFederationMapInMap('http://myhost.domain.com:7499/fed/sp',
'attributelist','cncommonName')
管理者は、属性値マッピングを使用することにより、メッセージの送受信時にSAMLメッセージでローカル属性を割り当てるための値を指定できます。
属性値マッピングには、次のような特徴があります。
値マッピングは、ローカル値とこれに対応する外部値の組合せで構成されます。
値マッピングは任意のローカル属性に対して定義できます。ローカル属性ごとに複数の値マッピングを定義できます。
値マッピングを使用して、同じローカル値に対して様々な外部値をマップできます。送信モードで使用される外部値の決定には、デフォルトの属性が使用されます。
値マッピングを使用して、同じ外部値に対して様々なローカル値をマップできます。外部値からローカル値へのマッピング時に受信モードで使用されるローカル値の決定には、デフォルトの属性が使用されます。
Oracle Identity Federationによって属性値マッピングが実行されるのは、Oracle Identity Federationが次のものとして動作する場合です。
属性認証局
属性リクエスタ
アイデンティティ・プロバイダ(SSOアサーションで属性を送信する場合)
属性値マッピングは、Fusion Middleware Controlコンソールを使用して構成します。詳細は、第5.9.2.2項「属性値マッピングの構成」を参照してください。
管理者は、属性値フィルタリングを使用して、SAMLメッセージの送信時に使用可能なローカル値を指定できます。
属性値フィルタリングには、次のような特徴があります。
フィルタ・ルールは任意のローカル属性に対して定義できます。フィルタ・ルールによって各属性値を評価し、送信可能かどうかを決定します。評価結果が正である場合、値は送信されます。正でない場合、送信対象の属性値のリストから削除されます。
ローカル属性ごとに複数のフィルタリング・ルールを定義できます。値の送信時には、次のいずれかのようにOracle Identity Federationを設定できます。
すべてのフィルタが正常に評価された場合のみ送信します。
少なくとも1つのフィルタが正常に評価された場合のみ送信します。
管理者は、比較のタイプと比較対象の文字列値を指定することにより、フィルタリング・ルールを定義します(第5.9.2.3項「属性値フィルタリングの構成」を参照)。
Oracle Identity Federationは、属性値と文字列を比較する場合、次の比較タイプをサポートしています。
次と等しい
次と等しくない
次で始まる
次で終わる
次を含む
次を含まない
NULLと等しい
NULLと等しくない
これらの比較タイプ以外にも、フィルタリングでは正規表現もサポートしており、属性値と正規表現を照合できます。詳細は、第5.9.2.3項「属性値フィルタリングの構成」の第5.9.2.3.1項「フィルタリング条件」を参照してください。
フィルタリング・ルールを使用して、比較時に大/小文字を区別するかどうかを指定できます。
Oracle Identity Federationによって属性値フィルタリングが実行されるのは、Oracle Identity Federationが次のように動作する場合です。
属性認証局
アイデンティティ・プロバイダ(SSOアサーションで属性を送信する場合)
この機能は、Fusion Middleware Controlコンソールを使用して構成します。詳細は、第5.9.2.3項「属性値フィルタリングの構成」を参照してください。
この項では、マッピングおよびフィルタリングの構成方法を説明します。
属性名マッピングの構成には次の目的があります。
IdP側:
アサーションに含まれる属性名をローカル属性名にマップします。
ピア・プロバイダに送信できるローカル属性を定義します。つまり、ピア・プロバイダの属性名マッピングを定義することにより、Oracle Identity Federationによるこの属性のリモート・サーバーへの送信を認可します。
SP側:
SOAPクライアントのリクエストに含まれる属性名を、属性認証局への属性問合せの名前にマップします。
属性名マッピングを定義するには、次の手順を実行します。
IdP側
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「フェデレーション」の順に移動します。
属性共有を構成する属性リクエスタを選択し、「編集」をクリックします。
「属性名マッピングの編集」をクリックします。
「名前マッピング」タブで「追加」をクリックして属性名マッピングを追加し、次のフィールドを設定します。
ユーザー属性名: ユーザー・リポジトリ内のローカル属性の名前です。アサーション属性にユーザーIDをマップする必要がある場合は、このフィールドに「orafed-userid」を設定します。
アサーション属性名: 属性問合せおよびアサーション内の属性を識別するために使用される名前です。
フォーマットまたはネームスペース: バージョンに応じてSAML属性のフォーマットまたはネームスペースを指定するために使用されるオプションのフィールドです。
SAML 1.xの場合、このフィールドの値を使用してSAML属性のネームスペースを設定します。
SAML 2.0の場合、この値を使用してSAML属性のNameFormatを設定します。このフィールドが空の場合、SAML属性のNameFormatはurn:oasis:names:tc:SAML:2.0:attrname-format:basicに設定されます。空でない場合、このフィールドに指定した値がNameFormatに保持されます。
SSOアサーションで送信: SSO処理時にアサーションで属性を送信するかどうかを示します。
|
注意: アイデンティティ・プロバイダからピア・プロバイダに属性を送信するには、その属性のマッピングを前述したように定義する必要があります。 |
ユーザー・セッションから値を取得: 属性値をユーザー・セッションから取得するかどうかを示します。
情報カードの内容が必要: 属性を情報カードから渡す必要があるかどうかを示します。
SP側
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「フェデレーション」の順に移動します。
属性共有を構成する属性認証局を選択し、「編集」をクリックします。
「手動更新」を選択し、「Oracle Identity Federation設定」で属性マッピングおよびフィルタの編集をクリックします。
「名前マッピング」タブで「追加」をクリックして属性名マッピングを追加し、次のフィールドを設定します。
ユーザー属性名: AttributeRequestのSOAPクライアントで使用される名前です。
アサーション属性名: 属性問合せおよびアサーション内の属性を識別するために使用される名前です。
フォーマットまたはネームスペース: バージョンに応じてSAML属性のフォーマットまたはネームスペースを指定するために使用されるオプションのフィールドです。
SAML 1.xの場合、このフィールドの値を使用してSAML属性のネームスペースを設定します。
SAML 2.0の場合、この値を使用してSAML属性のNameFormatを設定します。このフィールドが空の場合、SAML属性のNameFormatはurn:oasis:names:tc:SAML:2.0:attrname-format:basicに設定されます。空でない場合、このフィールドに指定した値がNameFormatに保持されます。
ユーザー・セッションから値を取得: 属性値をユーザー・セッションから取得するかどうかを示します。
情報カードの内容が必要: 属性を情報カードから渡す必要があるかどうかを示します。
|
注意: 属性名に対するマッピングが見つからない場合、サービス・プロバイダは名前をそれ自体にマップします。 |
例
次に、属性名構成とその構成で得られる結果を示します。
SPの名前マッピング:
| ユーザー属性 | アサーション属性 |
|---|---|
| phone | telephone |
| userid | username |
| emailaddress | |
| id | idnumber |
IdPの名前マッピング:
| アサーション属性 | ユーザー属性 |
|---|---|
| lastname | sn |
| idnumber | employeenumber |
| telephone | telephonenumber |
| title | title |
| username | uid |
| emailaddress | |
| firstname | givenname |
結果:
| SOAPクライアント・リクエスト内の属性 | SAML属性問合せ内の属性 | ユーザー・データ・ストア内の属性 | SAMLアサーション内の属性 | SOAPクライアントへのレスポンス内の属性 |
|---|---|---|---|---|
| lastname | lastname | sn | lastname | lastname |
| id | idnumber | employeenumber | idnumber | id |
| phone | telephone | telephonenumber | telephone | phone |
| title | title | title | title | title |
| userid | username | uid | username | userid |
| emailaddress | emailaddress | |||
| firstname | firstname | givenname | firstname | firstname |
| middlename | middlename | - | - | - |
次の点に注意してください。
属性lastname、title、firstnameは、SPでマッピングされていないため、これらの属性はそれ自体にマッピングされます。
属性middlenameは、IdPでマッピングされていないため、IdPはこの属性に関する値を返しません。属性問合せ/アサーションで使用される属性名がユーザー・データ・ストア内の名前と同じ場合は、属性名のマッピングを明示的に定義する必要があるため、属性titleで示したように、名前をそれ自体にマップします。
属性値マッピングを定義するには、次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「フェデレーション」の順に移動します。
属性共有を構成するピア・プロバイダを選択し、「編集」をクリックします。
「手動更新」を選択し、「Oracle Identity Federation設定」で属性マッピングおよびフィルタの編集をクリックします。
「値マッピング」タブで「追加」をクリックして属性値マッピングを追加し、次のフィールドを設定します。
属性名: ユーザー・リポジトリ内のローカル属性の名前です。
アンマップ値: マッピングが定義されていない値をOracle Identity Federationから送信できるようにするには、「送信」を選択します。マッピングが定義されていない値をOracle Identity Federationで受信できるようにするには、「受信」を選択します。
ローカルと外部との値マッピングのリスト:
ローカル値: 属性のローカル値
外部値: 外部メッセージで送信する際に対応する値
大/小文字区別なし: 選択した場合、属性値の照合時に大/小文字を区別して文字列比較が行われることを示します。
ローカルNULL: 選択した場合、ローカル値がヌル文字列(空の文字列「""」とは異なる)であることを示します。
外部NULL: 選択した場合、外部値がヌル文字列(空の文字列「""」とは異なる)であることを示します。
デフォルト: 選択した場合、着信外部値が複数のローカル値にマップ可能な場合に、このローカル値が使用されることを示します。
例
属性titleに対して次の値マッピングが構成されている場合、結果は次のようになります。
属性名: title
アンマップ値:
送信: 選択
受信: 選択
値マッピング:
| ローカル値 | 外部値 | 大/小文字区別なし | ローカルNULL | 外部NULL | デフォルト値 |
|---|---|---|---|---|---|
| Senior Member of Technical Staff | smts | 選択 | 選択 | ||
| Principal Member of Technical Staff | pmts | 選択 | |||
| なし | 選択 | ||||
| Senior Member of Technical Staff | srmts | 選択 | |||
| Consulting Member of Technical Staff | cmts | 選択 |
結果:
| 外部値 | ローカル値へのマップ |
|---|---|
| Consulting Member of Technical Staff | cmts |
| PRINCIPAL MEMBER OF TECHNICAL STAFF | pmts |
| Principal Member of Technical Staff | pmts |
| Senior Member of Technical Staff | smts |
| Vice President | Vice President |
| ローカル値 | 外部値へのマップ |
|---|---|
| NULL | なし |
| smts | Senior Member of Technical Staff |
| srmts | Senior Member of Technical Staff |
| CEO | CEO |
次の点に注意してください。
値マッピングで大/小文字は区別しないと定義したため、「PRINCIPAL MEMBER OF TECHNICAL STAFF」と「Principal Member of Technical Staff」は両方ともpmtsにマップされます。
「アンマップ値」の「送信」が選択されており、値「Vice President」にはルールが定義されていないため、この値はそれ自体にマップされます。
smtsを「Senior Member of Technical Staff」のデフォルトローカル値として定義したため、「Senior Member of Technical Staff」はsrmtsにもマップされていますが、smtsにマップされます。
ローカル値がNULLの場合は、文字列Noneにマップされます。
smtsおよびsrmtsは、ともに"Senior Member of Technical Staff"にマップされます。
「アンマップ値」の「受信」が選択されており、「CEO」にはルールが定義されていないため、この値はそれ自体にマップされます。
次の手順を実行します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「フェデレーション」の順に移動します。
属性共有を構成する属性リクエスタを選択し、「編集」をクリックします。
「手動更新」を選択し、「Oracle Identity Federation設定」で属性マッピングおよびフィルタの編集をクリックします。
「値フィルタ」タブで「追加」をクリックして属性値フィルタを追加し、次のフィールドを設定します。
属性名: ユーザー・リポジトリ内のローカル属性の名前です。
条件演算子: 「and」を選択した場合は、送信される属性がすべての条件を満たしている必要があることを示します。「or」を選択した場合は、1つでも条件を満たしていれば属性を送信できることを示します。
フィルタリング・ルールのリストには次のフィールドがあります。
条件: 属性値の評価に使用される条件です。
式: 属性値の評価に使用される値または正規表現です。
大/小文字区別なし: 選択した場合、属性値の照合時に大/小文字を区別して文字列比較が行われることを示します。
Oracle Identity Federationには複数のフィルタリング条件が用意されています。
equals: 式の値が送信属性値と等しい場合、trueを戻します。
does not equal: 式の値が送信属性値と異なる場合、trueを戻します。
starts with: 送信属性値が式の値から始まる場合、trueを戻します。
ends with: 送信属性値が式の値から終わる場合、trueを戻します。
contains: 送信属性値に式の値が含まれる場合、trueを戻します。
does not contain: 送信属性値に式の値が含まれない場合、trueを戻します。
equals null: 送信属性値がNULLである場合、trueを戻します。
does not equal nul: 送信属性値がNULLでない場合、trueを戻します。
regexp: 送信属性値が式の値に定義されている正規表現と一致する場合、trueを戻します。
|
注意: これらのルールを使用して許容値が決定されます。このため、ルールの評価結果がtrueである場合、値が送信可能であることを示します。 |
フィルタリング条件をregexpに設定する場合、式の値は標準のUNIXの正規表現である必要があります。
正規表現の構文の詳細は、http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.htmlを参照してください。
|
注意: フィルタリング条件をregexpに設定すると、正規表現ではすでに大/小文字を区別しないため、属性値処理時にignoreCaseフラグは無視されます。 |
表5-8は、regexpフィルタリング条件の使用方法を表す例を示しています。
この項では、値フィルタの構成例をいくつか示します。
例1
属性titleに対して次の値フィルタが構成されている場合、結果は次のようになります。
属性名: title
条件演算子: and
値フィルタ:
| 条件 | 式 | 大/小文字区別なし |
|---|---|---|
| does not equal | Vice-President | 選択 |
| 次を含む | President | 選択 |
結果:
| 値 | 値を送信するか |
|---|---|
| Vice-President | いいえ |
| President | はい |
| Vice-President | いいえ |
| Senior Vice-President | はい |
例2
属性値マッピングが、第5.9.2.2項「属性値マッピングの構成」の例で示したように定義されているとします。属性titleに対して次の値フィルタが構成されている場合、結果は次のようになります。
属性名: title
条件演算子: and
値フィルタ:
| 条件 | 式 | 大/小文字区別なし |
|---|---|---|
| does not equal | mngr | true |
| 次で終わる | mts | false |
結果:
| 値 | 値を送信するか | 送信される値 |
|---|---|---|
| mngr | いいえ | |
| cmts | はい | Consulting Member of Technical Staff |
次の点に注意してください。
送信される値は、mngrに一致してはいけないため、値mngrは送信されません。
cmtsは送信され(すべてのフィルタ条件がtrueの場合)、「Consulting Member of Technical Staff」にマップされます。
次の値フィルタでも同じ結果になります。
| 条件 | 式 | 大/小文字区別なし |
|---|---|---|
| does not equal | mngr | true |
| regexp | *mts |
セキュリティおよび信頼の各ページを使用して、Oracle Identity Federationサーバーのキーストアおよび証明書を構成します。
これらのページにアクセスするには、まず「トポロジ」アイコンの隣にあるドロップダウンから「Oracle Identity Federation」を選択し、「管理」→「セキュリティおよび信頼」の順に移動します。
この項では、信頼の構成に関連する次の内容について説明します。
サーバー・インスタンスの署名証明書および暗号化証明書はウォレットに保存されます。このページは、署名および暗号化ウォレットを管理するために使用します。
このページには次の内容が表示されます。
署名ウォレットのタイプ(PKCS#12、JKSなど)
ウォレット内の署名鍵の別名
旧署名ウォレットのタイプ(PKCS#12、JKSなど)
旧ウォレット内の旧署名鍵の別名
暗号化ウォレットのタイプ(PKCS#12、JKSなど)
ウォレット内の暗号化鍵の別名
旧暗号化ウォレットのタイプ(PKCS#12、JKSなど)
旧ウォレット内の旧暗号化鍵の別名
ウォレットの情報を変更するには、「更新」をクリックします。「ウォレットの更新」ダイアログでは、署名または暗号化ウォレットに関する次の情報が必要になります。
ウォレット・ロケーション: ウォレットを含むオペレーシング・システム・ファイルを選択できます。
パスワード: 秘密鍵を暗号化するために使用されたパスワードを入力します。
キー・パスワード: JKSキーストアおよびカスタムJavaキーストアの場合にのみ必要です。
署名鍵別名: 秘密鍵がウォレットに保存される場合の別名です。
このページでは、次の操作を行います:
メタデータ署名の要件を指定します。
更新されたメタデータを生成します。
メタデータ署名
Oracle Identity Federationは、準拠しているフェデレーション・サーバーによって公開されるサービスを記述するXMLメタデータ文書でXMLデジタル署名をサポートしています。Oracle Identity Federationは、メタデータ署名に次のサポートを提供します。
Oracle Identity Federationが公開するメタデータにデジタルで署名します。
サーバーにアップロードされるメタデータ文書にあるXMLデジタル署名を検証します。検証が失敗すると、メタデータはアップロードされません。
信頼できるプロバイダにアップロードするためにプロバイダ・メタデータでXMLデジタル署名を必要とするようサーバーを構成します。
このページのこのセクションでは、メタデータ署名を指定します。次の情報を指定します。
署名付メタデータが必要: このボックスを選択すると、信頼できるプロバイダに記述子をインポートするときに、署名されたメタデータをOracle Identity Federationが要求するよう指定できます。そのため、ピア・プロバイダは署名付メタデータをサーバーに提供する必要があります。
メタデータの署名: このボックスは、Oracle Identity Federationサーバーでメタデータに署名する必要がある場合に選択します。
有効期間: 有効期間を入力します(単位は日)。
変更を保存するには「適用」を、フィールドを前の状態にリセットするには「元に戻す」をクリックします。
メタデータの生成
このページのこのセクションは、メタデータに影響するサーバー構成を変更した後で、メタデータを生成してピア・プロバイダに配布する場合に使用します。
プロバイダ・タイプ: ドロップダウン・リストからタイプを選択します。
プロトコル: ドロップダウン・リストからプロトコルを選択します。
この機能は、SAML 1.0、1.1および2.0プロトコルでサポートされます。
|
注意: Liberty 1.xの構成およびメタデータのアップロードを利用するには、WLSTコマンドライン・ツールを使用します。 |
「保存」をクリックしてメタデータを生成および配布します。
Oracle Identity Federationは、信頼できる証明書とCRLを保持するための証明書ストアをメンテナンスします。証明書検証ストアが有効化されている場合、Oracle Identity Federationでは、これを使用してSAML/WSフェデレーション受信メッセージの署名検証が必要な証明書が検証されます。
このページは、証明書検証ストア内で次のオブジェクトをメンテナンスする場合に使用します。
認証局(CA)証明書
証明書失効リスト(CRL)
次の情報を指定します。
認証検証の有効化: このボックスを選択すると、サーバーでの証明書の検証が有効になります。
変更を保存するには「適用」を、フィールドを前の状態にリセットするには「元に戻す」をクリックします。
信頼できる認証局(CA): この表には、Oracle Identity Federationで信頼されているCAの詳細が表示されます。
CAのフィールドは次のとおりです。
サブジェクト: CA証明書のサブジェクト
発行者: 証明書の発行者
シリアル番号: 証明書のシリアル番号
有効期限開始: 証明書の有効期間の開始日時
有効期限終了: 証明書の有効期間の終了日時
CAをストアから削除するには、そのCAを選択して「削除」をクリックします。新しい信頼できるCAをストアに追加するには、「追加」をクリックします。
証明書失効リスト: CRLの表には、Oracle Identity Federationが認識している証明書失効リスト(CRL)のリストが表示されます。
CRLのフィールドは次のとおりです。
発行者: CRLを発行したCA
有効期限開始: CRLの有効期間の開始日時
有効期限終了: CRLの有効期間の終了日時
CRLをストアから削除するには、そのCRLを選択して「削除」をクリックします。新しいCRLをストアに追加するには、「追加」をクリックします。
第4.3項「アイデンティティ・フェデレーションの管理」を参照してください。
第4.4項「アイデンティティの構成」を参照してください。
この項では、Oracle Identity Federationで使用される各種データ・ストアの構成方法および管理方法について説明します。
この項では、Oracle Identity Federationでユーザー・データ・ストアを構成する方法を説明します。
Oracle Identity Federationでデータベースをユーザー・データ・ストアとして使用するには、ユーザー表と呼ばれる、ユーザー情報を格納する表をそのデータベースで使用する必要があります。ユーザー表にはユーザーIDを格納する列が必要になります。Oracle Identity FederationはこのユーザーIDを使用してユーザーを識別します。ユーザーIDは必ず存在し、すべてのユーザーで一意である必要があります。属性共有または属性を使用したユーザー・マッピングを使用する場合は、これらの属性の列もユーザー表に存在する必要があります。
RDBMSユーザー・データ・ストアを使用するようにOracle Identity Federationを構成する手順は次のとおりです。
JDBCデータ・ソースを作成します。
Oracle Identity Federationデータ・ストア構成を変更します。
JDBCデータ・ソースを作成します。
JDBCデータ・ソースを作成するには、次の手順に従います。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項 |
WebLogic管理コンソールにログインします。
「サービス」→「JDBC」→「データ・ソース」の順に移動します。
「新規」をクリックします。
新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。
RDBMSユーザー・データ・ストアの構成
RDBMSユーザー・データ・ストアを構成するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「データ・ストア」の順にナビゲートします。
「ユーザー・データ・ストア」セクションで「編集」をクリックします。
「リポジトリ・タイプ」ドロップダウン・リストから「データベース」を選択します。
次のプロパティを入力します。
JNDI名: WebLogic管理コンソールで作成したデータ・ソースのJNDIです。
ログイン表: ユーザー表の名前です。
ユーザーID属性: ユーザー表の「ユーザーID」列の名前です。
ユーザーの説明属性: ユーザー表の「ユーザーの説明」列の名前を入力します。
「OK」をクリックします。
例
次の「UserInformation」というユーザー表を使用し、データ・ソースのJNDI名が「MyCorpUserDS」であるとします。
| Username | FirstName | LastName | FullName | |
|---|---|---|---|---|
| alice | Alice | Smith | Alice Smith | alice@mycorp.com |
| bob | Robert | Jones | Robert Jones | bob@mycorp.com |
| charlie | Charles | Johnson | Charles Johnson | charlie@mycorp.com |
| david | David | Jones | David Jones | david@mycorp.com |
| robert | Robert | Williams | Robert Williams | williams@mycorp.com |
このユーザー・データ・ストアに対するOracle Identity Federation構成は次のようになります。
JNDI名: MyCorpUserDS
ログイン表: UserInformation
ユーザーID属性: Username
ユーザーの説明属性: Full Name
または、次のように構成することもできます。
JNDI名: MyCorpUserDS
ログイン表: UserInformation
ユーザーID属性: Username
ユーザーの説明属性: Username
LDAPユーザー・データ・ストアを構成するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「データ・ストア」の順にナビゲートします。
「ユーザー・データ・ストア」セクションで「編集」をクリックします。
「リポジトリ・タイプ」ドロップダウン・リストから「LDAPディレクトリ」を選択します。
この構成で設定するフィールドは次のとおりです。
接続URL: サーバーに接続するLDAPのURLです。例: ldap://ldap.oif.com:389
バインドDN: LDAPサーバーへの接続に使用する管理者アカウントDNです。例: cn=orcladmin
パスワード: LDAPサーバーに接続する管理者パスワードです。
ユーザーID属性: 認証時にユーザーを識別するために使用されるLDAP属性(たとえばuid)です。様々なタイプのディレクトリ・サーバーに対するユーザーID属性の例を次に示します。
Oracle Internet Directory:uid
Sun Java System Directory Server:uid
Microsoft Active Directory:sAMAccountName
ユーザーの説明属性: フェデレーション・レコードの所有者を識別するために使用される可読的なLDAP属性(たとえばuid)です。ディレクトリ・サーバーのタイプごとのユーザー説明属性の例を次に示します。
Oracle Internet Directory:uid
Sun Java System Directory Server:uid
Microsoft Active Directory:sAMAccountName
個人オブジェクト・クラス: オブジェクト・クラスにより、どのようなデータまたは属性をオブジェクトに関連付けるかが定義されます。個人オブジェクト・クラスは「個人」オブジェクトの属性を参照しますが、これは当該コンテキストでは、フェデレーテッド・アイデンティティ所有者のことです。ディレクトリは、1つ以上のオブジェクト・クラスを利用して個人データ（名前、住所など）を保持できます。サーバーでLDAPユーザー・エントリを表しているLDAPオブジェクト・クラスを入力します。様々なタイプのディレクトリ・サーバーに対する個人オブジェクト・クラスの例を次に示します。
Oracle Internet Directory:inetOrgPerson
Sun Java System Directory Server:inetOrgPerson
Microsoft Active Directory:user
ベースDN: ユーザーを検索する範囲となるディレクトリです。
最大接続数: Oracle Identity FederationがLDAPサーバーに同時に開くLDAP接続の数の最大値です。
接続待機タイムアウト: Oracle Identity FederationがLDAPサーバーへの接続を開く際に使用するタイムアウト(分)です。
Oracle Identity FederationはOracle Virtual Directoryと統合できます。Oracle Virtual Directoryをユーザー・データ・ストアとして使用する場合は、Oracle Virtual Directoryに接続されているすべてのディレクトリ構造に対して、ベースDN、個人オブジェクト・クラス、一意ユーザーIDおよびユーザーの説明属性の設定が有効になるようにしてください。
ユーザー・データ・ストアでは冗長性がサポートされます。この項では、冗長性ユーザー・データ・ストアの設定方法について説明します。
冗長性ユーザー・データ・ストアを設定するには次の2つの方法があります。
ユーザー・データ・ストア構成の「サーバーURL」フィールドで、LDAP URLのスペース区切りリストを入力します。
次に例を示します。
ldap://ldap1.oif.mycorp.com ldap://ldap2.oif.mycorp.com ldap://ldap3.oif.mycorp.com
または
LDAPサーバーの前面にロード・バランサを設定し、Oracle Identity Federation構成の「ldaphaenabled」プロパティをtrueに設定します。このタスクの詳細は、第6.4.1項「高可用性LDAPサーバーの構成」を参照してください。
実行時にユーザー・データ・ストアを使用しないようにOracle Identity Federationを構成できます。この構成では、サーバーで使用できるユーザー情報は次の時点のユーザー識別子に限られます。
ローカル認証後
サーバーがサービス・プロバイダとして動作する場合は、フェデレーテッド・アイデンティティ・レコードを使用して着信アサーションがマップされた後
ユーザー・データ・ストアを使用しないようにOracle Identity Federationを構成する手順は次のとおりです。
Oracle Identity Federationデータ・ストア構成を変更します。
ユーザー識別子を使用するようにOracle Identity Federation構成を変更します。
Oracle Identity Federationデータ・ストア構成を変更します。
ユーザー・データ・ストアを使用しないように構成するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「データ・ストア」の順にナビゲートします。
「ユーザー・データ・ストア」セクションで「編集」をクリックします。
「リポジトリ・タイプ」ドロップダウン・リストからNoneを選択します。
「OK」をクリックします。
ユーザー識別子を使用するためのOracle Identity Federation構成の変更
ユーザー・データ・ストアでNoneを選択した場合、アサーション・データの移入時またはフェデレーション・データ・ストアの構成時にユーザー識別子を使用するようにOracle Identity Federationを構成できます。
Oracle Identity Federationがアイデンティティ・プロバイダとして動作する場合、サーバーを次のように構成できます。
ユーザー識別子をアサーション名前IDとして設定します。
これを行うには、「名前IDフォーマット」表に移動して、名前IDフォーマットのユーザー属性にorafed-useridを設定します。
ユーザー識別子をアサーション属性として追加します。
これを行うには、アサーションが送信されるリモート・サービス・プロバイダの構成画面に移動して、送信属性を定義し、ユーザー属性にorafed-useridを設定します。
フェデレーション・データ・ストアを使用している場合は、フェデレーション・データ・ストアを構成するセクションで、Oracle Identity FederationがユーザーID属性およびユーザーの説明属性としてorafed-useridを使用するようにしてください。
Oracle Identity Federationには、フェデレーテッド・アイデンティティ情報を含むレコードをバックエンドのデータ・ストアに保存するための構成オプションが用意されています。
XML、LDAPまたはRDBMSのタイプのフェデレーション・データ・ストアを使用するように構成されている場合、Oracle Identity Federationは各ユーザーのフェデレーション・レコードを作成し、選択されたデータ・ストアにレコードを保存して、シングル・サインオンでアサーションを作成する際(アイデンティティ・プロバイダとして動作する場合)、またはIdPから受信したアサーションをユーザーにマップする際(サービス・プロバイダとして動作する場合)にこのレコードを使用します。
SAML 2.0プロトコルで永続名前IDを使用するには、フェデレーション・データ・ストアが必要です。これは、各ユーザーの不透明な識別子を作成する必要があるためです(つまり、ユーザーの識別時に使用される名前IDを、ユーザー・データ・ストアの属性から指定することができないため、この名前IDを個別に作成して保存する必要があります)。
Oracle Identity Federationは、ユーザーがシングル・サインオン処理を最初に実行するときにフェデレーション・レコードを作成します。Oracle Identity Federationがサービス・プロバイダとして動作し永続名前IDを使用する場合、名前IDにはユーザー情報が含まれないため、Oracle Identity Federationはユーザーにローカル認証を要求し、この認証からユーザー情報を取得してフェデレーション・レコードを作成します。フェデレーションが作成されると、Oracle Identity Federation(サービス・プロバイダとして動作)は、このフェデレーション・レコードを使用してアサーションの不透明な名前IDを自動的にユーザーにマップするため、ユーザーはローカル・ログインを求められません。
フェデレーション・データ・ストアがNoneに設定されている場合、Oracle Identity Federationはフェデレーション・レコードの作成、保存、使用を行わずに、ユーザー・データ・ストアの属性を使用してユーザーを識別し、アサーションの作成(アイデンティティ・プロバイダとして動作する場合)や、ユーザーへのアサーションのマップ(サービス・プロバイダとして動作する場合)を行います。
|
注意: 本番環境では、XMLをフェデレーション・ストアとして構成することはお薦めしません。本番環境ではRDBMSまたはLDAPストアを使用してください。 |
ガイドライン
一般的なガイドラインを次に示します。
フェデレーション・データ・ストアがNoneに設定されている場合:
永続名前IDを使用することはできません。
アイデンティティ・プロバイダとして動作する場合、Oracle Identity Federationはアサーションを作成する際に、使用する名前IDフォーマットをユーザー・データ・ストアの属性にマッピングし、この属性の値を名前IDとして使用します。
サービス・プロバイダとして動作する場合、Oracle Identity Federationはアイデンティティ・プロバイダから受信したアサーションをマップする際に、属性問合せを使用するか、アサーションの名前IDをユーザー・データ・ストアのエントリにマッピングします。
フェデレーション・データ・ストアがXML、LDAPまたはRDBMSに設定されている場合:
永続名前IDを使用できます。
アイデンティティ・プロバイダとして動作する場合、Oracle Identity Federationはアサーションの作成時に、そのユーザーに作成されたフェデレーション・レコードの名前IDを使用します。
サービス・プロバイダとして動作する場合、Oracle Identity Federationはアサーションをユーザーにマップする際に、アサーションに含まれている名前IDでフェデレーション・レコードを検索します。
サービス・プロバイダとして動作し永続名前IDを使用する場合、そのユーザーとプロバイダが最初にSSOを実行するときにOracle Identity Federationによってローカル認証が求められます。
以降の項では、次の内容について説明します。
RDBMSフェデレーション・データ・ストアを構成するための大まかな手順は次のとおりです。
JDBCデータ・ソースを作成します。
RCUを実行してOracle Identity Federationスキーマを作成します。
|
注意: RCUに表示されるOracle Identity Federationスキーマの所有者とパスワードは、必ず書き留めておいてください。これは、PREFIX_OIFの形式で表されます。Oracle Identity Federationの構成時この情報を指定する必要があります。 |
Oracle Identity Federationデータ・ストア構成を変更します。
この手順には、ステップ1で作成した新しいデータ・ソースを使用するようにOracle Identity Federationを構成し、フェデレーション・データ・ストアを構成する手順が含まれます。
以降で、それぞれの手順を詳しく説明します。
JDBCデータ・ソースを作成します。
JDBCデータ・ソースを作成するには、次の手順に従います。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項 |
WebLogic管理コンソールにログインします。
「サービス」→「JDBC」→「データ・ソース」の順に移動します。
「新規」をクリックします。
新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。
Oracle Identity Federationスキーマの作成
第5.13.5項「RCUを使用したOracle Identity Federationスキーマの作成」の手順に従って、Oracle Identity Federationスキーマを作成します。
Oracle Identity Federationデータ・ストア構成を変更します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「データ・ストア」の順にナビゲートします。
「フェデレーション・データ・ストア」セクションで「編集」をクリックします。
「リポジトリ・タイプ」ドロップダウン・リストから「データベース」を選択します。
「JNDI名」を入力します。WebLogic管理コンソールで作成したデータ・ソースのJNDIを使用します。
「OK」をクリックします。
LDAPフェデレーション・データ・ストアを構成するには、次の手順に従います。
接続URL
サーバーに接続するLDAPのURLです。次に例を示します。
ldap://ldap.oif.com:389
このフィールドには、LDAP接続URLのスペース区切りリストを入力できます。
バインドDN
LDAPサーバーへの接続に使用する管理者アカウントDNです。次に例を示します。
cn=orcladmin
ユーザー・フェデレーション・レコード・コンテキスト
すべてのフェデレーション・レコードが格納されるLDAPコンテナ・エントリです。次に例を示します。
cn=fed,dc=us,dc=oracle,dc=com
|
注意:
|
LDAPコンテナ・オブジェクト・クラス
LDAPコンテナがまだない場合に、それを作成する際にOracle Identity Federationが使用するユーザー・フェデレーション・レコード・コンテキスト・クラスのタイプです。フィールドが空の場合、値はapplicationProcessに設定されます。
Microsoft Active Directoryの場合、このフィールドは、ユーザー・フェデレーション・レコード・コンテキストに応じて、たとえばcontainerに設定される必要があります。これは、Microsoft Active DirectoryではapplicationProcessが機能しないためです。
これらのフィールドの関係を理解するには、ユーザー・フェデレーション・レコード・コンテキストがフェデレーション・レコードの格納されるLDAPコンテナ・エントリを参照し、LDAPコンテナ・オブジェクト・クラスによって、DNに使用されるLDAPコンテナ属性が定義されることに注意してください。ユーザー・フェデレーション・レコード・コンテキストには、フェデレーション・レコードが格納されるコンテナのDNを指定します。そのDNには、既存のコンテナの親と、そのオブジェクト・クラスの一部であるフェデレーション・レコード・コンテキストの属性が含まれます。
たとえば、コンテナの親がdc=us,dc=oracle,dc=comで、レコード・コンテキスト属性がcn=orclfedである場合、cnは「LDAPコンテナ・オブジェクト・クラス」フィールド(設定されていない場合はapplicationProcessオブジェクト・クラス)で設定されたオブジェクト・クラスの属性である必要があるという要件があるため、DNは最終的に次のようになります。
cn=orclfed,dc=us,dc=oracle,dc=com
「ユーザー・フェデレーション・レコード・コンテキスト」のDNをou=fed,dc=us,dc=oracle,dc=comのように表示することにした場合、属性にouを持つオブジェクト・クラス(たとえばapplicationProcess)に、「LDAPコンテナ・オブジェクト・クラス」を設定する必要があります。
DNが次のようである場合は、
cn=fed,dc=us,dc=oracle,dc=com
LDAPコンテナ・オブジェクト・クラスはcn属性を定義する必要があります。
様々なタイプのディレクトリ・サーバーの場合のLDAPコンテナ・オブジェクト・クラスの例を次に示します。
Oracle Internet Directory: 空
Sun Java System Directory Server: 空
Microsoft Active Directory: container
最大接続数
Oracle Identity FederationがLDAPサーバーに同時に開くLDAP接続の数の最大値です。
接続待機タイムアウト
Oracle Identity FederationがLDAPサーバーへの接続を開く際に使用するタイムアウトです(単位は秒)。
XMLファイルをフェデレーション・データ・ストアとして使用するようにOracle Identity Federationを構成するには、次の手順に従います。
|
注意: 本番環境では、XMLをフェデレーション・ストアとして構成することはお薦めしません。本番環境ではRDBMSまたはLDAPストアを使用してください。 |
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「データ・ストア」の順にナビゲートします。
「フェデレーション・データ・ストア」セクションで「編集」をクリックします。
「リポジトリ・タイプ」ドロップダウン・リストからXMLファイルを選択します。
「OK」をクリックします。
Oracle Virtual DirectoryをOracle Identity Federation環境に統合してフェデレーション・データ・ストアとして動作させる場合、フェデレーション・レコード・コンテキストとLDAPコンテナ・オブジェクト・クラスの設定が、フェデレーション・レコードの格納に使用される特定のディレクトリ構造に対して有効であることを確認してください。つまり、フェデレーション・レコード・コンテキストによって参照されるLDAPサーバーのディレクトリ構造に対して有効である必要があります。
Oracle Identity Federationは、フェデレーション・プロトコル/セッションの状態などの一時データの格納にメッセージ・データ・ストアおよびユーザー・データ・ストアを使用します。メッセージ・データ・ストアはユーザー・セッション・データ・ストアとともに、一時データ・ストアとも呼ばれます。
一時データは、メモリー内またはリレーショナル・データベースに格納できます。
メモリー内セッション/メッセージ・データ・ストアを使用するようにOracle Identity Federationを構成するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「データ・ストア」の順にナビゲートします。
「セッション・データ・ストアとメッセージ・データ・ストア」セクションで、「編集」をクリックします。
「リポジトリ・タイプ」ドロップダウン・リストから「メモリー」を選択します。
RDBMSセッション/メッセージ・データ・ストアを使用するようにOracle Identity Federationを構成する大まかな手順は次のとおりです。
JDBCデータ・ソースを作成します。
RCUを実行してOracle Identity Federationスキーマを作成します。
|
注意: RCUに表示されるOracle Identity Federationスキーマの所有者とパスワードは、必ず書き留めておいてください。これは、PREFIX_OIFの形式で表されます。Oracle Identity Federationの構成時この情報を指定する必要があります。 |
Oracle Identity Federationのデータ・ストア構成を変更します。
この手順には、ステップ1で作成した新しいデータ・ソースを使用するようにOracle Identity Federationを構成し、フェデレーション・データ・ストアを構成する手順が含まれます。
以降で、それぞれの手順を詳しく説明します。
JDBCデータ・ソースを作成します。
JDBCデータ・ソースを作成するには、次の手順に従います。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項 |
WebLogic管理コンソールにログインします。
「サービス」→「JDBC」→「データ・ソース」の順に移動します。
「新規」をクリックします。
新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。
Oracle Identity Federationスキーマの作成
第5.13.5項「RCUを使用したOracle Identity Federationスキーマの作成」の手順に従って、Oracle Identity Federationスキーマを作成します。
Oracle Identity Federationデータ・ストア構成を変更します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「データ・ストア」の順にナビゲートします。
「構成データ・ストア」セクションで「編集」をクリックします。
「リポジトリ・タイプ」ドロップダウン・リストから「データベース」を選択します。
「JNDI名」を入力します。WebLogic管理コンソールで作成したデータ・ソースのJNDIを使用します。
「OK」をクリックします。
Oracle Identity Federationアプリケーションは、構成データ・ストアを使用して構成アーティファクトを格納します。構成データ・ストアは、XMLファイルまたはリレーショナル・データベースにすることができます。使用中のデプロイメントが高可用性デプロイメントの場合は、リレーショナル・データベースを構成データ・ストアとして使用する必要があります。
この項は次のトピックで構成されています。
構成データ・ストアは、基本インストール時にデフォルトでファイル・システムに格納されます。ストアをデータベースからファイル・システムに変更する手順は次のとおりです。
「管理」→「データ・ストア」の順にナビゲートします。
「構成データ・ストア」セクションで「編集」をクリックします。
「リポジトリ・タイプ」ドロップダウン・リストから「ファイル・システム」を選択します。
RDBMS構成データ・ストアを使用するようにOracle Identity Federationを構成する大まかな手順は次のとおりです。
JDBCデータ・ソースを作成します。
RCUを実行してOracle Identity Federationスキーマを作成します。
|
注意: RCUに表示されるOracle Identity Federationスキーマの所有者とパスワードは、必ず書き留めておいてください。これは、PREFIX_OIFの形式で表されます。Oracle Identity Federationの構成時この情報を指定する必要があります。 |
Oracle Identity Federationデータ・ストア構成を変更します。
この手順には、ステップ1で作成した新しいデータ・ソースを使用するようにOracle Identity Federationを構成し、構成データ・ストアを設定する手順が含まれます。
以降で、それぞれの手順を詳しく説明します。
JDBCデータ・ソースを作成します。
JDBCデータ・ソースを作成するには、次の手順に従います。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項 |
WebLogic管理コンソールにログインします。
「サービス」→「JDBC」→「データ・ソース」の順に移動します。
「新規」をクリックします。
新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。
Oracle Identity Federationスキーマの作成
第5.13.5項「RCUを使用したOracle Identity Federationスキーマの作成」の手順に従って、Oracle Identity Federationスキーマを作成します。
Oracle Identity Federationデータ・ストア構成を変更します。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「データ・ストア」の順にナビゲートします。
「構成データ・ストア」セクションで「編集」をクリックします。
「リポジトリ・タイプ」ドロップダウン・リストから「データベース」を選択します。
「JNDI名」を入力します。WebLogic管理コンソールで作成したデータ・ソースのJNDIを使用します。
「OK」をクリックします。
構成データ・ストアがRDBMSに統合されていて、そのデータベースが停止した場合、Oracle Identity FederationではRDBMSから取得した最新バージョンの構成データを使用できるため、実行時の操作は影響を受けません。ただし、RDBMSの停止中は構成を行わないでください。これは、変更内容がRDBMSに保存されず、構成の変更がデータベースに伝播されないためです。
この項では、RCUを使用してOracle Identity Federationスキーマを作成する方法について説明します。データベースを使用するようにデータ・ストアを構成するには、スキーマを作成する必要があります。
インストールCDまたはインストーラ・バイナリからRCUをインストールします。
$RCU_HOME/bin/rcuを実行します。
|
注意: RCUに表示されるOracle Identity Federationスキーマの所有者とパスワードは、必ず書き留めておいてください。これは、PREFIX_OIFの形式で表されます。Oracle Identity Federationの構成時この情報を指定する必要があります。 |
「作成」を選択してデータベースにコンポーネントを作成します。
次の画面でデータベース接続の詳細を入力します。
「コンポーネントの選択」画面の「アイデンティティ管理」から「Oracle Identity Federation」を選択します。
「スキーマ・パスワード」画面でパスワードを入力します。
処理を続行してOracle Identity Federationのスキーマ作成を完了させます。
認証メカニズムにはルールが含まれており、このルールにはエンティティのアイデンティティを検証するために資格証明をどのように使用するかが指定されています。
次の項では、認証メカニズムについて説明した後で、各サーバー・プロトコルの認証メカニズムを構成します。
認証メカニズムにより、認証が必要な場合にユーザーがチャレンジを受ける方法を指定します。選択肢として、ユーザー名/パスワード、Kerberosなどがあります。サービス・プロバイダは認証リクエストで認証方式を指定することにより、アイデンティティ・プロバイダに対して一定の方法でユーザーのチャレンジを行うようにリクエストできます。
SPおよびIdPは様々なプロトコルによる通信が可能なため、Oracle Identity Federationのローカル認証メカニズムはプロトコル固有の方式をマップできるよう定義されています。
たとえば、SAML 2.0方式urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordとSAML 1.x方式urn:oasis:names:tc:SAML:1.0:am:passwordをローカル認証メカニズムoracle:fed:authentication:passwordにマップできます。
Oracle Identity Federationはこうしたローカル認証メカニズムを次のような状況で使用します。
SPは、ユーザーの認証方法を示した認証方式をリクエストで指定できます。Oracle Identity Federation IdPはこのリクエストを受信すると、リクエストされた方式をローカル認証メカニズムにマップします。認証方式がリクエストされなかった場合、IdPではデフォルト認証メカニズムが使用されます。この認証メカニズムが認証エンジンにマップされ、ユーザーに対するチャレンジ方法が決定されます。
SPエンジンは、ローカル認証メカニズムを指定することにより、SPがアイデンティティ・プロバイダにリクエストする認証方式を指定できます。このローカル・メカニズム(SPエンジンが指定しなかった場合はデフォルト・メカニズム)はプロトコル固有の方式にマップされ、SPがアイデンティティ・プロバイダに送信する認証リクエストに組み込まれます。
SPエンジンが認証リクエストの送信先のアイデンティティ・プロバイダを指定しない場合、SPはIdPを特定する際に、SPエンジンから受信した認証メカニズムをアイデンティティ・プロバイダにマップします(エンジンがメカニズムを送信しなかった場合は、デフォルト・メカニズムを使用します)。
アサーションの作成時に、アイデンティティ・プロバイダはユーザーの認証に使用するメカニズムを決定し、対応するプロトコル固有の認証方式をアサーションで指定します。
ユーザー・セッションの作成時に、Oracle Identity Federationはユーザーの認証に使用するローカル認証メカニズムを記録します。
Oracle Identity Federation IdPでフェデレーションSSOプロキシ・認証エンジンを使用する場合、Oracle Identity Federation IdPはリクエストされた認証メカニズム(SPから方式のリクエストがなかった場合はデフォルト・メカニズム)を使用して、リクエストの送信先のアイデンティティ・プロバイダを特定します。この認証エンジンの詳細は、第5.15.9.1項「フェデレーテッドSSOプロキシ認証エンジンについて」を参照してください。
この項のその他の内容は次のとおりです。
サービス・プロバイダがリクエストで認証方式を指定しなかった場合、Oracle Identity Federation IdPでは前述のような状況でデフォルト認証メカニズムが使用されます。
デフォルト認証メカニズムを設定するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「認証メカニズム」の順に移動します。
デフォルト認証メカニズムを選択して、「適用」をクリックします。
前述のように、Oracle Identity Federationには次のようなマップ機能が用意されています。
これにより、サービス・プロバイダがリクエストで指定した認証方式に応じて異なる認証エンジンを使用できます。
たとえば、SAML 2.0プロトコルで次のようなマッピングを定義できます。
urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos -> oracle:fed:authentication:kerberos oracle:fed:authentication: kerberos -> Custom Kerberos Authentication Engine
および
urn:oasis:names:tc:SAML:2.0:ac:classes:Password -> oracle:fed:authentication:password oracle:fed:authentication:password -> Oracle Single Sign-On
SAML 2.0 SPが、メカニズムurn:oasis:names:tc:SAML:2.0:ac:classes:Kerberosによってユーザーを認証するようにリクエストした場合、Oracle Identity Federationは作成済のカスタム認証エンジンを使用し、Kerberosによってユーザーを認証します。一方、SPがメカニズムurn:oasis:names:tc:SAML:2.0:ac:classes:Passwordをリクエストした場合は、Oracle Single Sign-Onエンジンによってユーザーが認証されます。
構成する内容は次のとおりです。
ローカル認証メカニズムから認証エンジンへのマッピング
プロトコル固有の認証方式からローカル認証メカニズムのマッピング
次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「認証メカニズム」の順に移動します。
「ローカル・メカニズム」タブで、ローカル・メカニズムを有効にして認証エンジンにマップし、「適用」をクリックします。
たとえば、次のようなマッピングを追加します。
oracle:fed:authentication: kerberos -> Custom Kerberos Authentication Engine oracle:fed:authentication:password -> Oracle Single Sign-On
各プロトコルに固有のタブ(SAML 2.0、SAML 1.x、WS-Federation 1.1)で、プロトコル固有の認証方式をローカル・メカニズムにマップし、「適用」をクリックします。
たとえば、SAML 2.0タブで次のようなマッピングを追加します。
urn:oasis:names:tc:SAML:2.0:ac:classes: Kerberos -> oracle:fed:authentication: kerberos urn:oasis:names:tc:SAML:2.0:ac:classes:Password -> oracle:fed:authentication:password
ローカル認証メカニズムからアイデンティティ・プロバイダへのマッピングを構成するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「サービス・プロバイダ」の順に移動します。
「プロトコル設定」で、「アイデンティティ・プロバイダ・マッピングに対するSSO認証メカニズム」をクリックします。
「追加」をクリックして、認証メカニズムとマップ先のアイデンティティ・プロバイダを選択します。
マッピングの追加が完了したら、「OK」をクリックします。次に、「適用」をクリックします。
フェデレーションSSOプロキシ認証エンジンは、これらのマッピングを使用して、リクエストの送信先のアイデンティティ・プロバイダを決定します。
Oracle Identity Federationサービス・プロバイダも同様に、SPエンジンがSPへのリクエストでターゲットIdPを指定しなかった場合は、これらのマッピングを使用して、リクエストの送信先のアイデンティティ・プロバイダを特定します。たとえば、Oracle Access Manager SPエンジンを使用する場合、Oracle Access ManagerスキームをOracle Identity Federationのローカル認証メカニズムにマップできます。認証リクエストの送信先のアイデンティティ・プロバイダを特定する際にはこのマッピングが使用されます。
このページでは、次の操作を行います:
ローカル認証メカニズムの表示、追加、削除
選択した認証メカニズムの有効化または無効化
ローカル認証メカニズムから認証エンジンへのマップ
相対的な順序やローカル認証メカニズムの更新表内で上位の順序にあるメカニズムほど、より上位の認証レベルを持ちます。
認証メカニズムの表には次の列が表示されます。
ローカル認証メカニズムの名前
メカニズムに現在関連付けられている認証エンジン
そのメカニズムが現在アクティブかどうかを示すチェック・ボックス
メカニズムを有効(無効)にするには、「有効化」列で該当するボックスを選択(選択解除)します。
表示されたデータを変更するには、「表示」ドロップダウンを使用して希望のフィールドを選択します。
新しい認証メカニズムを追加するには、「追加」をクリックします。
既存の認証メカニズムを削除するには、そのメカニズムの行を選択して「削除」をクリックします。削除を確認するダイアログが表示されます。
メカニズムの順序を変更するには、行を選択してから表の上部にある矢印キーを使用します。
変更を保存するには「適用」を、データを前の状態にリセットするには「元に戻す」をクリックします。
このページでは、次の操作を行います:
SAML 2.0認証メカニズムの表示、追加、削除
SAML 2.0認証メカニズムからローカル認証メカニズムへのマップ
認証メカニズムの表には次の列が表示されます。
ローカル認証メカニズムの名前
メカニズムに現在関連付けられている認証エンジン
表示されたデータを変更するには、「表示」ドロップダウンを使用して希望のフィールドを選択します。
新しい認証メカニズムを追加するには、「追加」をクリックします。
既存の認証メカニズムを削除するには、そのメカニズムの行を選択して「削除」をクリックします。削除を確認するダイアログが表示されます。
変更を保存するには「適用」を、データを前の状態にリセットするには「元に戻す」をクリックします。
このページでは、次の操作を行います:
SAML 1.x認証メカニズムの表示、追加、削除
SAML 1.x認証メカニズムからローカル認証メカニズムへのマップ
認証メカニズムの表には次の列が表示されます。
SAML 1.x認証メカニズムの名前
メカニズムに現在関連付けられている認証エンジン
表示されたデータを変更するには、「表示」ドロップダウンを使用して希望のフィールドを選択します。
新しい認証メカニズムを追加するには、「追加」をクリックします。
既存の認証メカニズムを削除するには、そのメカニズムの行を選択して「削除」をクリックします。削除を確認するダイアログが表示されます。
変更を保存するには「適用」を、データを前の状態にリセットするには「元に戻す」をクリックします。
このページでは、次の操作を行います:
WS-Federation 1.1認証メカニズムの表示、追加、削除
WS-Federation 1.1認証メカニズムからローカル認証メカニズムへのマップ
認証メカニズムの表には次の列が表示されます。
WS-Federation 1.1認証メカニズムの名前
メカニズムに現在関連付けられている認証エンジン
表示されたデータを変更するには、「表示」ドロップダウンを使用して希望のフィールドを選択します。
新しい認証メカニズムを追加するには、「追加」をクリックします。
既存の認証メカニズムを削除するには、そのメカニズムの行を選択して「削除」をクリックします。削除を確認するダイアログが表示されます。
変更を保存するには「適用」を、データを前の状態にリセットするには「元に戻す」をクリックします。
このページで構成する内容は次のとおりです。
ユーザー・セッションの属性として使用されるHTTPヘッダー
これらのヘッダーを構成するには、「HTTPヘッダーの属性」の横にある「構成」ボタンをクリックします。表示されるダイアログ・ボックスで、ヘッダーの追加および既存ヘッダーの削除ができます。
Oracle Identity Federationサーバーの認証エンジン
このページは、それぞれの認証エンジン用のタブで構成されています。タブで行った更新は、他のタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
HTTPヘッダー認証エンジンはHTTPヘッダーの値に基づいてユーザーを認証します。
そのようなエンジンのデプロイメントは、通常次のように構成されます。
ドメインにデプロイされたOracle Identity Federationサーバー
Oracle Identity Federationが実行されているWebLogic管理対象サーバーの前面に配置されたWebサーバー(Oracle HTTP Serverなど)(Oracle HTTP Serverがインストールされていない場合のデプロイ方法と統合方法の詳細は、第3.2.1項「Oracle Identity FederationとOracle HTTP Serverのデプロイ」を参照してください。)
Webサーバーに統合されたWebエージェント。HTTPヘッダー認証エンジンのURL(http(s)://oif-host:oif-port/fed/user/authnhttp)を保護します。
HTTPヘッダー認証エンジンのURLのWebエージェント・ポリシー。エージェントに対して、ユーザーのアイデンティティをHTTPヘッダー変数として設定するように指示します。
ユーザーのアイデンティティを含むHTTPリクエストからHTTPヘッダー変数を取得するように構成されたOracle Identity Federation
WebエージェントによってHTTPヘッダー認証エンジンのURLが保護されるため、このURLでOracle Identity Federationサーバーが処理するリクエストは、Webエージェントが属しているWebアクセス管理システムによってユーザー認証が行われていることになります。
「HTTPヘッダー」タブには次のフィールドがあります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。
ユーザーの一意IDヘッダー: Oracle Identity FederationでHTTPヘッダー・エンジンを認証エンジンとして使用する場合、WebエージェントはOracle HTTP Server/Oracle Identity Federationに統合され、Oracle Identity Federation URLを保護します。Oracle Identity Federation URLのポリシー・ドメインは、ユーザー識別子をHTTPヘッダーとして提供するように構成されます。
このフィールドでは、Webエージェントから提供されるユーザー識別子を含むHTTPヘッダーの名前を指定します。
ログアウト有効: このボックスを選択すると、このエンジンによるログアウトが有効になります。ログアウトを有効にする場合、次のフィールドが関連します。
ログアウトURL: Webアクセス管理システムのログアウト時に、Oracle Identity Federationによってユーザーがリダイレクトされる必要のあるURLです。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
|
注意: ユーザーのログアウト時に、(ログアウト操作を実行するために)Webアクセス管理URLにリダイレクトする必要がある場合は、「ログアウト有効」を選択し、ユーザーのリダイレクト先のURLを入力して、Oracle Identity Federationを構成する必要があります。Oracle Identity FederationによってユーザーがそのURLにリダイレクトされると、戻りURLが問合せパラメータとして追加されます。これは、Webアクセス管理のログアウト操作が実行された後でユーザーがリダイレクトされるOracle Identity FederationのURLです。Oracle Identity Federationは、 |
HTTPヘッダーの属性モジュールは、ローカル認証操作が成功した場合に呼び出されます。この操作では、ユーザーのHTTPリクエストからHTTPヘッダーが抽出され、Oracle Identity Federationセッションの属性として保存されます。Oracle Identity Federationがアイデンティティ・プロバイダとして動作する場合、これらの属性を使用してSAMLアサーションに移入できます。
HTTPヘッダーの属性モジュールを構成するには、次の手順を実行します。
「認証エンジン」セクションで、「構成」をクリックして、HTTPヘッダーの属性モジュールを管理します。
HTTPヘッダーの属性がリストされたウィンドウが表示されます。この属性は、ローカル認証操作が成功した場合にOracle Identity Federationによって収集されます。
HTTPヘッダーを追加して、セッション属性として収集および保存されるようにするには、次のようにします。
「追加」をクリックします。
HTTPヘッダーを取得するために、新しいフィールドにその名前を入力します。たとえば、Accept Languageヘッダーを取得するには、Accept-Languageと入力します。
HTTPリクエストで提供されたCookieの値を取得するには、接頭辞にorafed-cookie-を使用してCookieの名前を入力します。たとえば、userLanguageCookieというCookieの値を取得するには、orafed-cookie-userLanguageCookieと入力します。Oracle Identity Federationは、実行時にCookieを取得して値を抽出し、orafed-cookie-userLanguageCookieセッション属性を設定します。
HTTPヘッダーを削除するには、次のようにします。
削除するHTTPヘッダーを選択します。
「削除」をクリックします。
「OK」をクリックして変更を保存します。
HTTPヘッダーの属性モジュールを構成したら、Oracle Identity Federationを構成して、アサーションの作成時にこれらのセッション属性を使用して次のものに移入できます。
アサーションのSubjectの名前識別子の値
アサーションの属性。たとえば、「Accept-Language」および「orafed-cookie-userLanguageCookie」をアサーション属性として送信するには、それらを信頼できるサービス・プロバイダの「属性マッピングとフィルタ」セクションでリストします。
実行時のフローは次のようになります。
Oracle Identity Federationは、ユーザーの認証が必要かどうかを判断し、認証エンジンを呼び出してそのユーザーのチャレンジと識別を行います。
ユーザーは、資格証明または情報(たとえば、LDAP認証エンジンの資格証明処理URLにPOSTするユーザー名とパスワード)を提供するために、認証エンジンURLにデータを送信します。
ユーザー・データが検証されると、エンジンが内部的にユーザーをOracle Identity Federationに再転送します。
HTTPヘッダーの属性モジュールが、認証エンジンに送信されたHTTPリクエストを解析します(内部転送操作により、モジュールがリクエストにアクセスできます)。このモジュールは必要なHTTPヘッダーやCookieの値をこのリクエストから抽出します。
Oracle Identity Federationは抽出されたデータをセッション属性として保存します。
アサーションの作成時に、Oracle Identity Federation/IdPはセッション属性を使用して名前IDや属性の要素を移入します(このように構成されている場合)。
このタブには次のフィールドがあります。
デフォルトの認証エンジン: 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。
ユーザーの一意ID属性: Oracle Identity Federationがユーザーの識別に使用する属性です。
|
注意:
|
ログアウトURL: ログアウト時に表示されるOracle Single Sign-OnサーバーのURLです。
ログアウト有効: このボックスを選択すると、Oracle Identity Federationログアウト・フローの実行時に、Oracle Identity FederationによってユーザーがOracle SSOログアウトURLにリダイレクトされるように指定できます。
ログアウトURLは、次のようなOracle SSOログアウトURLにする必要があります。
http(s)://sso-host:sso-port/sso/logout
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブは、Oracle Access Manager 11g認証エンジンを構成する際に使用します。
このタブには次のフィールドがあります。
デフォルトの認証エンジン: 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。
エージェント・タイプ: エージェントは、Webgate11g、Webgate10g、mod_ossoのいずれかである必要があります。
ユーザーの一意IDヘッダー: Oracle Identity Federationがユーザーの識別に使用する属性です。mod_ossoエージェントの場合、ここはドロップダウン・リストが表示され、デフォルトではProxy Remote Userに設定されています。Webgate10gまたはWebgate11gの場合のデフォルトは、OAM_REMOTE_USERです。
|
注意:
|
ログアウトURL: ログアウト時に表示されるOracle Access ManagerサーバーのURLです。次に例を示します。
http://oam_host:oam_port/oam/server/logout
|
注意: SPとOAM11gエンジンとの統合が有効で、ログアウトの構成がされている場合、OAM11g認証エンジンでログアウトを構成する必要はありません。 |
ログアウト有効: このボックスを選択すると、Oracle Identity Federationログアウト・フローの実行時に、Oracle Identity FederationによってユーザーがOracle Access ManagerログアウトURLにリダイレクトされるように指定できます。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブには次のフィールドがあります。
デフォルトの認証エンジン: 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。
ユーザーの一意IDヘッダー: Oracle Identity FederationでOracle Access Managerを認証エンジンとして使用する場合、WebGateはOracle HTTP Server/Oracle Identity Federationに統合され、Oracle Identity Federation URLを保護します。Oracle Identity Federation URLのポリシー・ドメインは、ユーザー識別子をHTTPヘッダーとして提供するように構成されます。
このフィールドでは、WebGateから提供されるユーザー識別子を含むHTTPヘッダーの名前を指定します。
ログアウト有効: このボックスを選択すると、このエンジンによるログアウトが有効になります。ログアウトを有効にする場合、次のフィールドが関連します。
Cookieのクリア: 選択した場合、Oracle Access ManagerのCookieは、ユーザーがOracle Access Managerドメインからログアウトする際にOracle Identity Federationによってリセットされます。
Cookieドメイン: Oracle Access ManagerのCookieの作成時に、Oracle Identity Federationによって設定されるCookieドメインです。
ログアウトURLへのリダイレクト: Oracle Access Managerのログアウト時にOracle Identity Federationによってユーザーを特定のURLにリダイレクトする必要がある場合は、このボックスを選択してURLを入力します。
ログアウトURL: ログアウト時に表示されるURLです。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブには次のフィールドがあります。
デフォルトの認証エンジン: 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。
接続URL: ホスト名とポートで構成されるLDAPサーバーURLのスペース区切りリストです。
バインドDN: Oracle Identity FederationサーバーがLDAPサーバーに接続するために使用するDNです。次に例を示します。
cn=fedid,dc=mycompany,dc=com
パスワード: サーバーのパスワードです。
パスワードの確認: サーバーのパスワードです。
最大接続数: Oracle Identity FederationによってLDAPサーバーに作成される同時接続数の最大値です。
ユーザー資格証明ID属性: Oracle Identity Federationがユーザーの認証に使用する属性です。
たとえば、ここで構成される属性がmailで、ユーザーのこの属性の値がalice@mycorp.comの場合、ユーザーはユーザー名alice@mycorp.comで認証される必要があります。
|
注意: ここで構成する属性の値は、すべてのユーザーで一意である必要があります。 |
ユーザーの一意ID属性: Oracle Identity Federationがユーザーを識別する属性です。
|
注意:
|
個人オブジェクト・クラス: 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サーバーに開かれた接続数が最大値に達した場合に、接続が利用可能になるまで待機する秒数の最大値です。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
LDAP認証エンジンの構成に関する詳細は、次を参照してください。
第5.13.1.4項「冗長性ユーザー・データ・ストアの構成」では、LDAPサーバーの前面にロード・バランサを構成する方法について説明しています。
このタブには次のフィールドがあります。
デフォルトの認証エンジン: 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。
JDBC URL: データベースの接続URLです。
JDBCドライバ: JDBCドライバ文字列を入力します。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブには次のフィールドがあります。
デフォルトの認証エンジン: 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられたリスト・ボックス)にこのエンジンが表示されます。
JNDI名: Oracle WebLogic Server管理コンソールで作成したデータ・ソースのJNDIです。
ログイン表: ログイン表の名前です。
ログインID列: ログイン表のログインID列の名前です。
ユーザーの一意ID列: ログイン表のユーザーID列の名前です。
ログイン・パスワード列: ログイン表のログイン・パスワード列の名前です。
パスワード・ダイジェスト・アルゴリズム: ログイン表のパスワードに適用されるダイジェスト・アルゴリズムです。パスワードをクリアテキストでデータベースに格納する場合は、Noneを選択します。パスワードのMD5ハッシュ値またはSHA1ハッシュ値をデータベースに格納する場合は、MD5またはSHA1を選択します。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
Oracle Identity Federationでデータベースを認証エンジンとして使用するには、ログイン表と呼ばれる、ユーザーのログイン情報を格納する表をそのデータベースで使用する必要があります。ログイン表の各ユーザーは次の属性を持っている必要があります。
ログインID: ユーザーがログイン時に使用する一意のユーザー名です。
ログイン・パスワード: ユーザーがログイン時に使用するパスワードです。この列の値は、クリアテキスト・パスワード、パスワードのMD5ハッシュ値またはSHA1ハッシュ値にできます。
ユーザーID: Oracle Identity Federationがユーザーを識別する一意の識別子です。ユーザーIDの値は、ユーザー・データ・ストアのユーザーIDの値と一致する必要があります。
ログインID属性とユーザーID属性は2つの別々の列に格納できます。または、ログインIDをユーザーIDとして使用する場合は1つの列に格納することもできます。
例1
次のような「UserLoginInfo1」というログイン表があるとします。この表では、ログインIDは列「Email」に、ユーザーIDは列「UserID」に含まれます。
| UserID | FirstName | LastName | Password | |
|---|---|---|---|---|
| alice | Alice | Smith | gu*L3nb | alice@mycorp.com |
| bob | Robert | Jones | aqweb80 | bob@mycorp.com |
| charlie | Charles | Johnson | b23thag | charlie@mycorp.com |
| david | David | Jones | 094bshyq= | david@mycorp.com |
| robert | Robert | Williams | #)haba*(+ | williams@mycorp.com |
例2
次のような「UserLoginInfo2」というログイン表があるとします。この表では、ログインIDとユーザーIDはともに「Username」列に含まれます。
| Username | Password | FullName |
|---|---|---|
| alice | gu*L3nb | Alice Smith |
| bob | aqweb80 | Robert Jones |
| charlie | b23thag | Charles Johnson |
| david | 094bshyq= | David Jones |
| robert | #)haba*(+ | Robert Williams |
RDBMS認証エンジンを使用するようにOracle Identity Federationを構成するには、次の手順が必要です。
JDBCデータ・ソースを作成します。
Oracle Identity Federation認証エンジンを変更します。
JDBCデータ・ソースを作成します。
RDBMSユーザー・データ・ストアを構成するには、次の手順に従います。
WebLogic管理コンソールにログインします。
「サービス」→「JDBC」→「データ・ソース」の順に移動します。
「新規」をクリックします。
新しいデータ・ソースの名前とJNDI名を選択して、データベース情報を入力します。Oracle Identity Federationがこのデータ・ソースのターゲットとしてデプロイされるWebLogic管理対象サーバーを選択します。
|
関連項目: 『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソールの使用開始に関する項 |
Oracle Identity Federation認証エンジンの変更
RDBMS認証エンジンを構成するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「認証エンジン」の順に移動します。
「データベース表」タブで、「認証エンジンの有効化」を選択し、次のプロパティを追加します。
JNDI名: WebLogic管理コンソールで作成したデータ・ソースのJNDIです。
ログイン表: ログイン表の名前です。
ログインID列: ログイン表のログインID列の名前です。
ユーザーの一意ID属性: ログイン表のユーザーID列の名前です。
ログイン・パスワード列: ログイン表のログイン・パスワード列の名前です。
パスワード・ダイジェスト・アルゴリズム: ログイン表のパスワードに適用されるダイジェスト・アルゴリズムです。
パスワードをクリアテキストでデータベースに格納する場合は、Noneを選択します。パスワードのMD5ハッシュ値またはSHA1ハッシュ値をデータベースに格納する場合は、MD5またはSHA1を選択します。
「適用」をクリックします。
例1の構成
前述の例1の表「UserLoginInfo1」に対応する構成は次のとおりです。このデータベースに作成されているデータ・ソースのJNDI名は「MyCorpUserDS」であるとします。
JNDI名: MyCorpUserDS
ログイン表: UserLoginInfo1
ログインID列: Email
ユーザーの一意ID属性: UserID
ログイン・パスワード列: Password
パスワード・ダイジェスト・アルゴリズム: None/MD5/SHA1
例2の構成
前述の例2の表「UserLoginInfo2」に対応する構成は次のとおりです。このデータベースに作成されているデータ・ソースのJNDI名は「MyCorpUserDS」であるとします。
JNDI名: MyCorpUserDS
ログイン表: UserLoginInfo2
ログインID列: Username
ユーザーの一意ID属性: Username
ログイン・パスワード列: Password
パスワード・ダイジェスト・アルゴリズム: None/MD5/SHA1
このタブには次のフィールドがあります。
デフォルトの認証エンジン: 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。
アサーションのユーザーへのマップ: 選択した場合、着信アサーションは「サービス・プロバイダ」ページのSAML 2.0/SAML 1.xアサーションタブの構成に基づいてユーザー・レコードにマップされます。
情報カード・プロバイダごとに1つのエントリを表示: 選択した場合、「フェデレーション」ページで構成した情報カード・プロバイダごとに情報カード選択オプションが表示されます。
認証メカニズムを含む: 選択した場合、Oracle Identity Federationは認証メカニズムを必要なクレームとして追加し、情報カード・プロバイダからの特定の認証方式をリクエストできます。
個人カード発行者にマップされた認証メカニズム: ここで構成した認証メカニズムによって情報カード認証エンジンが呼び出され認証が行われる場合、個人発行者カードがログイン・ページに表示されます。ここで構成した認証メカニズム以外で呼び出された場合は、すべての情報カード・プロバイダが表示されます。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブには次のフィールドがあります。
デフォルトの認証エンジン: 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。
認証メカニズム: フェデレーテッドSSOプロキシを使用する場合に、Oracle Identity Federationがユーザーをロカールに認証するために使用する認証メカニズムです。
|
警告: ここで指定した認証メカニズムを、フェデレーテッドSSOプロキシ認証エンジンにマップしないでください。 |
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
その他の内容は次のとおりです。
アイデンティティ・プロバイダがフェデレーテッドSSOプロキシ認証エンジンを使用してユーザーを認証する場合、このアイデンティティ・プロバイダは、認証を行うためにサービス・プロバイダの役割を果たし、ユーザーを認証する2つ目のアイデンティティ・プロバイダとシングル・サインオン・フローを開始します。
フローは次のようになります。
サービス・プロバイダ(SP-1)が、認証リクエストをOracle Identity Federationアイデンティティ・プロバイダ(IdP-1)に送信します。
Oracle Identity Federation/IdP-1は、フェデレーテッドSSOプロキシ認証エンジンを使用しているので、信頼できるアイデンティティ・プロバイダ(IdP-2)を選択して、サービス・プロバイダの役割を担い、指定のユーザーの新しい認証リクエストをIdP-2に送信します。
IdP-2がユーザーを認証します。
IdP-2は、アサーションをOracle Identity Federation/IdP-1に送り返し、Oracle Identity Federation/IdP-1は、このアサーションを処理します。
必要に応じて(フェデレーションの作成処理を実行する必要がある場合など)、Oracle Identity Federation/IdP-1はユーザーをローカルに認証します。
Oracle Identity Federation/IdP-1が、新しいアサーションをSP-1に送り返します。
フェデレーテッドSSOプロキシ認証エンジンを使用するアイデンティティ・プロバイダは、サービス・プロバイダから認証リクエストを受信すると、新しいリクエストの送信先となる信頼できるアイデンティティ・プロバイダを選択します。アイデンティティ・プロバイダを選択するために、Oracle Identity Federationは、サービス・プロバイダからリクエストされた認証メカニズム(SPが認証メカニズムをリクエストしなかった場合はデフォルトのメカニズム)をアイデンティティ・プロバイダにマップし、このIdPに新しいリクエストを送信します。
このメカニズムがアイデンティティ・プロバイダにマップされていない場合は、Oracle Identity Federationによって構成内のデフォルト・アイデンティティ・プロバイダが使用されます。(認証メカニズムの詳細およびプロトコル固有の方式がローカル認証メカニズムにマップされる仕組みの詳細は、第5.14.1項「認証メカニズムについて」を参照してください)。
たとえば、ローカル認証メカニズムからアイデンティティ・プロバイダに対して次のようなマッピングが構成されているとします。
oracle:fed:authentication:internet-protocol -> http://corp-1.com/idp oracle:fed:authentication:password-protected -> http://corp-2.com/idp
また、デフォルト・アイデンティティ・プロバイダはhttp://corp-3.com/idpであるとします。
このとき、サービス・プロバイダがoracle:fed:authentication:internet-protocolにマップされている認証方式をリクエストすると、Oracle Identity Federationはhttp://corp-1.com/idpをアイデンティティ・プロバイダとして選択します。ただし、サービス・プロバイダがoracle:fed:authentication:password-protectedをリクエストすると、Oracle Identity Federationはhttp://corp-2.com/idpを選択します。サービス・プロバイダが認証方式をリクエストしない場合、Oracle Identity Federationは新しい認証リクエストをhttp://corp-3.com/idpに送信します。
ローカル認証メカニズムからアイデンティティ・プロバイダへのマッピングを定義するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「サービス・プロバイダ」の順に移動します。
「プロトコル設定」で、「アイデンティティ・プロバイダ・マッピングに対するSSO認証メカニズム」をクリックします。
「追加」をクリックして、認証メカニズムとマップ先のアイデンティティ・プロバイダを選択します。
マッピングの追加が完了したら、「OK」をクリックします。次に、「適用」をクリックします。
デフォルト・アイデンティティ・プロバイダを構成するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「サービス・プロバイダ」の順に移動します。
「デフォルトSSOアイデンティティ・プロバイダ」を選択して、「適用」をクリックします。
フェデレーテッドSSOプロキシ認証エンジンを正しく使用するには、認証メカニズムを構成する必要があります。たとえば、次のようなことがあります。
デフォルト認証メカニズムの設定
プロトコル固有の方式からローカル・メカニズムへのマッピングおよびローカル・メカニズムから認証エンジンのマッピング
ローカル認証メカニズムからアイデンティティ・プロバイダへのマッピング
認証メカニズムの構成に加えて、フェデレーテッドSSOプロキシ認証エンジン自体も構成する必要があります。これを実行するには、次の手順に従います。
Fusion Middleware Controlにログインして、Oracle Identity Federationインスタンスに移動します。
「管理」→「認証エンジン」の順に移動します。
「フェデレーテッドSSOプロキシ」タブで、「認証エンジンの有効化」を選択し、必要に応じてユーザーのローカル認証に使用する認証メカニズムを選択します。
|
警告: ユーザーのローカル認証に使用するローカル認証メカニズムを、フェデレーテッドSSOプロキシ認証エンジンにマップしないでください。そうした場合、IdP-1からIdP-2にリクエストが連続的に送信されるため、ループが発生します。(IdP-1はIdP-2にリクエストを送信し、アサーションを受信します。IdP-1はユーザーをローカルに認証する必要があるため、メカニズムをフェデレーテッドSSOプロキシ認証エンジンにマップします。これにより、IdP-1はIdP-2に新しいリクエストを送信するよう求められます)。 |
認証メカニズムの詳細および認証メカニズムを認証エンジンにマップする方法の詳細は、第5.14.1項「認証メカニズムについて」を参照してください。
JAAS認証エンジンはOracle Identity Federationサーバーのデフォルト認証エンジンです。
このエンジンを有効または無効にするには、「認証エンジンの有効化」チェック・ボックスを使用します。
JAASはデフォルト・エンジンであるため、このボックスはデフォルトで選択されています。JAAS認証エンジンを無効にする場合、別のエンジンがデフォルト・エンジンとして機能するようにする必要があります。必要に応じて、先に別の認証エンジンを設定してからこのタブに戻り、JAASエンジンを無効にします。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
|
注意: JAAS認証エンジンはログアウトをサポートしていません。つまり、このエンジンを使用するプロバイダを構成して、IdPとSPの間でシングル・サインオンを実行し、Oracle Identity FederationのログアウトURLhttp://host:port/fed/user/logoutを発行すると、ユーザーはログアウトされないので、再度ログインせずにSSOフローを実行できます。 |
ユーザーの作成およびoifusersグループへの追加
JAAS認証エンジンで認証を受けるユーザーは、Oracle Identity FederationがデプロイされているWLSドメインのセキュリティ・レルムに対応するユーザー・エントリが存在している必要があります。また、oifusersグループに含まれている必要があります。
oifusersグループを作成して新しいユーザーを追加するには、次の手順に従います。
|
関連項目: Oracle Fusion Middlewareの管理の概要 |
Oracle WebLogic Server管理コンソールにログインします。
左側のペインで、「セキュリティ・レルム」を選択し、「myrealm」→「ユーザーとグループ」→「グループ」の順に移動します。
「新規」をクリックして、名前にoifusersと入力します。
「ユーザーとグループ」→「ユーザー」の順に移動します。
「新規」をクリックして、名前とパスワードを選択します。
作成したユーザーをクリックして、「グループ」タブを選択します。
グループoifusersを選択して「選択済み」列に移動します。「保存」をクリックします。
さらにユーザーを入力するには、ステップ4から7までを繰り返します。グループとユーザーを作成したら、管理サーバーおよびOracle Identity Federationが実行されている管理対象サーバーを再起動して、変更を有効にする必要があります。
このタブでは、カスタム認証エンジンを設定できます。
カスタム・エンジンの表示
カスタム・エンジンの表を並べ替えるには、「表示」ボタンを使用します。列の表示順序を変更して、含めるまたは除外するフィールドを指定できます。「列の並替え」ダイアログでは、任意のフィールドを選択し、矢印を使用してそのフィールドを表に再配置できます。
エンジンの追加
「追加」をクリックして、新しいカスタム・エンジンを追加します。一意のエンジン名を入力するよう求められ、エンジンIDが自動的に生成されます。エンジンを追加した後で、次の情報を追加できます。
有効: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。
Webコンテキスト: カスタム認証エンジンをデプロイするWebアプリケーション・コンテキストを指定します。
認証相対パス: カスタム認証エンジンに対する、Webコンテキストからの相対パスを指定します。
ログアウト相対パス: カスタム認証エンジンのログアウト・サービス(使用する場合)に対する、Webコンテキストからの相対パスを指定します。たとえば、「/auth_engines/myAuthLogout.jsp」などです。
このタブには次のフィールドがあります。
デフォルトの認証エンジン: 認証に使用するエンジンです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
認証エンジンの有効化: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。有効にした場合、使用可能なエンジンのリスト(「デフォルトの認証エンジン」に関連付けられているリスト・ボックス)にこのエンジンが表示されます。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このページは、Oracle Identity FederationのSP統合モジュールを構成する場合に使用します。
このページは、それぞれのSP統合モジュール用のタブで構成されています。タブで行った更新は、他のタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブは、Oracle Single Sign-On用のSP統合を構成する場合に使用します。
このタブには次のフィールドがあります。
デフォルトSP統合モジュール: サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
SPモジュールの有効化: このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。
認証メカニズム: フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合に、ユーザーをローカルに認証するために使用される認証メカニズムです。
ユーザー名属性: Oracle Identity FederationからOracle SSOに渡す必要のあるユーザー名属性です。デフォルトはuidです。
ログインURL: ログイン時に表示されるOracle Single Sign-OnサーバーのURLです。次に例を示します。
http://sso_host:sso_port/sso/auth
ログアウトURL: ログアウト時に表示されるOracle Single Sign-OnサーバーのURLです。次に例を示します。
http://sso_host:sso_port/sso/logout
ログアウト有効: Oracle Single Sign-Onアプリケーションでのログアウトを有効/無効にします。
「再生成」ボタンをクリックすると暗号化鍵が作成されます。この暗号化鍵はファイルに保存され、Oracle SSOサーバーに渡されます。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブは、Oracle Access Manager 11g用のSP統合を構成する場合に使用します。
このタブには次のフィールドがあります。
デフォルトSP統合モジュール: サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
SPモジュールの有効化: このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。
認証メカニズム: フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合に、ユーザーをローカルに認証するために使用される認証メカニズムです。
ユーザー名属性: Oracle Identity FederationからOracle Access Managerに渡す必要のあるユーザー名属性です。デフォルトはcnです。
ログインURL: ログイン時に表示されるOracle Access ManagerサーバーのURLです。次に例を示します。
http://oam_host:oam_port/oam/server/dap/cred_submit
ログアウトURL: ログアウト時に表示されるOracle Access ManagerサーバーのURLです。次に例を示します。
http://oam_host:oam_port/oam/server/logout
ログアウト有効: Oracle Access Managerでのログアウトを有効/無効にします。
「再生成」ボタンをクリックするとキーストア・ファイルが生成されます。このファイルには、Oracle Access ManagerとOracle Identity Federationサーバーの間で交換されるトークンの暗号化および復号化に使用される鍵が含まれています。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブは、Oracle Access Manager用のSP統合を構成する場合に使用します。
|
関連項目: Oracle Access ManagerをSP統合エンジンとして構成する場合の詳細は、第3.2.3.3項「SP統合モジュールとしてのOracle Access Managerの統合」を参照してください。 |
このタブには次のフィールドがあります。
デフォルトSP統合モジュール: サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
SPモジュールの有効化: このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。
認証メカニズム: フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合に、ユーザーをローカルに認証するために使用される認証メカニズムです。
サーバーSDKディレクトリへのアクセス: アクセス・サーバーSDKのディレクトリの場所です。DOMAIN_HOMEへの絶対パスまたは相対パスです。
デフォルトの認証スキーム: Oracle Identity Federationで作成されたポリシーのデフォルト・スキームとして使用されるOracle Access Managerの認証スキームです。
Cookieドメイン: Oracle Access ManagerのCookieの作成時に、Oracle Identity Federationによって設定されるCookieドメインです。
永続Cookieの場合は、Cookieの有効期間です(単位は分)。セッションCookieの場合は0を入力します。
Cookieセキュア・フラグ設定済: Cookieの安全性を示す必要があるかどうかをチェックします。示す必要がある場合、ブラウザはCookieをHTTPS接続経由で送信します。
ログアウト有効: Oracle Access Managerアプリケーションでのログアウトを有効/無効にします。
Cookieのクリア: 選択した場合、Oracle Access ManagerのCookieは、ユーザーがOracle Access Managerドメインからログアウトする際にOracle Identity Federationによってリセットされます。
ログアウトURLへのリダイレクト: Oracle Access Managerのログアウト時にOracle Identity Federationによってユーザーを特定のURLにリダイレクトする必要がある場合は、「ログアウトURLへのリダイレクト」を選択してURLを入力します。
|
注意: ユーザーのログアウト時にOracle Access ManagerのURLにリダイレクトする必要がある場合(Oracle Access Managerで追加の処理を実行する必要がある場合)は、「ログアウトURLへのリダイレクト」ボックスを選択し、ユーザーのリダイレクト先のURLを入力して、Oracle Identity Federationを構成する必要があります。Oracle Identity FederationによってユーザーがそのURLにリダイレクトされると、戻りURLが問合せパラメータとして追加されます。これは、Oracle Access Managerで追加の処理が実行された後でユーザーがリダイレクトされるOracle Identity FederationのURLです。Oracle Access ManageのログアウトURLに追加される問合せパラメータは、 |
このタブには、Oracle Access ManagerとOracle Identity Federationの統合に必要な次のフィールドがあります。
ポリシー・ドメインの構成に必要なOracle Access Manager資格証明
サーバー自身の認証をOracle Identity Federationで可能にするためのOracle Identity Federationアカウント情報
これらの機能の詳細は、第3.2.3.3項「SP統合モジュールとしてのOracle Access Managerの統合」および第3.2.4項「Oracle Access Managerに対するOracle Identity Federation/SPの認証」.
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブは、テストSPエンジン用のSP統合を構成する場合に使用します。
このタブには次のフィールドがあります。
デフォルトSP統合モジュール: サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
SPモジュールの有効化: このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。
認証メカニズム: フェデレーションSSO処理でフェデレーテッドIDを使用し、SSO処理でフェデレーション・レコードを作成する必要がある場合に、ユーザーをローカルに認証するために使用される認証メカニズムです。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
このタブは、カスタムSPエンジン用のSP統合を構成する場合に使用します。
このタブには次のフィールドがあります。
デフォルトSP統合モジュール: サービス・プロバイダで統合に使用するモジュールです。このリスト・ボックスには現在有効なすべてのエンジンが含まれます。リストからエンジンを選択すると、選択したエンジンがデフォルトのエンジンになります。
SPモジュールの有効化: このボックスを選択すると、モジュールが有効になります。ボックスの選択を解除すると、モジュールが無効になります。有効にした場合、使用可能なモジュールのリスト(「デフォルトSP統合モジュール」に関連付けられたリスト・ボックスにこのモジュールが表示されます)。
SP統合モジュールの表示
SP統合モジュールの表を並べ替えるには、「表示」ボタンを使用します。列の表示順序を変更して、含めるまたは除外するフィールドを指定できます。「列の並替え」ダイアログでは、任意のフィールドを選択し、矢印を使用してそのフィールドを表に再配置できます。
エンジンの追加
「追加」ボタンをクリックして、新しいカスタム・エンジンを追加します。一意のエンジン名を入力するよう求められ、エンジンIDが自動的に生成されます。エンジンを追加した後で、次の情報を追加できます。
有効: このボックスを選択すると、エンジンが有効になります。ボックスの選択を解除すると、エンジンが無効になります。
認証メカニズム: アサーションの処理時にローカル認証を行う必要がある場合に使用する認証メカニズムです。
Webコンテキスト: SP統合エンジンのcontextPathを「Webコンテキスト」フィールドに指定します。たとえば、/engineなどです。
認証相対パス: SP統合エンジンのログイン・サービスの相対パスを「ログイン相対パス」フィールドに指定します。たとえば、/application.jspなどです。
ログアウト相対パス: SP統合エンジンのログアウト・サービスの相対パスを「ログアウト相対パス」フィールドに指定します。
このタブで行った更新は、他の認証エンジンのタブに移動する際に保存されます。変更が済んだら、「適用」をクリックして変更を保存します。または、「元に戻す」をクリックするとデータを前の状態にリセットできます。
