1. Oracle Access Management管理者ガイド
  2. Oracle Access Management Identity Federationの管理
  3. Identity Federationパートナの管理

29 Identity Federationパートナの管理

Oracle Access Management Identity Federationにおけるフェデレーション・パートナ(サービス・プロバイダとアイデンティティ・プロバイダ)の概念について理解を深める必要があります。

次の各トピックでは、アイデンティティ・フェデレーション・パートナの管理方法について説明します。

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

アイデンティティ・フェデレーション・パートナの管理を始める前に、フェデレーションおよびパートナの概念を理解しておく必要があります。

次のタスクを完了しておく必要があります。

「Identity Federationの有効化」を参照してください。

統合されたIdentity Federationサーバーは、Security Access Markup Language (SAML) 2.0仕様、SAML 1.1、OpenID 2.0またはWS-Federation 1.1のいずれかを使用してリクエスト・メッセージとレスポンス・メッセージの転送と受信をサポートします。したがって、アイデンティティ・プロバイダ(IdP)とサービス・プロバイダ(SP)のパートナは、定義されたこれらのプロトコルのいずれかを使用して作成できます。SAMLパートナとOpenIDパートナは、Oracle Access Managementコンソールを使用して定義できます。WS-Federationパートナは、WLSTコマンドを使用して作成できます。

「リモート・アイデンティティ・プロバイダ・パートナの作成」を参照してください。

「リモート・サービス・プロバイダ・パートナの作成」を参照してください。

Oracle Fusion Middleware WebLogic Scripting Tool Identity and Access Managementコマンド・リファレンスを参照してください。

29.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コマンドによってのみ管理できます。新しいパートナが作成されるたびに、表29-1に示されているデフォルト・パートナ・プロファイルの1つに関連付けられます。新しいパートナ・プロファイルをパートナに割り当てるには、パートナを作成した後にsetFedPartnerProfile() WLSTコマンドを使用します。

「WLSTを使用したIdentity Federationの管理」を参照してください。

表29-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パートナ・プロファイル

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

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

SPであるIdentity Federationサーバーの管理を開始するには、Oracle Access Managementコンソールの「起動パッド」からIdentity Federationの「サービス・プロバイダ管理」リンクをクリックします。この項の内容は次のとおりです。

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

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

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

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

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

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

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

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

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

表29-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にのみ適用されます。

29.3.1.1 フェデレーション用の新しいSAML 2.0アイデンティティ・プロバイダの定義

フェデレーション用に新しいSAML 2.0アイデンティティ・プロバイダ(IdP)を定義できます。

新しいアイデンティティ・プロバイダを作成するには、次のようにします。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
  2. 「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「アイデンティティ・プロバイダ・パートナの作成」を選択します。
  3. 「サービスの詳細」フィールドで、「プロバイダ・メタデータからロード」を選択します。(通常、SAML 2.0はメタデータで構成します。)
  4. 「メタデータ・ファイル」という新しいフィールドが表示されます。「参照」をクリックします。
  5. 対象のメタデータ・ファイルを選択します。
  6. ファイルからメタデータがロードされます。
  7. 「保存」をクリックすると、アイデンティティ・プロバイダの定義が作成されます。
29.3.1.2 フェデレーション用の新しいSAML 1.1アイデンティティ・プロバイダの定義

フェデレーション用に新しいSAML 1.1アイデンティティ・プロバイダ(IdP)を定義できます。

新しいアイデンティティ・プロバイダを作成するには、次のようにします。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
  2. 「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「アイデンティティ・プロバイダ・パートナの作成」を選択します。
  3. 「サービスの詳細」フィールドで、「手動で入力」を選択します。
  4. 使用環境に適した値を、「新規アイデンティティ・プロバイダ」ページに入力します。指定する情報は、プロバイダなどの要素で選択したプロトコルに応じて異なります。

    表29-2を参照してください。

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

    ノート:

    一部のSAML 1.1構成パラメータはOracle Access Managementコンソールから設定できません。このようなパラメータの値はupdatePartnerProperty WLSTコマンドを使用して変更できます。

    「updatePartnerProperty」(『WebLogic Server WLSTコマンド・リファレンス』ガイド)を参照してください。

