ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Access Management管理者ガイド
11gリリース2 (11.1.2.2) for All Platforms
B69533-09
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

31 Identity Federationパートナの管理

この章では、Oracle Access Management Identity Federationにおけるフェデレーション・パートナ(サービス・プロバイダとアイデンティティ・プロバイダ)の概念について説明します。この章には次の項が含まれます:

31.1 フェデレーションとパートナについての理解

この章の内容は、Oracle Fusion Middleware Oracle Identity Federation管理者ガイドに記載されているフェデレーションとパートナの概念をある程度理解していることを前提としています。また、第30.8項「Identity Federationの有効化」を行っていることも前提とされます。

31.2 フェデレーション・パートナの管理

この11gリリース2 (11.1.2.2)の統合Identity Federationは、サービス・プロバイダ(SP)またはアイデンティティ・プロバイダ(IdP)として構成できます。このプロバイダ定義に続いて、フェデレーションSSOでパートナとなるリモート・プロバイダ(サービスまたはアイデンティティ)も管理する必要があります。このため、Identity Federationでは、パートナとパートナ・プロファイルという構成階層概念を生み出しています。

  • パートナ・プロファイルとは、パートナ・タイプ(IdPまたはSP)とプロトコル・バージョン(SAML 2.0、SAML 1.1、OpenID 2.0)に固有の設定のことです。これは、そのプロファイルを参照するすべてのパートナに適用される共通プロパティ・セットを表す構成グループです。ここには、認証方式マッピング、暗号化設定(SHA-1またはSHA-256)などの大部分の補助的な構成オブジェクトが含まれています。

  • パートナとは、フェデレーションSSOプロセスでパートナとなる特定の組織に対する構成のことです。各パートナは、パートナ・プロファイルと関連付けられます。パートナ・エントリのpartnerprofileidプロパティが、このパートナが割り当てられるパートナ・プロファイルを定義します。partnerprofileidプロパティが定義されていない場合、パートナ・タイプとパートナ・プロトコルに基づくデフォルトのパートナ・プロファイルが使用されます。

同じパートナ・プロファイルに関連付けられているすべてのパートナは、そのパートナ構成レベルでオーバーライドされないかぎり、定義されている設定を共有することになります。パートナ構成はパートナ・プロファイル構成をオーバーライドします。また、パートナ・プロファイルはグローバル構成をオーバーライドします。

パートナ・プロファイルは、WLSTコマンドによってのみ管理できます。新しいパートナが作成されるたびに、表31-1に示されているデフォルト・パートナ・プロファイルの1つに関連付けられます。新しいパートナ・プロファイルをパートナに割り当てるには、パートナを作成した後にsetFedPartnerProfile() WLSTコマンドを使用します。詳細は、第31.9項「WLSTを使用したIdentity Federationの管理」を参照してください。

表31-1 デフォルト・パートナ・プロファイル

デフォルト・パートナ・プロファイル 説明

saml20-idp-partner-profile

IdPパートナ用SAML 2.0パートナ・プロファイル

saml20-sp-partner-profile

SPパートナ用SAML 2.0パートナ・プロファイル

saml11-idp-partner-profile

IdPパートナ用SAML 1.1パートナ・プロファイル

saml11-sp-partner-profile

SPパートナ用SAML 1.1パートナ・プロファイル

openid20-idp-partner-profile

IdPパートナ用OpenID 2.0パートナ・プロファイル

openid20-sp-partner-profile

SPパートナ用OpenID 2.0パートナ・プロファイル

31.3 サービス・プロバイダとしてのIdentity Federationの管理

統合Identity FederationがSPとして構成されている場合、各リモートIdPについての詳細を含むプロファイルを作成およぴ管理することにより、信頼できるパートナとしてリモートIdPパートナを定義する必要があります。SPである統合Identity Federationサーバーの管理を開始するには、Oracle Access Managementコンソールの「起動パッド」からIdentity Federationの「サービス・プロバイダ管理」リンクをクリックします。この項の内容は次のとおりです。

31.3.1 リモート・アイデンティティ・プロバイダ・パートナの作成

「新規アイデンティティ・プロバイダ」ページを使用して、Access Managerのアイデンティティ・プロバイダ(IdP)パートナのレコードを定義します。サービスの詳細は、手動で指定することもメタデータ・ファイルからロードすることも可能です。

図31-1には、XMLメタデータ・ファイルがロードされてサービス詳細が構成されている「アイデンティティ・プロバイダ・パートナの作成」ページが示されています。

図31-1 サービスの詳細をメタデータからロードした場合の「新規アイデンティティ・プロバイダ」ページ

図31-1については周囲のテキストで説明しています。

図31-2には、値が手動で入力されてサービス詳細が構成されている「アイデンティティ・プロバイダ・パートナの作成」ページが示されています。

図31-2 サービスの詳細を手動で入力した場合の「新規アイデンティティ・プロバイダ」ページ

図31-2については周囲のテキストで説明しています。

表31-2は、「新規アイデンティティ・プロバイダ」ページの各要素について説明しています。

表31-2 アイデンティティ・プロバイダ・パートナの設定

要素 説明

名前

プロバイダ名です。

説明

プロバイダの簡単な説明です。(オプション)。

プロトコル

プロバイダ・プロトコルです(SAML 1.1、SAML 2.0など)。

サービスの詳細

このドロップダウンを使用して、サービスの詳細を手動で入力するか、メタデータからロードするかを選択します。

メタデータ・ファイル

このフィールドは、ファイルからメタデータをロードする場合に表示されます。「参照」をクリックして、使用するファイルを選択します。SAML 2.0にのみ適用されます。

発行者ID

プロバイダの発行者IDです。SAML 2.0とSAML 1.1にのみ適用されます。

簡潔ID

プロバイダの簡潔IDです。この要素は、アーティファクト・プロファイルを使用する場合は必須です。SAML 2.0とSAML 1.1にのみ適用されます。

SSOサービスURL

SSOリクエストが送信されるURLアドレスです。

SOAPサービスURL

SOAPサービス・リクエストが送信されるURLアドレスです。この要素は、アーティファクト・プロファイルを使用する場合は必須です。

ログアウト・リクエスト・サービスURL

プロバイダからログアウト・リクエストが送信されるURLアドレスです。この要素はログアウト機能を使用する場合は必須です。SAML 2.0にのみ適用されます。

ログアウト・レスポンス・サービスURL

ログアウト・レスポンスが送信されるURLアドレスです。この要素はログアウト機能を使用する場合は必須です。SAML 2.0にのみ適用されます。

署名証明書

プロバイダが使用する署名証明書です。pemおよびderフォーマットで指定できます。SAML 2.0とSAML 1.1にのみ適用されます。

ユーザー・アイデンティティ・ストア

IdPのユーザーが配置およびマップされるアイデンティティ・ストアです。Identity Federationは、パートナ単位で定義された複数のアイデンティティ・ストアをサポートします。また、ユーザー・アイデンティティ・ストアが選択されていない場合は、デフォルトのAccess Managerストアが使用されます。

ユーザー検索ベースDN

ユーザー・レコードの参照時に使用される基本検索DNです。(オプション。)省略した場合は、選択したユーザー・アイデンティティ・ストア用に構成されているデフォルトのユーザー検索ベースDNが使用されます。)

マッピング・オプション

この設定では、アイデンティティ・ストア内のユーザーに着信アサーションをマップする方法を指定します。次のいずれかのオプションを選択します。

  • ユーザーIDストア属性にアサーション名IDをマップ

    アサーションのNameIDのマップ先となるアイデンティティ・ストア属性を入力します。

  • ユーザーIDストア属性にアサーション属性をマップ

    アサーション属性とそのマップ先となるアイデンティティ・ストア属性を入力します。

  • LDAP問合せを使用してユーザー・レコードにアサーションをマップ

    着信データのプレースホルダを含むLDAP問合せを入力します。次を使用できます。

    - SAMLアサーションのAttributeStatement要素の属性。属性名の先頭と末尾に%文字を付けて参照します。

    - SAMLアサーションのサブジェクトのNameID。%fed.nameidvalue%で参照します。

    - アイデンティティ・プロバイダのパートナ名。%fed.partner%で参照します。

    たとえば、2つのアサーション属性(lastnameとemail)に基づいて着信アサーションをマップするLDAP問合せは、(&(sn=%lastname%)(mail=%email%))のようになります。

HTTP Basic認証の有効化

HTTP基本資格証明を受け入れる場合はこのボックスを選択します。(拡張要素。プロバイダの「Edit」モードのみで使用できます。)

属性マッピング・プロファイル

パートナが関連付けられる属性プロファイルを示します。

サービスの詳細

次のオプションのうち、Identity Federation (RP)がフェデレーションSSOをIdPとともに実行する際に使用するオプションを示します。OpenID 2.0にのみ適用されます。

  • 検出サービスURLで使用可能なIdP XRDSメタデータ経由でIdP SSO URを検出する。

  • IDP SSOサービスURLである指定の静的なOpenIDログイン・エンドポイントを使用する。

検出URL

IdPがXRDSメタデータを発行する場所を定義します。OpenID 2.0にのみ適用されます。

エンドポイントURL

IdP SSOサービス・ロケーションを定義します。OpenID 2.0にのみ適用されます。

グローバル・ログアウトの有効化

ログアウト・フロー中、ユーザーのサインオフをIdentity Federationがリモート・パートナに通知するかどうかを示します。SAML 2.0にのみ適用されます。

HTTP POST SSOレスポンス・バインディング

IdPからSAMLアサーションを戻すのにHTTP POSTバインディングを使用するのか、アーティファクト・バインディングを使用するのかを示します。SAML 2.0にのみ適用されます。

認証リクエスト名前IDフォーマット

Identity FederationがフェデレーションSSO操作中にIdPに要求する名前IDフォーマットを示します。選択しない場合、リクエストに名前IDフォーマットは指定されません。SAML 2.0にのみ適用されます。




注意:

IdP機能には、11gリリース1 (11.1.1)のOracle Identity Federationサーバーを使用してください。詳細は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』を参照してください。

フェデレーションで使用するSAML 2.0アイデンティティ・プロバイダを定義する手順

次の手順に従って、新しいSAML 2.0アイデンティティ・プロバイダ(IdP)を定義します。

  1. Oracle Access Managementコンソールで、「サービス・プロバイダ管理」をクリックします。

  2. 「IDプロバイダの作成」ボタンをクリックして、「新規アイデンティティ・プロバイダ」ページを表示します。

  3. 通常、SAML 2.0はメタデータで構成します。「サービスの詳細」ドロップダウンで、「プロバイダ・メタデータからロード」を選択します。

  4. 「メタデータ・ファイル」という新しいフィールドが表示されます。「参照」をクリックします。

  5. 対象のメタデータ・ファイルを選択します。

  6. ファイルからメタデータがロードされます。

  7. 「保存」をクリックすると、アイデンティティ・プロバイダの定義が作成されます。

フェデレーションで使用するSAML 1.1アイデンティティ・プロバイダを定義する手順

次の手順を実行して、新しいSAML 1.1アイデンティティ・プロバイダ(IdP)を作成します。

  1. Oracle Access Managementコンソールで、「サービス・プロバイダ管理」をクリックします。

  2. 「IDプロバイダの作成」ボタンをクリックして、「新規アイデンティティ・プロバイダ」ページを表示します。

  3. 使用環境に適した値(表31-2)を、「新規アイデンティティ・プロバイダ」ページに入力します。指定する情報は、プロバイダなどの要素で選択したプロトコルに応じて異なります。

  4. 「保存」をクリックすると、アイデンティティ・プロバイダの定義が作成されます。


    注意:

    一部のSAML 1.1構成パラメータはOracle Access Managementコンソールから設定できません。このようなパラメータの値はupdatePartnerProperty WLSTコマンドを使用して変更できます。詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

フェデレーションで使用するOpenID 2.0アイデンティティ・プロバイダを定義するには:

11g リリース2 (11.1.2.2)では、Identity FederationはOpenIDをサポートし、OpenID RP/SPとして機能します。OpenIDプロバイダは、IdPパートナとして登録できます。これらのOpenIDパートナを使用して作成された認証スキームは、OpenIDアイデンティティ・プロバイダが提供する認証サービスを使用してAccess Managerリソースを保護します。次の手順を実行して、新しいOpenID 2.0アイデンティティ・プロバイダ(IdP)を作成します。

  1. Oracle Access Managementコンソールにログインします。

  2. 「起動パッド」から、Identity Federationの「サービス・プロバイダ管理」をクリックします。

  3. 「アイデンティティ・プロバイダ・パートナの作成」ボタンをクリックします。

    「アイデンティティ・プロバイダ・パートナの作成」ページが表示されます。

  4. 手動、またはメタデータ・ファイルのアップロードにより、現在の環境に適した値を入力します。

    指定する情報は、プロバイダなどの要素で選択したプロトコルに応じて異なります。

  5. 「保存」をクリックして、アイデンティティ・プロバイダの定義を作成します。

Google IdPパートナ

GoogleをOpenID 2.0 IdPとして追加するには、次の手順を実行します。

  1. Oracle Access Managementコンソールにログインします。

  2. 「起動パッド」から、Identity Federationの「サービス・プロバイダ管理」をクリックします。

  3. 「アイデンティティ・プロバイダ・パートナの作成」ボタンをクリックします。

    「アイデンティティ・プロバイダ・パートナの作成」ページが表示されます。

  4. 「プロトコル」ドロップダウン・リストから「OpenID 2.0」を選択します。

  5. 「サービスの詳細」ドロップダウン・リストからGoogleプロバイダのデフォルト設定を選択します。

  6. 「保存」をクリックして、アイデンティティ・プロバイダの定義を作成します。

このパートナは、SPが表31-3に一覧されたアサーション属性をGoogle IdPに要求できるように構成され、これらの属性を、対応するセッション属性名にマッピングします。

表31-3 Google OpenIDパートナの属性

アサーション属性名 セッション属性名

http://axschema.org/contact/country/home

country

http://axschema.org/contact/email

email

http://axschema.org/namePerson/first

firstname

http://axschema.org/pref/language

language

http://axschema.org/namePerson/last

lastname

Googleパートナはユーザー・マッピング属性としてmailを使用するため、着信のhttp://axschema.org/contact/email属性は、ユーザー・アイデンティティ・ストアに含まれるユーザーのmail属性と一致するようになります。

Yahoo IdPパートナ