29.3.1.3 フェデレーション用の新しいOpenID 2.0アイデンティティ・プロバイダの定義

11gリリース2 (11.1.2.3)以降では、Identity FederationはOpenIDをサポートし、OpenID RP/SPとして機能します。OpenIDプロバイダは、IdPパートナとして登録できます。

これらのOpenIDパートナを使用して作成された認証スキームは、OpenIDアイデンティティ・プロバイダが提供する認証サービスを使用してAccess Managerリソースを保護します。

フェデレーション用に新しいOpenID 2.0アイデンティティ・プロバイダ(IdP)を定義するには、次のようにします。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。

  2. 「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「アイデンティティ・プロバイダ・パートナの作成」を選択します。

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

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

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

Google IdPパートナ

GoogleをOpenID 2.0 IdPとして追加するには、次のようにします。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。

  2. 「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「アイデンティティ・プロバイダ・パートナの作成」を選択します。

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

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

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

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

このパートナは、SPがアサーション属性をGoogle IdPに要求し、それらを対応するセッション属性名にマップするように構成されます。

表29-3を参照してください。

表29-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. 「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「アイデンティティ・プロバイダ・パートナの作成」を選択します。
  3. 「プロトコル」ドロップダウン・リストから「OpenID 2.0」を選択します。
  4. 「サービスの詳細」ドロップダウン・メニューから「Yahooプロバイダのデフォルト設定」を選択します。
  5. 「保存」をクリックすると、アイデンティティ・プロバイダの定義が作成されます。

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

表29-4を参照してください。

表29-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属性と一致するようになります。

29.3.1.4 OpenID Simple Registrationの有効化

デフォルトでは、Identity FederationはAttribute Exchange Extensionを使用して、OpenID IdPからユーザー・アイデンティティ属性を取得します。

ただし、古いSimple Registration (SREG)拡張機能を使用する必要がある場合は、次のWLSTコマンドを実行することで、有効化できます。

putBooleanProperty("/spglobal/openid20axenabled", "false")
putBooleanProperty("/spglobal/openid20sregenabled", "true")
29.3.1.5 OpenID Simple Registrationの無効化

Attribute Exchange Extensionに対してSimple Registrationを無効にできます。

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

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

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

次の各トピックでは、Identity Federationの既存のIdPを管理する方法について説明します。

29.3.2.1 既存のアイデンティティ・プロバイダの検索

「フェデレーション」コンソールから既存のアイデンティティ・プロバイダを検索できます。

検索するには、次のようにします。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
  2. 「フェデレーション」コンソールで、「フェデレーション」セクションの「アイデンティティ・プロバイダ管理」をクリックします。
  3. ページの「検索」に、アイデンティティ・プロバイダの検索基準を入力します。"*"(アスタリスク)文字と"."(ピリオド)文字は、検索のワイルドカードとしてサポートされています。

    検索パラメータの詳細は、表29-5を参照してください。

  4. 「検索」をクリックします。
  5. 検索結果は、表に表示されます。

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

    要素 説明

    パートナ名

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

    プロバイダID

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

    ステータス

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

    説明

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

    プロトコル

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

    表29-5では、プロバイダの検索に使用できるパラメータについて説明します。

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

    図29-3の説明が続きます
    「図29-3 アイデンティティ・プロバイダの検索」の説明
29.3.2.2 フェデレーション用のアイデンティティ・プロバイダの更新

フェデレーション用のアイデンティティ・プロバイダを検索し、プロバイダ情報を更新できます。

フェデレーション用のアイデンティティ・プロバイダを更新するには、次のようにします。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
  2. 「フェデレーション」コンソールで、「フェデレーション」セクションの「アイデンティティ・プロバイダ管理」をクリックします。
  3. 更新対象のプロバイダを検索します。
  4. 検索結果の表から対象のプロバイダを選択します。
  5. 鉛筆アイコンをクリックして、プロバイダの更新ページを表示します。このページは、「サービス情報」、「署名証明書」、「ユーザー・マッピング」および「詳細設定」のセクションに分かれています。
  6. プロバイダの情報を更新します。

    詳細は、表29-2を参照。

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

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

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

この項の内容は次のとおりです。

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

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