YahooをOpenID 2.0 IdPとして追加するには、次の手順を実行します。

  1. Oracle Access Managementコンソールにログインします。

  2. 「起動パッド」から、Identity Federationの「サービス・プロバイダ管理」をクリックします。

  3. 「アイデンティティ・プロバイダ・パートナの作成」ボタンをクリックします。

    「アイデンティティ・プロバイダ・パートナの作成」ページが表示されます。

  4. 「プロトコル」ドロップダウン・リストから「OpenID 2.0」を選択します。

  5. 「サービスの詳細」ドロップダウン・リストからYahooプロバイダのデフォルト設定を選択します。

  6. 「保存」をクリックして、アイデンティティ・プロバイダの定義を作成します。

このパートナは、SPがYahoo IdPから表31-4に一覧されたアサーション属性を要求できるように構成され、それらの属性を対応するセッション属性名にマップします。

表31-4 Yahoo OpenIDパートナの属性

アサーション属性名 セッション属性名

http://axschema.org/contact/country/home

country

http://axschema.org/contact/email

email

http://axschema.org/namePerson/first

firstname

http://axschema.org/pref/language

language

http://axschema.org/namePerson/last

lastname

Yahooパートナはユーザー・マッピング属性としてmailを使用するため、着信のhttp://axschema.org/contact/email属性は、ユーザー・アイデンティティ・ストアに含まれるユーザーのmail属性と一致するようになります。

OpenID簡易登録を有効化するには

デフォルトでは、Identity FederationはAttribute Exchange Extensionを使用して、OpenID IdPからユーザー・アイデンティティ属性を取得します。ただし、古いSimple Registration (SREG)拡張機能を使用する必要がある場合は、次のWLSTコマンドを実行することで、有効化できます。

putBooleanProperty("/spglobal/openid20axenabled", "false")
putBooleanProperty("/spglobal/openid20sregenabled", "true")

OpenID Simple Registrationを無効化するには

Simple Registration (SREG)拡張機能からAttribute Exchange Extensionに切り替えてOpenID IdPからユーザー・アイデンティティ属性を取得するには:

putBooleanProperty("/spglobal/openid20axenabled", "true")
putBooleanProperty("/spglobal/openid20sregenabled", "false")

31.3.2 リモート・アイデンティティ・プロバイダ・パートナの管理

Identity Federation用の既存のIdPを管理するには、次の手順を使用します。

既存のアイデンティティ・プロバイダを検索する手順

次の手順に従います。

  1. Oracle Access Managementコンソールで、「サービス・プロバイダ管理」をクリックします。

  2. ページの「検索」に、アイデンティティ・プロバイダの検索基準を入力します。"*"(アスタリスク)文字と"."(ピリオド)文字は、検索のワイルドカードとしてサポートされています。検索パラメータの詳細は、表31-5を参照してください。

  3. 「検索」をクリックします。

  4. 検索結果は、表に表示されます。

表31-5 IdPのプロバイダ検索で使用される要素

要素 説明

パートナ名

特定のパートナ名を検索します。

プロバイダID

プロバイダIDで検索します。

ステータス

ステータスに一致するプロバイダを検索します。

説明

プロバイダの説明で検索します。

プロトコル

指定したプロバイダを使用するプロバイダを検索します。

表31-5に、IdP検索の検索結果の例を示します。

図31-3 アイデンティティ・プロバイダの検索

図31-3については周囲のテキストで説明しています。

フェデレーションで使用するアイデンティティ・プロバイダを更新する手順

  1. Oracle Access Managementコンソールで、「サービス・プロバイダ管理」をクリックします。

  2. 更新対象のプロバイダを検索します。詳細は、「既存のアイデンティティ・プロバイダを検索する手順」を参照してください。

  3. 検索結果の表から対象のプロバイダを選択します。

  4. 鉛筆アイコンをクリックして、プロバイダの更新ページを表示します。このページは、「サービス情報」、「署名証明書」、「ユーザー・マッピング」および「詳細設定」のセクションに分かれています。

  5. プロバイダの情報を更新します。詳細は、表31-2を参照。

    HTTP Basic認証を有効にした後、SOAP URLを保護するように構成する方法は、『Oracle Fusion Middleware Oracle Identity Federation管理者ガイド』を参照してください。

  6. 「保存」をクリックすると、アイデンティティ・プロバイダの定義が更新されます。

図31-4に、IdP定義の更新の例を示します。

図31-4 アイデンティティ・プロバイダの更新

図31-4については周囲のテキストで説明しています。

31.4 アイデンティティ・プロバイダとしてのIdentity Federationの管理

統合Identity FederationがIdPとして構成されている場合、各リモートSPについての詳細を含むプロファイルを作成およぴ管理することにより、信頼できるパートナとしてリモートSPパートナを定義する必要があります。この項の内容は次のとおりです。

31.4.1 リモート・サービス・プロバイダ・パートナの作成

「サービス・プロバイダ・パートナ」ページを使用して、Identity FederationがIdPとして構成された場合のパートナ・プロファイルを定義します。サービスの詳細は、手動で指定することもメタデータ・ファイルからロードすることも可能です。

  1. Oracle Access Managementコンソールに管理者としてログインします。

    起動パッドが表示されます。

  2. Identity Federationの「アイデンティティ・プロバイダ管理」をクリックします。

    「アイデンティティ・プロバイダ管理」ページが表示されます。

  3. 「サービス・プロバイダ・パートナの作成」ボタンをクリックします。

    「サービス・プロバイダ・パートナの作成」ページが表示されます。

  4. パラメータの値を入力します。

    表31-6では、「新規サービス・プロバイダ」ページの各要素について説明します。

    表31-6 サービス・プロバイダ・パートナの設定

    要素 説明

    名前

    プロバイダ名です。

    パートナの有効化

    このパートナをフェデレーションに参加させるかどうかを選択します。

    説明

    プロバイダの簡単な説明です。(オプション)。

    プロトコル

    これはプロバイダのプロトコルです(SAML 1.1、SAML 2.0またはOpenID 2.0)。

    サービスの詳細

    サービスの詳細を手動で入力するか、メタデータからロードするかを選択します。後者の場合、メタデータ・ファイルを参照します。SAML 2.0にのみ適用されます。

    メタデータ・ファイル

    このフィールドは、ファイルからメタデータをロードする場合に表示されます。「参照」をクリックして、使用するファイルを選択します。SAML 2.0にのみ適用されます。

    プロバイダID

    リモート・サービス・プロバイダのプロバイダIDまたは発行者ID。SAML 2.0とSAML 1.1にのみ適用されます。

    アサーション・コンシューマのURL

    アサーション・レスポンスの送信先URL。SAML 2.0とSAML 1.1にのみ適用されます。

    署名証明書のロード

    このSPが使用する署名証明書をアップロードします。「手動で入力」が選択されている場合のみ表示されます。SAML 2.0とSAML 1.1にのみ適用されます。

    ログアウト・リクエストURL

    ログアウト・リクエストの送信先URL。SAML 2.0にのみ適用されます。

    ログアウト・レスポンスURL

    ログアウト・リクエストへのレスポンスが送信される先のURL。SAML 2.0にのみ適用されます。

    暗号化証明書のロード

    このSPが使用する暗号化証明書をアップロードします。「手動で入力」が選択されている場合のみ表示されます。SAML 2.0にのみ適用されます。

    名前IDフォーマット

    このSPに対して使用する必要がある名前IDフォーマットを示します。SAML 2.0とSAML 1.1にのみ適用されます。名前IDフォーマットの詳細は、それぞれ30.4.1項「SAML 2.0の使用」または30.4.2項「SAML 1.1の使用」を参照してください。

    NameID値

    名前ID値の入力方法を示します。SAML 2.0とSAML 1.1にのみ適用されます。

    • 「ユーザーIDストア属性」が選択されている場合、使用するユーザー属性を指定します。

    • 「式」を指定した場合、使用する式を入力します。

    属性マッピング・プロファイル

    パートナがバインドされる属性マッピング・プロファイルを示します。SAML 2.0とSAML 1.1にのみ適用されます。

    ユーザー・アイデンティティ・ストア

    IdPのユーザーが配置およびマップされるアイデンティティ・ストアです。Identity Federationは、パートナ単位で定義された複数のアイデンティティ・ストアをサポートします。ユーザー・アイデンティティ・ストアが選択されていない場合は、Access Managerに定義されたデフォルト・ストアが使用されます。(これは、OIFがSAML属性共有プロトコルの属性認証局である場合にのみ、該当します。SSOの間は使用されません。)

    ユーザー検索ベースDN

    ユーザー・レコードの参照時に使用される基本検索DNです。(オプション。省略した場合は、選択したユーザー・アイデンティティ・ストア用に構成されているデフォルトのユーザー検索ベースDNが使用されます。)

    グローバル・ログアウトの有効化

    ログアウト・フロー中、ユーザーのサインオフをOIFがリモート・パートナに通知するかどうかを示します。SAML 2.0にのみ適用されます。

    SSOレスポンス・バインディング

    IdPからSAMLアサーションを戻すのにHTTP POSTバインディングを使用するのか、アーティファクト・バインディングを使用するのかを示します。SAML 2.0とSAML 1.1に対してのみ適用されます。

    アサーションの暗号化

    このパートナに対してアサーションを暗号化するかどうかを示します。SAML 2.0にのみ適用されます。

    レルム

    OpenID SPを識別するURL。OpenID 2.0にのみ適用されます。

    エンドポイントURL

    IdPがユーザーをOpenIDアサーション付きでリダイレクトするURL。OpenID 2.0にのみ適用されます。

  5. 「保存」をクリックして、リモートSPパートナ・プロファイルを作成します。

31.4.2 リモート・サービス・プロバイダ・パートナの管理

リモートSPパートナのプロファイルを編集および管理するには、プロファイルを検索して、属性値を変更します。

既存のサービス・プロバイダ・パートナ・プロファイルを検索する手順は、次のとおりです。

  1. Oracle Access Managementコンソールの起動パッドで、Identity Federationの「アイデンティティ・プロバイダ管理」をクリックします。

    「アイデンティティ・プロバイダ管理」ページが表示されます。

  2. ページの「検索」に、アイデンティティ・プロバイダの検索基準を入力します。"*"(アスタリスク)文字と"."(ピリオド)文字は、検索のワイルドカードとしてサポートされています。検索パラメータの詳細は、表31-5を参照してください。

  3. 「サービス・プロバイダ・パートナの検索」タブを起動します。

  4. 検索基準を入力し、「検索」をクリックします。

    検索結果が表示されます。

  5. 「検索結果」表から適切なパートナを選択して、「アクション」から「編集」を選択します(または、鉛筆のアイコンをクリックします)。

    新しいタブが開いて、そのパートナの属性が表示されます。表31-6に示されている属性に加えて、次の拡張属性も変更できます。

    • グローバル・ログアウトの有効化

    • アサーションの暗号化

    • 「SSOレスポンス・バインディング」(HTTP POSTまたはアーティファクト)

  6. 「保存」をクリックして、変更を保持します。


注意:

SAML 1.1を使用する場合には、署名に証明書を含めることができます。詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

31.5 属性マッピング・プロファイルの使用

Identity Federation (SPとして構成した場合)は、フェデレーション・プロセス中、IdPに対して属性を要求できます。このためには、着信アサーションの属性の名前を、Access Managerセッションで使用できるローカル属性(たとえば$session.attr.fed.attr.ATTR_NAME)にマッピングします。IdP属性マッピング・プロファイルにはこのようなマッピングが含まれます。

同様に、Identity Federation (IdPとして構成した場合)は、属性をSSOアサーション内に含めることや、SPパートナが属性をSSOアサーション内とするように要求することをサポートしています。Identity FederationをIdPとして構成する際、SP属性マッピング・プロファイルを設定して、SSOアサーション内の属性名、属性値入力に使用される式、SSOアサーションで属性を常に送信するかどうかを定義できます。


注意:

プロバイダによって使用されるプロトコルが、たとえばOpenID 2.0など、この機能をサポートしている必要があります。

各パートナ・タイプ(IdPまたはSP)は、適切なマッピングを定義する属性マッピング・プロファイルを参照します。これは、そのパートナで使用される属性を、Identity Federationサーバーで定義されている属性にマッピングする方法を示します。パートナに対して属性マッピング・プロファイルが定義されていない場合、デフォルトの属性マッピング・プロファイルが(パートナ・タイプに基づいて)使用されます。各プロバイダ・タイプに対してデフォルトの属性マッピング・プロファイルがあります。

  • SP属性マッピング・プロファイル: 各SPパートナ・プロファイルはSP属性マッピング・プロファイルを参照します。プロファイルが構成されていない場合、デフォルトのSP属性マッピング・プロファイルが使用されます。詳細は、第31.5.1項「SP属性マッピング・プロファイルの使用」を参照してください。

  • IdP属性マッピング・プロファイル: 各IdPパートナ・プロファイルはIdP属性マッピング・プロファイルを参照します。プロファイルが構成されていない場合、デフォルトのIdP属性マッピング・プロファイルが使用されます。詳細は、第31.5.2項「IdP属性マッピング・プロファイルの使用」を参照してください。

31.5.1 SP属性マッピング・プロファイルの使用

Identity FederationインスタンスがIdPとして構成されている場合、SP属性マッピング・プロファイルにより、管理者は、どのメッセージ属性(着信Identity Federationメッセージまたは送信Identity Federationメッセージに含められている属性)をどのAccess Managerセッション属性にマップするか定義できます。式は、Access Manager属性をアサーションまたは送信メッセージに含めるときに、その値を検出するのに使用されます。表31-7は、サンプルSP属性マッピングの一部です。

表31-7 サンプルSP属性マッピング

メッセージ属性 Access Managerセッション属性 常に送信

mail

$user.attr.mail

firstname

$user.attr.givenname

true

lastname

$user.attr.sn

true

authn-level

$session.authn_level

true

「常に送信」は、その属性が要求されていない場合でも送信するかどうかを示します。属性が要求されているかどうかにかかわらず送信アサーションに含める必要がある場合、「常に送信」を「true」に設定します。「常に送信」が「false」の場合、この属性は要求されていてもアサーションに含まれません。SPが要求を送信すると、メッセージ属性が検索され、式が評価されて、このメッセージ属性に対するマッピング値が算出されます。


注意:

値式には、第20.9項「SSOのポリシー・レスポンスの概要」に説明されているように、OAMポリシー式言語が使用されます。複数のメッセージ属性に同じ値式を使用することもできます。

SPパートナ・プロファイルを作成または変更する際(第31.4.1項「リモート・サービス・プロバイダ・パートナの作成」を参照)、使用可能な属性マッピング・プロファイルがドロップダウン・リストに表示されます。sp-attribute-profileがデフォルト・プロファイルです。デフォルト・プロファイルを選択するか、緑のプラス記号をクリックして、カスタム・マッピング・プロファイルを作成します。SPパートナに対して新しい属性マッピングを作成する際、属性に対する値文字列内に表31-8に示されている式を埋め込むことができます。これらの式は、実行時に値に置換されます。