リモート・サービス・プロバイダ・パートナを作成するには、次のようにします。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
  2. 「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「サービス・プロバイダ・パートナの作成」を選択します。
  3. パラメータの値を入力します。

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

    表29-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にのみ適用されます。

    「SAML 2.0の使用」を参照してください。

    「SAML 1.1の使用」を参照してください。

    NameID値

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

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

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

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

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

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

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

    ユーザー検索ベース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にのみ適用されます。
  4. 「保存」をクリックして、リモートSPパートナ・プロファイルを作成します。

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

リモートSPパートナのプロファイルの編集および管理、プロファイルの検索、属性値の変更が可能です。

既存のサービス・プロバイダ・パートナ・プロファイルを検索するには、次のようにします。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
  2. 「フェデレーション」コンソールで、「フェデレーション」セクションの「サービス・プロバイダ管理」をクリックします。
  3. このページの「検索」セクションに、アイデンティティ・プロバイダの適切な検索基準を入力します。"*"(アスタリスク)文字と"."(ピリオド)文字は、検索のワイルドカードとしてサポートされています。

    検索パラメータの詳細は、表29-5を参照してください。

  4. 「検索」をクリックします。
  5. 「検索結果」表から適切なパートナを選択し、ツールバーの「編集」をクリックします。

    新しいタブが開いて、そのパートナの属性が表示されます。その属性に加えて、

    変更可能な拡張属性の詳細は、表29-6を参照してください。

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

    • アサーションの暗号化

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

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

ノート:

SAML 1.1を使用する場合には、署名に証明書を含めることができます。

『WebLogic Server WLSTコマンド・リファレンス』を参照してください。

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

Identity Federation (SPとして構成した場合)は、フェデレーション・プロセス中、IdPに対して属性を要求できます。

このためには、着信アサーションの属性の名前を、Access Managerセッションで使用できるローカル属性(たとえば$session.attr.fed.attr.ATTR_NAME)にマッピングします。IdP属性マッピング・プロファイルにはこのようなマッピングが含まれます。

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

ノート:

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

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

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

    「SP属性マッピング・プロファイルの使用」を参照してください。

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

    「IdP属性マッピング・プロファイルの使用」を参照してください。

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

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

式は、Access Manager属性をアサーションまたは送信メッセージに含めるときに、その値を検出するのに使用されます。表29-7は、サンプルSP属性マッピングの一部です。

表29-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が要求を送信すると、メッセージ属性が検索され、式が評価されて、このメッセージ属性に対するマッピング値が算出されます。

ノート:

値式では、OAMポリシー式言語が使用されます。複数のメッセージ属性に同じ値式を使用することもできます。

「SSOのポリシー・レスポンスの概要」を参照してください。

SPパートナ・プロファイルを作成または変更する際、使用可能な属性マッピング・プロファイルがドロップダウン・リストに表示されます。sp-attribute-profileがデフォルト・プロファイルです。

「リモート・サービス・プロバイダ・パートナの作成」を参照してください。

デフォルト・プロファイルを選択するか、緑のプラス記号をクリックして、カスタム・マッピング・プロファイルを作成します。SPパートナに対して新しい属性マッピングを作成する際、属性の値文字列内に式を埋め込むことができます。これらの式は、実行時の値で置換されます。

表29-8に、属性マッピング値の式を示します。

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

値の型 許容値 式

request

httpheader.HTTP_HEADER_NAME

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

request

cookie.COOKIE_NAME

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

request

client_ip

$request.client_ipとして格納

session

authn_level

$session.authn_levelとして格納

session

authn_scheme

$session.authn_schemeとして格納

session

count

$session.countとして格納

session

creation

$session.creationとして格納

session

expiration

$session.expirationとして格納

session

attr.ATTR_NAME

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

user

userid

$user.useridとして格納

user

id_domain

$user.id_domainとして格納

user

guid

$user.guidとして格納

user

groups

$user.groupsとして格納

user

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の名前です

expression

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

- session:

  • $session.authn_level

  • $session.authn_scheme

  • $session.count

  • $session.creation

  • $session.expiration

  • $session.attr.ATTR_NAME

-

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

expression

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

- from 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ユーザー属性の名前です
29.5.1.1 SAMLレスポンスのAWSロール・マッピング属性