表31-8 属性マッピングの値式

値の型 許容値 式

request

httpheader.HTTP_HEADER_NAME

HTTP_HEADER_NAMEは、$request.httpheader.HTTP_HEADER_NAMEとして格納されているHTTPヘッダーの名前です

cookie.COOKIE_NAME

COOKIE_NAMEは、$request.cookie.COOKIE_NAMEとして格納されているCookieの名前です

client_ip

$request.client_ipとして格納

session

authn_level

$session.authn_levelとして格納

authn_scheme

$session.authn_schemeとして格納

count

$session.countとして格納

creation

$session.creationとして格納

expiration

$session.expirationとして格納

attr.ATTR_NAME

ATTR_NAMEは、$session.attr.ATTR_NAMEとして格納されているAccess Managerセッション属性の名前です。

user

userid

$user.useridとして格納

id_domain

$user.id_domainとして格納

guid

$user.guidとして格納

groups

$user.groupsとして格納

attr.ATTR_NAME

ATTR_NAMEは、$user.attr.ATTR_NAMEとして格納されているLDAPユーザー属性の名前です。

expression

(前述のように定義され、データ型により修飾されている識別子に基づく)

- request:

  • $request.httpheader.HTTP_HEADER_NAME

  • $request.cookie.COOKIE_NAME

  • $request.client_ip

-

  • HTTP_HEADER_NAMEはHTTPヘッダーの名前です

  • COOKIE_NAMEはCookieの名前です

- session:

  • $session.authn_level

  • $session.authn_scheme

  • $session.count

  • $session.creation

  • $session.expiration

  • $session.attr.ATTR_NAME

-

  • ATTR_NAMEは、Access Managerセッション属性の名前です

- userから:

  • $user.userid

  • $user.id_domain

  • $user.guid

  • $user.groups

  • $user.attr.ATTR_NAME

  • ドット(.)文字と空白を含む任意の文字列にできます(「$user.userid」、「$user.attr.givenname $user.attr.sn」または「これはセッション数: $session.countです」など)

-

  • ATTR_NAMEは、LDAPユーザー属性の名前です

31.5.2 IdP属性マッピング・プロファイルの使用

Identity FederationインスタンスがSPとして構成されている場合、IdP属性マッピング・プロファイルにより、管理者は、どの属性(着信Identity Federationメッセージまたは送信Identity Federationメッセージに含まれている属性)をどのAccess Managerセッション属性にマップするか定義できます。プロファイルは、次のデータを含めることを許可します。

  • メッセージ属性: 着信または送信フェデレーション・メッセージ内の属性の名前。

  • Access Managerセッション属性: ローカルAccess Managerサーバーが認識する属性の名前。

  • パートナからの要求: この属性をIdPへのリクエストに含めて送信するかどうかを示します(この属性値をSPから要求します)。

表31-9は、サンプルIdP属性マッピングを示しています。

表31-9 サンプルIdP属性マッピング

メッセージ属性 Access Managerセッション属性 挿入要求

mail

email

true

givenname

true

sn

surname

uid

uid

SPが、IdPからのレスポンスに要求する属性を指定できるプロトコルの場合、メッセージ属性名はIdPへのリクエストで送信されます。SPがアサーションつまりIdPからのレスポンスを受信すると、アサーションからの属性は、Access Managerセッションに格納されます。Access Manager値が指定されていない場合、メッセージ属性が格納されます。

IdPパートナ・プロファイルを作成または変更する際(第31.3.1項「リモート・アイデンティティ・プロバイダ・パートナの作成」を参照)、属性マッピング・プロファイルがドロップダウン・リストに表示されます。idp-attribute-profileがデフォルト・プロファイルです。デフォルト・プロファイルを選択するか、緑のプラス記号をクリックして、カスタム・マッピング・プロファイルを作成します。

「アンマップ属性の無視」チェック・ボックス(構成画面内)は、存在していない(または、存在していてもAccess Managerの「セッション属性」列に値がない)アサーション属性の処理方法を示します。このチェック・ボックスを選択しない場合、表に含まれてない(またはAccess Managerに値がマッピングされていない)すべてのアサーション属性は、アサーション内にある同じ属性名で、Access Managerセッションに格納されます。このチェック・ボックスが選択されている場合、表にない(または値がAccess Managerにマッピングされていない)アサーション属性は無視され、Access Manager画面に追加されません。


注意:

Identity FederationインスタンスがSPとして構成された場合、使用するフェデレーション・プロトコルがサポートしている場合にかぎり、属性をリクエストできます。OpenID 2.0はこの機能をサポートしていますが、SAML 2.0とSAML 1.1はサポートしていません。

31.6 フェデレーション認証方式からAccess Manager認証スキームへのマッピング

フェデレーション認証方式(FAM)は、フェデレーション・メッセージ内で認証メカニズムを表す識別子です。この識別子は、既知の識別子(SAML仕様で定義されているurn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransportやurn:oasis:names:tc:SAML:1.0:am:passwordなど)でも、2つの通信パートナ間で同意されている任意の識別子でも構いません。

IdPとして構成されているIdentity Federationは、ユーザーが認証された方法を示す情報が含まれるアサーション(SAMLまたはOpenID)を生成します。アサーション生成プロセス中、IdPは、ユーザーが認証された認証スキームを取得し、これをFAMにマッピングしようとします。このようなマッピングが存在していれば、IdPはFAMを送信アサーションに含めます。マッピングが存在していない場合、IdPは、FAMとして定義されている認証スキームをアサーションに含めます。


注意:

セッション属性は、マッピングが定義されていない場合にプロキシ・モードで使用できます。IdPとして機能するIdentity Federationは、両方のプロトコルが同じ場合、アサーションを作成するときにFAM値に対してセッション属性を使用します。

表31-10は、FAMとAccess Manager認証スキーム間のデフォルトの設定不要なマッピングを示しています。

表31-10 フェデレーション認証方式からAccess Manager認証スキームへのデフォルト・マッピング

プロトコル マッピング

saml20-sp-partner-profile

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransportから:

  • LDAPScheme (SPパートナがurn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransportを要求したときに使用されるスキーム)

  • FAAuthScheme

  • BasicScheme

  • BasicFAScheme

saml11-sp-partner-profile

urn:oasis:names:tc:SAML:1.0:am:passwordから:

  • LDAPScheme (SPパートナがurn:oasis:names:tc:SAML:1.0:am:passwordを要求したときに使用されるスキーム)

  • FAAuthScheme

  • BasicScheme

  • BasicFAScheme

詳細は、次の項を参照してください。

31.6.1 IdPとしてのフェデレーションSSOについての理解

IdPとして機能するIdentity Federationは、SPパートナから送信される着信認証リクエスト・メッセージを処理します。これらのメッセージは、ユーザーがAccess Manager (IdP)からチャレンジを受ける必要があるFAMを指定します。認証リクエストにFAMが含まれていれば、IdPはこれをAccess Managerの認証スキームにマッピングしようとします。このようにマッピングが定義されている場合、Access Managerは、ユーザーがチャレンジを必要とする場合のみ、このスキームを使用してユーザーを認証します。たとえば、セッションがタイムアウトしたり、セッションが存在していなかったり、現在のセッションの認証レベルが、マッピングされている認証スキームのレベルより低かったり、ユーザーがAccess Managerによってまだ認証されていない場合に、そのユーザーはチャレンジを受けることが必要になります。マッピングが定義されていない場合、IdPはSPにエラーを返し、FAMが不明であることを示します。

IdP認証モジュールにはユーザーにチャレンジを渡すAccess Managerが含まれているので、次のいずれかの方法で、使用できる認証スキームが判断されます。

  • SPが、フェデレーション認証リクエストによりユーザーを認証する特別な方法を要求します。

  • IdP構成内のSP設定により、デフォルト・スキームを定義します。パートナ構成が最初にチェックされ、次に、パートナ・プロファイル構成、そして最後に、IdP構成で定義されているグローバル・デフォルト認証スキーム(LDAPScheme)がチェックされます。


注意:

デフォルトでは、パートナ構成とパートナ・プロファイル構成は、デフォルトの認証スキームを定義しません。つまり、グローバル・デフォルト認証スキームLDAPSchemeが有効になります。

認証後、IdPはアサーションを作成し、Access Manager認証スキーム(と適切なレベル)をFAMにマッピングします(マッピングが存在する場合)。FAMは、認証コンテキストとして設定されます。マッピングが存在しない場合、Identity FederationはデフォルトのAccess Manager認証スキームを認証コンテキストとして送信します。このプロセスの後、ユーザーはIdentity Federationにリダイレクトされます。

31.6.2 SPとしてのフェデレーションSSOについての理解

フェデレーションSSOプロセスでSPとして機能するIdentity Federationは、IdPパートナによって生成される着信アサーションを処理します。このプロセスにより、そのユーザーに対するAccess Managerセッションが生成され、アサーションに含まれているFAMがデフォルトSchemeID/Access Manager認証スキームにマッピングされます。Identity Federationは、Access Managerがユーザー・セッションを生成する際に使用する認証レベル(設定されている場合)を提供します。(デフォルトでは、Access Managerセッションの認証レベルは、定義されているFederationSchemeの認証レベルに設定されます。)FAMは、セッション属性として保存されます。

管理者が定義するマッピングにより、SPは、アサーションに含まれるFAMに対してマッピングされている認証レベルで、Access Managerセッションを生成します。これは、ユーザーがIdPによって元々認証されていたメカニズムの強度を反映する方法を提供します。

31.6.3 代替認証スキームの構成

フェデレーションSSO中、ユーザーがAccess Managerで認証されていなかったり、Access Managerセッションが長い間非アクティブ状態だったり、タイムアウトしていたり、サービス・プロバイダからユーザーの再チャレンジが要求された場合、IdPは、Access Manager認証モジュールを起動して、ユーザーに対するチャレンジを渡します。特定のクライアントに対して、IdPは、別の認証スキームを使って、デフォルト以外の方法でユーザーのチャレンジを渡すこともできます。このことは、たとえば、HTTP基本認証スキームではなく、モバイル・クライアント用のスキームを使用するなど、コンピュータベースのブラウザで使用される認証スキーム以外の認証スキームでユーザーのチャレンジを渡すことが必要になる携帯電話用の認証において発生します。

IdPとして機能するIdentity Federationの構成により、ユーザーのブラウザから送信されるHTTPヘッダーを確認することにより、構成済認証スキーム以外の代替認証スキームを使用するかどうかを評価できます。Identity Federationは、次の構成可能な設定に基づいて評価を行います。

  • ユーザーのブラウザから送信されるHTTPヘッダー属性を示す設定。

  • 前述のHTTPヘッダー属性の値を評価する正規表現を含む設定。

  • 使用する代替認証スキームを含む設定。


注意:

SPが特別な認証スキームを要求した場合は、評価は適用されません。

代替認証スキームは、Oracle Access Managementコンソールではなく、WLSTコマンドによってのみ構成可能です。WLSTコマンドであるsetSPPartnerAlternateSchemeとsetSPPartnerProfileAlternateSchemeについては、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

31.6.4 WLSTを使用したマッピングの管理

認証方式、認証スキーム、認証レベルのマッピングはすべて、WLSTコマンドを使って構成されます。これは、パートナ・レベル、またはこのレベルでの定義がない場合は、パートナ・プロファイル・レベルで構成します。詳細は、第31.9項「WLSTを使用したIdentity Federationの管理」を参照してください。

31.7 属性問合せサービス用属性共有プラグインの使用

Identity Federationには、Access ManagerがIdPにユーザー属性を要求できるようにするための属性共有プラグインが用意されています。この対話において、SPは<AttributeQuery>リクエスタであり、IdPは<AttributeQuery>レスポンダになります。属性共有プラグインは、SOAPを使用して転送されるリクエスト/レスポンス・プロトコルである属性問合せサービスに依存します。


注意:

属性共有プラグインは、X.509認証ベースの属性共有プロファイル(XASP)のスーパーセットをAccess Manager認証フローに実装するのにAttributeQueryリクエスタ・サービスを利用します。

SPとして構成されているIdentity Federationは、SOAPコールへのレスポンスでSAML 2.0 <AttributeQuery>をIdPに送信できます。プラグインは、認証スキームの1ステップとして構成できます。別のプラグインによる認証後に起動して、認証済ユーザーの属性をフェッチし、これをAccess Managerセッションに設定できます。次の各項では、さらに詳細を説明します。

31.7.1 プラグインと問合せサービスの設計についての理解

Identity Federationは、リモートIdPにユーザー属性を要求するには、SPとして構成されている必要があります。属性共有プラグインは大まかに見ると、図31-5のようになります。

図31-5 属性共有プラグインの設計

図31-5の説明が続きます
「図31-5 属性共有プラグインの設計」の説明

属性共有プラグインは、Access Managerカスタム認証モジュールに含めることができ、ユーザー認証後に起動できます。属性共有プラグインは、Identity Federation Java APIを起動し、ユーザー属性をAccess Managerセッションに設定し、Java引数を、SPによって処理できる属性リクエストに変換することにより、ユーザー属性をフェッチします。Identity Federation SPは、属性リクエストを受信し(公開SOAPエンドポイントで)、要求されている属性を判断し、SOAP/HTTP/SSLチャネルで要求されている属性名を使用して、オプションで署名および暗号化されたSAML 2.0 <AttributeQuery>をIdPの属性レスポンダ・サービスに送信します。


注意:

属性共有プラグインを起動する際、このフレームワークから、<AttributeQuery>に含める次の情報が提供されます。

  • 認証済ユーザーのユーザーIDまたはSubjectDN (使用可能な場合)

  • パートナIDのユーザー・セッション属性(フェデレーション認証プラグインがユーザーの認証に使用された場合のみ使用可能)

  • テナント名

  • IdP名(プラグインがIdP固有に作成された場合)

リモートIdPの属性レスポンダ・サービスが<AttributeQuery>を受信し、これを復号化し(必要に応じて署名を確認し)、SPが属性を要求できるかどうかをローカル・ポリシーから判断します。問題ない場合、ユーザー・リポジトリから属性を取得し、<Assertion>を(属性値を含む<AttributeStatement>とともに)構築し、オプションで署名と暗号化を行い、<Response>をアサーションとともにSPに戻します。SPは、<Response>を受け取ると、アサーションを復号化して、必要に応じて署名を確認し、アサーションから属性を抽出し、この情報をAccess Managerセッションに設定します。後続の項で詳細を示します。