OAMには、SAMLレスポンスでAWSロール・マッピング属性をサポートするためにSP属性プロファイルで構成できる新しい関数が用意されています。

SP属性プロファイルで次の式を使用します:
$func.aws_assertion_role_attr_mapping("$base_expression", "account-number", "saml-provider-name")
ここで、$base_expressionはユーザー・グループに評価される式、account-numberはAWSアカウント番号、saml-provider-nameはAWS SAMLプロバイダ名です。

たとえば、次のような式があります。

$func.aws_assertion_role_attr_mapping("$user.groups","123456789","OAM")

属性名がhttps://aws.amazon.com/SAML/Attributes/Roleで、ユーザーがグループOAMSSORoleおよびEC2SSORoleに属する場合、次のSAMLレスポンスが返されます: 


<Attribute Name="https://aws.amazon.com/SAML/Attributes/Role">
<AttributeValue>arn:aws:iam::123456789:role/OAMSSORole,arn:aws:iam::123456789:saml-provider/OAM</AttributeValue>
<AttributeValue>arn:aws:iam::123456789:role/EC2SSORole,arn:aws:iam::123456789:saml-provider/OAM</AttributeValue>
</Attribute>

29.5.2 属性値マッピングおよびフィルタリングの使用

トピック

29.5.2.1 属性値マッピングについて

属性値マッピングを使用すると、メッセージの送信時または受信時にSAMLメッセージのローカル属性に割り当てる必要がある値を指定できます。

属性値マッピングには次の特性があります:

  • 値マッピングは、ローカル値とこれに対応する外部値の組合せで構成されます。
  • 値マッピングは任意のローカル属性に対して定義できます。ローカル属性ごとに複数の値マッピングを定義できます。
  • 値マッピングを使用して、同じローカル値に対して様々な外部値をマップできます。送信モードで使用される外部値の決定には、デフォルトの属性が使用されます。
  • 値マッピングを使用して、同じ外部値に対して様々なローカル値をマップできます。外部値からローカル値へのマッピング時に受信モードで使用されるローカル値の決定には、デフォルトの属性が使用されます。

属性値マッピングは、OAMコンソールまたはWLSTコマンドを使用して構成できます。

OAMコンソールによる属性値マッピングの構成の詳細は、「属性値マッピングの構成」を参照してください。

構成に使用可能なWLSTコマンドの詳細は、『Identity and Access ManagementのためのWebLogic Scripting Toolコマンド・リファレンス』のIdentity Federationコマンドに関する項にあるsetSPPartnerAttributeValueMapping、deleteSPPartnerAttributeValueMapping、displaySPPartnerAttributeValueMapping、setIdPPartnerAttributeValueMapping、deleteIdPPartnerAttributeValueMappingおよびdisplayIdPPartnerAttributeValueMappingを参照してください。

29.5.2.2 属性値マッピングの構成

OAMコンソールを使用して属性値マッピングを定義するには、次のステップを実行します。

IdP側

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
  2. 「フェデレーション」セクションの「アイデンティティ・プロバイダ管理」をクリックします。
  3. 「サービス・プロバイダ属性プロファイル」タブを選択し、「検索」をクリックします。
  4. 編集のために、検索結果から必要なサービス属性プロファイルを選択します。
  5. 「属性マッピング」表で、「作成」をクリックし、値をマップする必要がある各属性の属性名マッピングを作成します。
  6. 「属性値マッピング」表で、「作成」をクリックし、「属性値マッピング」ウィンドウの次のフィールドに入力します:
    • メッセージ属性名: 前のステップで作成した必須属性名を選択します。
    • アンマップ値の送信: OAM Identity Federationがマッピングが定義されていない値を送信できるようにするには、「アンマップ値の送信」を選択します。
    • 「作成」をクリックし、次のフィールドに移入して値マッピングを作成します:
      • ローカル値: 属性のローカル値
      • 外部値: 外部メッセージで送信される対応する値
      • 大/小文字区別なし: 選択した場合、属性値の照合時に大/小文字を区別して文字列比較が行われることを示します。
      • ローカルnull: 選択した場合、ローカル値がnull文字列と等しいことを示します(これは空の文字列""とは異なります)。
      • 外部null: 選択した場合、外部値がnull文字列と等しいことを示します(これは空の文字列""とは異なります)。
      • デフォルト: 選択した場合、着信外部値が複数のローカル値にマップされている場合に、このローカル値が使用されることを示します。