31.7.1.1 SP属性リクエスタの使用

属性リクエスタ・サービスは、SOAP属性リクエストを処理し、SOAP属性レスポンスを返します。(詳細は、第31.7.1.3項「SOAPエンドポイントの使用」を参照してください。)属性リクエストには、SubjectDNと、その他の要求された属性とその値のリストが含まれます。属性リクエスタ・サービスは、リクエストから次のいずれかを(リストの順で検索)抽出することにより、属性をフェッチするIdPを識別します。

  1. パートナ/IdP名(フェデレーション・エンジンからリクエストが発行されている場合)。

  2. 認証で使用されるプラグインで構成されているIdP。

  3. リクエストのサブジェクトDN(構成済SubjectDN-IdPマップから問合せを取得するIdPを判断)。具体性が最も高いレベル(cn=Joe User,ou=Finance,o=Company,c=US)から最も低いレベル(c=US)にSubjectDNをマッピング。

  4. デフォルトIdP。

この検出の後、属性リクエスタ・サービスは、SOAP属性レスポンダ・サービスのエンドポイントURLをIdPのメタデータから取得し、属性マッピング・プロファイル経由でリクエスト内の属性を処理することにより、フェッチする属性リストを作成します。


注意:

ターゲットIdP用に指定されている属性マッピング・プロファイルを使用して、着信属性名を変更したり、このIdP用の属性マッピングでsend-with-sso (常に要求)として構成されている属性を追加します。

SAML属性問合せが、属性リストとともに生成され、IdPのSOAPエンドポイントに送信されます。レスポンスが受信されると、サブジェクトが検証され、アサーションから各属性が抽出され、値が検出され、属性と値の両方がキャッシュされます。最後に、属性レスポンスSOAPメッセージが構築され、コール元に戻されます。例31-1は、サンプルSOAP属性リクエストです。

例31-1 サンプルSOAP属性リクエスト

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Body>
      <attrreq:AttributeRequest TargetIDP="adc.example.com"
          xmlns:attrreq="http://www.example.com/fed/ar/10gR3">
      <attrreq:Subject
         Format="oracle:security:nameid:format:emailaddress">alice@example.com
      </attrreq:Subject>
         <attrreq:Attribute Name="cn">
         </attrreq:Attribute>
      </attrreq:AttributeRequest>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

例31-2は、サンプルSOAP属性レスポンスです。

例31-2 サンプルSOAP属性レスポンス

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <soap:Envelope xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"  xmlns:ns2="http://www.w3.org/2005/08/addressing"  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"  xmlns:enc="http://www.w3.org/2001/04/xmlenc#"  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"  xmlns:wst14="http://docs.oasis-open.org/ws-sx/ws-trust/200802"  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"  xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity"  xmlns:mdext="urn:oasis:names:tc:SAML:metadata:extension"  xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"  xmlns:ns11="http://docs.oasis-open.org/ws-sx/ws-trust/200512"  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"  xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"  xmlns:ns14="urn:oasis:names:tc:SAML:2.0:assertion"  xmlns:xrds="xri://$xrds" xmlns:xrd="xri://$xrd*($v*2.0)"  xmlns:tns="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"  xmlns:ns18="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"  xmlns:ns19="urn:oasis:names:tc:SAML:1.0:protocol"  xmlns:ns20="http://www.w3.org/2003/05/soap-envelope"  xmlns:wsse11="http://docs.oasis-open.org/wss/
   oasis-wss-wssecurity-secext-1.1.xsd"  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"  xmlns:query="urn:oasis:names:tc:SAML:metadata:ext:query"  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
   oasis-200401-wss-wssecurity-utility-1.0.xsd"  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/
   oasis-200401-wss-wssecurity-secext-1.0.xsd"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"  xmlns:orafed-arxs="http://www.oracle.com/fed/ar/10gR3"  xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"  xmlns:ns31="urn:oasis:names:tc:SAML:profiles:v1metadata"  xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"> 
<soap:Body><orafed-arxs:AttributeResponse CacheFor="899"> <orafed-arxs:Status>Success</orafed-arxs:Status> <orafed-arxs:Subject Format="oracle:security:nameid:format:emailaddress">
   alice@example.com</orafed-arxs:Subject> <orafed-arxs:Attribute Name="cn"> <orafed-arxs:Value>alice</orafed-arxs:Value> </orafed-arxs:Attribute> </orafed-arxs:AttributeResponse></soap:Body></soap:Envelope>

31.7.1.2 IdP属性レスポンダの使用

Identity Federation IdP属性レスポンダは、SAML属性問合せを受信し、要求された属性の値を含む属性文とともにSAMLレスポンスを送信します。IdPはまず、リクエスタをSPパートナとして識別し、次に、そのユーザーがユーザー・データ・ストアに格納されていることを、NameId値またはSubjectDN値により確認します。次に、SPパートナの属性マッピング・プロファイルを使用して、要求されている各属性の値を取得します。最後に、属性値を含む属性文とともにSAMLレスポンスを構築し、返します。(これは、OIFがSAML属性共有プロトコルの属性認証局である場合にのみ、該当します。SSOの間は使用されません。)


注意:

属性レスポンダはSPパートナの属性マッピング・プロファイルを使用して、値を取得します。属性マッピング・プロファイルにマッピングが定義されていない場合、属性には空の値が返されます。値式にセッションまたはリクエストのネームスペースにおける変数が含まれている場合も、空の文字列が返されます。属性マッピング・プロファイル内の値式を正しく評価するには、user.attrネームスペースの変数のみ使用できます。

31.7.1.3 SOAPエンドポイントの使用

SPの属性リクエスタ・サービスは、クライアント・リクエスト用のSOAPインタフェースを公開します。SOAPサービスは、SP上の次のURLで使用できます。

http://<SP-managed-server>:<SP-port>/oamfed/ar/soap

31.7.2 属性共有の構成

属性共有プラグインには、表31-11に示されているオプションの構成パラメータがあります。

表31-11 属性共有プラグインの構成パラメータ

パラメータ 説明

NameIDValueAttribute

ユーザーの名前IDを取得できるセッション属性の名前。

NameIDFormatAttribute

名前IDフォーマットとして使用する値を含む属性の名前。

AttributeAuthorityAttribute

SPが<AttributeQuery>を送信する先のIdPとして使用する値を含む属性の名前。

RequestedAttributes

このパラメータは、attr1&attr2&attr3=value1など、URL問合せ形式で要求する属性を指定するのに使用できます。この場合、attr1とattr2はフェッチされますが、attr3は値にvalue1が含まれている場合のみレスポンスに含まれます。

DefaultNameIDFormat

他のパラメータとセッション属性から決定されていない場合に使用される名前IDフォーマット。

DefaultAttributeAuthority

ユーザーの属性を要求するデフォルトIdPパートナ。

属性共有プラグインは表31-12の属性にもアクセスできます。これらの属性は、実行時Access Managerセッションに含まれている場合があります。

表31-12 属性共有プラグインがアクセスできるセッション属性

属性 説明

fed.partner

ユーザーの認証にフェデレーションが使用されている場合、この値により、使用されたIdPが判断されます。これにより同じIdPが属性共有で使用されます。

fed.nameidformat

ユーザーの認証にフェデレーションが使用されている場合、この属性値により、名前IDフォーマットが判断されます。

fed.nameidvalue

ユーザーの認証にフェデレーションが使用されている場合、この属性値により、ユーザーの名前IDが判断されます。この属性がセッションに含まれている場合、SPのアイデンティティ・ストアからのユーザーの検出にDNとして使用されます。

KEY_USERNAME_DN

この値がセッションに含まれている場合、SPのアイデンティティ・ストアからのユーザーの検出にDNとして使用されます。

パラメータについて、およびパラメータが属性共有の処理方法をどのように決定するかについて、以降の項で詳しく説明します。

31.7.2.1 名前ID

これは、SPが属性を要求するユーザーの名前識別子です。名前IDを決定するには、次の検索が順に実行されます。

属性共有プラグインが次のことを行います。

  1. NameIDValueAttributeが指定されている場合、セッションから指定の属性値を取得し、それを名前IDとして使用します。

  2. NameIDValueAttributeが指定されていない場合、名前IDとしてfed.nameidvalueの値を使用します。

  3. 前述の方法で判断できない場合、属性共有プラグインは、nullまたは空の名前IDでフェデレーション・エンジンを起動し、ユーザーID (KEY_USERNAME_DNセッション属性で指定)がSP属性リクエスタに送信されます。

属性リクエスタ(SP)は次のことを行います。

  1. 名前IDがリクエストに含まれていれば、ユーザーの名前としてこの値を使用します。

  2. 名前IDの指定がなく、ユーザーIDがある場合(認証プラグイン起動時に発生)、defaultattrrequestnameiduserattribute属性の値を取得し(このIdPのSP構成で検出)、これを名前IDとして使用します。

  3. SAML 2.0を使用している場合のみ: 名前IDが決定されていない状態でSSOがシンプル名前IDマッピングで構成されている場合、nameiduserattribute属性を使用します(このIdPのSP構成で検出)。たとえば、この属性値が$user.attr.mailである場合、この属性からユーザーの名前を抽出し、これを名前IDとして使用します。

  4. 名前IDがまだ決定されない場合、エラーがスローされます。

31.7.2.2 名前IDフォーマット

これは、ユーザーの名前IDのフォーマットです。名前IDフォーマットを決定するには、次の検索が順に実行されます。

属性共有プラグインが次のことを行います。

  1. NameIDFormatAttributeパラメータ(表31-11)が指定されている場合、指定の属性値を取得し、これを名前IDフォーマットとして使用します。

  2. fed.nameidformat属性(表31-12)の値を名前IDフォーマットとして使用します。

  3. DefaultNameIDFormat属性(表31-11)の値を名前IDフォーマットとして使用します。

  4. 名前IDフォーマットがまだ決定されない場合、属性共有プラグインがフェデレーションをnull/空の名前IDフォーマットで起動します。

属性リクエスタ(SP)は次のことを行います。

  1. リクエストで指定されている名前IDフォーマットを使用します。

  2. defaultattrrequestnameidformat属性の値(このIdPのSP構成で検出)を使用します。

  3. SAML 2.0を使用している場合のみ: 名前IDフォーマットがまだ決定されていない場合、defaultauthnrequestnameidformat属性の値(このIdPのSP構成で検出)を使用します。

  4. 名前IDフォーマットがまだ決定されない場合、エラーがスローされます。

31.7.2.3 IdP

これは、属性リクエストが送信されるIdPパートナです。IdPパートナを決定するには、次の検索が順に実行されます。

属性共有プラグインが次のことを行います。

  1. AttributeAuthorityAttribute (表31-11)が指定されている場合、その値を取得し、これをIdP名として使用します。

  2. fed.partner属性(表31-12)の値をIdP名として使用します。

  3. DefaultAttributeAuthorityパラメータ(表31-11)の値をIdP名として使用します。

  4. IdPがまだ決定されない場合、属性共有プラグインがフェデレーションをnull/空の名前IDフォーマットで起動します。

属性リクエスタ(SP)は次のことを行います。

  1. 属性共有プラグインに送信されたリクエストに含まれていたIdP名を使用します。

  2. x509を使用している場合のみ: DN-IdPマッピングを検出し、このユーザーDNのIdPを決定します。

  3. defaultattrauthority属性の値(SP構成で検出)を使用します。

  4. defaultssoidp属性の値(SP構成で検出)を使用します。

  5. IdP名がまだ決定されない場合、エラーがスローされます。

31.7.2.4 RequestedAttributes

これらは、属性認証局に対して要求された属性です。属性を決定するには、次の検索が順に実行されます。

属性共有プラグインが次のことを行います。

RequestedAttributesパラメータ(表31-11)が定義されている場合、指定の属性を使用します。何も指定されていない場合、属性は送信されません。

属性リクエスタ(SP)は次のことを行います。

  1. RequestedAttributesパラメータ(表31-11)が定義されている場合、指定の属性を使用します。

  2. 属性をIdPパートナ・プロファイル内のrequest from partner(send-with-sso)属性に追加します。

属性レスポンダ(IdP)は次のことを行います。

  1. SPからの<AttributeQuery>に特定の属性値に対するリクエストが含まれている場合、これらの属性の値を返します。

  2. 属性値が要求されていない場合、SP属性プロファイル構成内のAlways Send (send-with-sso)として指定されている属性を返します。

31.8 フェデレーション・プロキシの使用

IdPとして構成されているIdentity Federationは、リモートSPパートナからリクエストを受信できるフェデレーション・プロキシを構成できます。ユーザーをローカルで認証するかわりに、IdPは、2つ目のリモートIdP (IdP2)との2つ目のフェデレーションSSOフロー(SP2)を開始します。IdP2は、ユーザーを認証し、アサーションを作成し、ユーザーをフェデレーション・プロキシ(IdP/SP2)にリダイレクトします。プロキシがアサーションを検証し、ユーザーを識別し、2つ目のアサーションを作成し、ユーザーを元のSPにリダイレクトすることにより、最初のフェデレーションSSOフローを再開します。フェデレーション・プロキシにより、最初のIdPが2つ目のIdPに認証を委任します。


注意:

フェデレーション・プロキシは、「フェデレーション設定」の「HTTPプロキシ設定」を参照しません。これは、ファイアウォールが存在する場合にリモート・サーバーに接続するIdentity Federationによって使用されるものです。

フェデレーションIdPプロキシを使用するには、管理者は、認証用にローカル・スキーム(LDAPSchemeやBasicSchemeなど)ではなくFederationSchemeを使用するようIdentity Federationを構成します。実行時、ユーザーをFederationSchemeを使用して認証する必要がある場合、Identity FederationはSPとして機能し、リモートIdPとのフェデレーションSSOフローを開始します。


注意:

最初のSPに対して作成されたアサーションに、2つ目のIdPによって使用されるプロキシ・フェデレーション認証方式を含めるオプションがあります。これは、SP2とIdP2間のフェデレーションSSOで、SP1とIdP1間で使用されるプロトコルと同じプロトコルが使用されている場合のみ可能です。

useProxiedFedAuthnMethod WLSTコマンドを使用してフェデレーション・プロキシを有効にする方法については、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

31.9 WLSTを使用したIdentity Federationの管理

Identity Federationは管理用にWLSTコマンドを使用します。認証マッピング、パートナ・プロファイルおよびSAML 1.1を管理するためのコマンドに対応する管理フィールドはOracle Access Managementコンソールにありません。これらのWLSTコマンドおよびその他のWLSTコマンドについては、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引