SP側

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
  2. 「フェデレーション」セクションの「サービス・プロバイダ管理」をクリックします。
  3. 「アイデンティティ・プロバイダ属性プロファイル」タブを選択し、「検索」をクリックします。
  4. 編集のために、検索結果から必要なアイデンティティ属性プロファイルを選択します。
  5. 「属性マッピング」表で、「作成」をクリックし、値をマップする必要がある各属性の属性名マッピングを作成します。
  6. 「属性値マッピング」表で、「作成」をクリックし、「属性値マッピング」ウィンドウの次のフィールドに入力します:
    • OAMセッション属性名: 前のステップで作成した必須属性名を選択します。
    • アンマップ値の受信: OAM Identity Federationがマッピングが定義されていない値を受信できるようにするには、「アンマップ値の受信」を選択します。
    • 「作成」をクリックし、次のフィールドに移入して値マッピングを作成します:
      • 受信値: SPプロバイダが受信した値。
      • 外部値: OAMセッションで保存する対応する値。
      • 大/小文字区別なし: 選択した場合、属性値の照合時に大/小文字を区別して文字列比較が行われることを示します。
      • 受信null: 選択した場合、受信した値がnull文字列と等しいことを示します(これは空の文字列""とは異なります)。
      • 外部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"のデフォルト・ローカル値として定義されているため、srmtsも"Senior Member of Technical Staff"にマップされていますが、"Senior Member of Technical Staff"はsmtsにマップされます。
  • ローカル値NULLが文字列noneにマップされます。
  • smtsおよびsrmtsは、ともに"Senior Member of Technical Staff"にマップされます。
  • 「アンマップ値」の「受信」が選択されており、"CEO"にはルールが定義されていないため、この値はそれ自体にマップされます。
29.5.2.3 属性値フィルタリングについて

属性値フィルタリングを使用すると、SAMLメッセージの送信時に許可されるローカル値を指定できます。

属性値フィルタリングには次の特性があります:

  • フィルタ・ルールは任意のローカル属性に対して定義できます。フィルタ・ルールによって各属性値を評価し、送信可能かどうかを決定します。評価結果が正である場合、値は送信されます。正でない場合、送信対象の属性値のリストから削除されます。
  • ローカル属性ごとに複数のフィルタリング・ルールを定義できます。

    値を送信する場合、OAM Identity Federationは次のいずれかに設定できます:

    • すべてのフィルタが正常に評価された場合のみ送信します。
    • 少なくとも1つのフィルタが正常に評価された場合のみ送信します。
  • 比較のタイプおよび比較する文字列値を指定して、フィルタリング・ルールを定義できます。
  • OAM Identity Federationでは、属性値を文字列と比較する際に、次の比較タイプがサポートされます:
    • 次と等しい
    • 次と等しくない
    • 次で始まる
    • 次で終わる
    • 次を含む
    • 次を含まない
    • nullと等しい
    • nullと等しくない
  • これらの比較タイプに加えて、フィルタリングでは正規表現がサポートされているため、属性値を正規表現と照合できます。フィルタリング・ルールを使用して、比較時に大/小文字を区別するかどうかを指定できます。

属性値フィルタリングは、OAMコンソールまたはWLSTコマンドを使用して構成できます。

OAMコンソールによる属性値フィルタリングの構成の詳細は、「属性値フィルタリングの構成」を参照してください。

構成に使用可能なWLSTコマンドの詳細は、『Identity and Access ManagementのためのWebLogic Scripting Toolコマンド・リファレンス』のIdentity Federationコマンドに関する項にあるsetSPPartnerAttributeValueFilter、deleteSPPartnerAttributeValueFilterおよびdisplaySPPartnerAttributeValueFilterを参照してください。

29.5.2.4 属性値フィルタリングの構成

OAMコンソールを使用して属性値フィルタリングを定義するには、次のステップを実行します。

  1. Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
  2. 「フェデレーション」セクションの「アイデンティティ・プロバイダ管理」をクリックします。
  3. 「サービス・プロバイダ属性プロファイル」タブを選択し、「検索」をクリックします。
  4. 編集のために、検索結果から必要なサービス属性プロファイルを選択します。
  5. 「属性マッピング」表で、「作成」をクリックし、値をフィルタ処理する必要がある各属性の属性名マッピングを作成します。
  6. 「属性値フィルタ」表で、「作成」をクリックし、「属性値フィルタ」ウィンドウの次のフィールドに入力します:
    • メッセージ属性名: 前のステップで作成した必須属性名を選択します。
    • 条件演算子: 次のいずれかを選択します
      • すべての条件を満たす必要があることを示すには、ANDを選択します。
      • 属性を送信するには、1つの条件を満たすだけで十分であることを示すには、ORを選択します。
    • 「作成」をクリックし、次のフィールドに入力します:
      • 条件: 属性値の評価に使用される条件。サポートされる条件の詳細は、表29-9を参照してください
      • 式: 属性値の評価に使用される値または正規表現。
      • 大/小文字区別なし: 選択した場合、属性値の照合時に大/小文字を区別して文字列比較が行われることを示します。

OAMには、次のフィルタリング条件があります。これらのルールを使用して許容値が決定されます。したがって、ルールがtrueと評価された場合は、値の送信が許可されます。

表29-9 属性値フィルタリング条件

Condition 説明
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 null 送信属性値がnullでない場合、フィルタリング・ルールはtrueを返します。
regexp 送信属性値が式の値で定義されている正規表現と一致する場合、フィルタリング・ルールはtrueを返します。

ノート:

  • 式の値は、標準のUNIX正規表現である必要があります。
  • 正規表現ではすでに大/小文字が区別されないため、ignoreCaseフラグは属性値の処理中無視されます。
例: 正規表現 説明
.*rector rectorで終わる任意の文字列
[^abc] a、bまたはc以外の任意の文字(否定)
user\d user0、user1、...、user9
a*b 文字aで始まり、文字bで終わる任意の文字列(たとえば、aaaaab)

例1

次の例に、属性titleの値フィルタ構成および対応する結果を示します。

サンプル構成

  • 属性名: title
  • 条件演算子: and
  • 値フィルタ:
    Condition 式 大/小文字区別なし
    does not equal Vice-President 選択
    contains President 選択

サンプル結果

値 値を送信するか
Vice-President いいえ
President はい
Vice-President いいえ
Senior Vice-President はい

例2

属性値マッピングが属性値マッピングの構成例で定義されているとおりだとします

属性titleの値フィルタ構成は、次のような結果になります:

サンプル構成

  • 属性名: title
  • 条件演算子: and
  • 値フィルタ:
    Condition 式 大/小文字区別なし
    does not equal mngr 選択
    ends with mts 未選択

サンプル結果

値 値を送信するか 送信される値
mngr いいえ  
cmts はい Consulting Member of Technical Staff

ノート:

  • 送信される値は、mngrと等しくてはいけないため、値mngrは送信されません。
  • cmtsは(すべてのフィルタ条件がtrueと評価されるため)送信でき、Consulting Member of Technical Staffにマップされます。

次の値フィルタでも同じ結果になります:

Condition 式 大/小文字区別なし
does not equal mngr 選択
regexp *mts N/A

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

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

プロファイルは、次のデータを含めることを許可します。

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

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

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

表29-10に、サンプルIdP属性マッピングを示します。

表29-10 サンプルIdP属性マッピング

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

mail

email

true

givenname

true

sn

surname

uid

uid

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

IdPパートナ・プロファイルを作成または変更する際、属性マッピング・プロファイルがドロップダウン・リストに表示されます。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はサポートしていません。

29.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値に対してセッション属性を使用できます。

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

表29-11 フェデレーション認証方式から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

詳細は、次の各トピックを参照してください。

29.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にリダイレクトされます。

29.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によって元々認証されていたメカニズムの強度を反映する方法を提供します。

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

代替認証スキームは、Oracle Access Managementコンソールではなく、WLSTコマンドによってのみ構成可能です。

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

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

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

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

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

ノート:

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

代替認証スキームの構成に使用するWLSTコマンドsetSPPartnerAlternateSchemeおよびsetSPPartnerProfileAlternateSchemeの詳細は、『WebLogic Server WLSTコマンド・リファレンス』を参照してください。

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

認証方式、認証スキーム、認証レベルのマッピングはすべて、WLSTコマンドを使って構成されます。

これは、パートナ・レベル、またはこのレベルでの定義がない場合は、パートナ・プロファイル・レベルで構成します。

「WLSTを使用したIdentity Federationの管理」を参照してください。

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

Identity Federationには、Access ManagerがIdPにユーザー属性を要求できるようにするための属性共有プラグインが用意されています。

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

ノート:

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

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

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

Identity Federationは、リモートIdPにユーザー属性を要求するには、SPとして構成されている必要があります。

図29-4に、属性共有プラグインの大まかな設計を示します。

図29-4 属性共有プラグインの設計

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

属性共有プラグインは、Access Managerカスタム認証モジュールに含めることができ、ユーザー認証後に起動できます。属性共有プラグインは、Identity Federation Java APIを起動し、ユーザー属性をAccess Managerセッションに設定し、SPによって処理できる属性リクエストにJava引数を変換することにより、ユーザー属性をフェッチします。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セッションに設定します。後続の項で詳細を示します。

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

属性リクエスタ・サービスは、SOAP属性リクエストを処理し、SOAP属性レスポンスを返します。

「SOAPエンドポイントの使用」を参照してください。

属性リクエストには、SubjectDNと、その他の要求された属性とその値のリストが含まれます。属性リクエスタ・サービスは、リクエストから次のいずれかを(リストの順で検索)抽出することにより、属性をフェッチするIdPを識別します。

SP属性リクエスタを使用する場合

  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メッセージが構築され、コール元に戻されます。

次の例は、サンプルのSOAP属性リクエストです。

サンプルの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>

次の例は、サンプルのSOAP属性レスポンスです。

サンプルの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>
29.7.1.2 IdP属性レスポンダの使用

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

ノート:

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

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

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

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

29.7.2 属性共有の構成

属性共有プラグインには、オプションの構成パラメータがあります。

表29-12に、属性共有プラグインを示します。

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

パラメータ 説明

NameIDValueAttribute

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

NameIDFormatAttribute

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

AttributeAuthorityAttribute

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

RequestedAttributes

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

DefaultNameIDFormat

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

DefaultAttributeAuthority

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

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

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

属性 説明

fed.partner

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

fed.nameidformat

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

fed.nameidvalue

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

KEY_USERNAME_DN

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

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

29.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がまだ決定されない場合、エラーがスローされます。

29.7.2.2 名前IDフォーマット

これは、ユーザーの名前IDのフォーマットです。

名前IDフォーマットを決定するには、次の検索が順に実行されます。属性共有プラグインが次のことを行います。

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

    表29-12を参照してください。

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

    表29-13を参照してください。

  3. DefaultNameIDFormatの値を名前IDフォーマットとして使用します。

    表29-12を参照してください。

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

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

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

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

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

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

29.7.2.3 IdP

これは、属性リクエストが送信されるIdPパートナです。

IdPパートナを決定するには、次の検索が順に実行されます。属性共有プラグインが次のことを行います。

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

    表29-12を参照してください。

  2. fed.partner属性の値をIdP名として使用します。

    表29-13を参照してください。

  3. DefaultAttributeAuthorityパラメータの値をIdP名として使用します。

    表29-12を参照してください。

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

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

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

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

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

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

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

29.7.2.4 RequestedAttributes

これらは、属性認証局に対して要求された属性です。

属性を決定するには、次の検索が順に実行されます。属性共有プラグインが次のことを行います。

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

表29-12を参照してください。

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

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

    表29-12を参照してください。

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

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

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

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

29.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間で使用されるプロトコルと同じプロトコルが使用されている場合のみ可能です。

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

Identity Federationでは管理にWLSTコマンドを使用します。

認証マッピング、パートナ・プロファイルおよびSAML 1.1を管理するためのコマンドはありますが、それに対応する管理フィールドはOracle Access Managementコンソールにありません。これらのWLSTコマンドおよび他のWLSTコマンドの詳細は、次のドキュメントを参照してよく理解してください。

Oracle Fusion Middleware WebLogic Scripting Tool Identity and Access Managementコマンド・リファレンスを参照してください。