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の説明が続きます](img/oif_new_idp_load.gif)
「図29-1 サービスの詳細をメタデータからロードした場合の「新規アイデンティティ・プロバイダ」ページ」の説明
図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にのみ適用されます。 |
署名証明書 |
プロバイダが使用する署名証明書です。 |
ユーザー・アイデンティティ・ストア |
IdPのユーザーが配置およびマップされるアイデンティティ・ストアです。Identity Federationは、パートナ単位で定義された複数のアイデンティティ・ストアをサポートします。また、ユーザー・アイデンティティ・ストアが選択されていない場合は、デフォルトのAccess Managerストアが使用されます。 |
ユーザー検索ベースDN |
ユーザー・レコードの参照時に使用される基本検索DNです。(オプション。)省略した場合は、選択したユーザー・アイデンティティ・ストア用に構成されているデフォルトのユーザー検索ベースDNが使用されます。) |
マッピング・オプション |
この設定では、アイデンティティ・ストア内のユーザーに着信アサーションをマップする方法を指定します。次のいずれかを選択します。
|
HTTP Basic認証の有効化 |
HTTP基本資格証明を受け入れる場合はこのボックスを選択します。(拡張要素。プロバイダの「Edit」モードのみで使用できます。) |
属性マッピング・プロファイル |
パートナが関連付けられる属性プロファイルを示します。 |
サービスの詳細 |
次のオプションのうち、Identity Federation (RP)がフェデレーションSSOをIdPとともに実行する際に使用するオプションを示します。OpenID 2.0にのみ適用されます。
|
検出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)を定義できます。
新しいアイデンティティ・プロバイダを作成するには、次のようにします。
- Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
- 「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「アイデンティティ・プロバイダ・パートナの作成」を選択します。
- 「サービスの詳細」フィールドで、「プロバイダ・メタデータからロード」を選択します。(通常、SAML 2.0はメタデータで構成します。)
- 「メタデータ・ファイル」という新しいフィールドが表示されます。「参照」をクリックします。
- 対象のメタデータ・ファイルを選択します。
- ファイルからメタデータがロードされます。
- 「保存」をクリックすると、アイデンティティ・プロバイダの定義が作成されます。
29.3.1.2 フェデレーション用の新しいSAML 1.1アイデンティティ・プロバイダの定義
フェデレーション用に新しいSAML 1.1アイデンティティ・プロバイダ(IdP)を定義できます。
新しいアイデンティティ・プロバイダを作成するには、次のようにします。
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)を定義するには、次のようにします。
-
Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
-
「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「アイデンティティ・プロバイダ・パートナの作成」を選択します。
-
手動、またはメタデータ・ファイルのアップロードにより、現在の環境に適した値を入力します。
指定する情報は、プロバイダなどの要素で選択したプロトコルに応じて異なります。
-
「保存」をクリックして、アイデンティティ・プロバイダの定義を作成します。
Google IdPパートナ
GoogleをOpenID 2.0 IdPとして追加するには、次のようにします。
-
Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
-
「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「アイデンティティ・プロバイダ・パートナの作成」を選択します。
-
「起動パッド」から、Identity Federationの「サービス・プロバイダ管理」をクリックします。
-
「プロトコル」ドロップダウン・リストから「OpenID 2.0」を選択します。
-
「サービスの詳細」ドロップダウン・メニューから「Googleプロバイダのデフォルト設定」を選択します。
-
「保存」をクリックすると、アイデンティティ・プロバイダの定義が作成されます。
このパートナは、SPがアサーション属性をGoogle IdPに要求し、それらを対応するセッション属性名にマップするように構成されます。
表29-3を参照してください。
表29-3 Google OpenIDパートナの属性
アサーション属性名 | セッション属性名 |
---|---|
http://axschema.org/contact/country/home |
country |
http://axschema.org/contact/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として追加するには、次のようにします。
- Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
- 「フェデレーション」コンソールで、「フェデレーション」セクションの「作成」(+)ドロップダウン・リストから「アイデンティティ・プロバイダ・パートナの作成」を選択します。
- 「プロトコル」ドロップダウン・リストから「OpenID 2.0」を選択します。
- 「サービスの詳細」ドロップダウン・メニューから「Yahooプロバイダのデフォルト設定」を選択します。
- 「保存」をクリックすると、アイデンティティ・プロバイダの定義が作成されます。
このパートナは、SPがアサーション属性をYahoo IdPに要求し、それらを対応するセッション属性名にマップするように構成されます。
表29-4を参照してください。
表29-4 Yahoo OpenIDパートナの属性
アサーション属性名 | セッション属性名 |
---|---|
http://axschema.org/contact/country/home |
country |
http://axschema.org/contact/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.4 アイデンティティ・プロバイダとしてのIdentity Federationの管理
統合Identity FederationがIdPとして構成されている場合、各リモートSPについての詳細を含むプロファイルを作成およぴ管理することにより、信頼できるパートナとしてリモートSPパートナを定義する必要があります。
この項の内容は次のとおりです。
29.4.1 リモート・サービス・プロバイダ・パートナの作成
「サービス・プロバイダ・パートナ」ページを使用して、Identity FederationがIdPとして構成された場合のパートナ・プロファイルを定義します。サービスの詳細は、手動で指定することもメタデータ・ファイルからロードすることも可能です。
リモート・サービス・プロバイダ・パートナを作成するには、次のようにします。
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セッション属性 | 常に送信 |
---|---|---|
|
$user.attr.mail |
|
firstname |
$user.attr.givenname |
true |
lastname |
$user.attr.sn |
true |
authn-level |
$session.authn_level |
true |
「常に送信」は、その属性が要求されていない場合でも送信するかどうかを示します。属性が要求されているかどうかにかかわらず送信アサーションに含める必要がある場合、「常に送信」を「true」に設定します。「常に送信」が「false」の場合、この属性は要求されていてもアサーションに含まれません。SPが要求を送信すると、メッセージ属性が検索され、式が評価されて、このメッセージ属性に対するマッピング値が算出されます。
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:
|
-
|
expression (前述のように定義され、データ型により修飾されている識別子に基づく) |
- session:
|
-
|
expression (前述のように定義され、データ型により修飾されている識別子に基づく) |
- from user:
|
-
|
29.5.1.1 SAMLレスポンスのAWSロール・マッピング属性
OAMには、SAMLレスポンスでAWSロール・マッピング属性をサポートするために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側
- Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
- 「フェデレーション」セクションの「アイデンティティ・プロバイダ管理」をクリックします。
- 「サービス・プロバイダ属性プロファイル」タブを選択し、「検索」をクリックします。
- 編集のために、検索結果から必要なサービス属性プロファイルを選択します。
- 「属性マッピング」表で、「作成」をクリックし、値をマップする必要がある各属性の属性名マッピングを作成します。
- 「属性値マッピング」表で、「作成」をクリックし、「属性値マッピング」ウィンドウの次のフィールドに入力します:
- メッセージ属性名: 前のステップで作成した必須属性名を選択します。
- アンマップ値の送信: OAM Identity Federationがマッピングが定義されていない値を送信できるようにするには、「アンマップ値の送信」を選択します。
- 「作成」をクリックし、次のフィールドに移入して値マッピングを作成します:
- ローカル値: 属性のローカル値
- 外部値: 外部メッセージで送信される対応する値
- 大/小文字区別なし: 選択した場合、属性値の照合時に大/小文字を区別して文字列比較が行われることを示します。
- ローカルnull: 選択した場合、ローカル値がnull文字列と等しいことを示します(これは空の文字列
""
とは異なります)。 - 外部null: 選択した場合、外部値がnull文字列と等しいことを示します(これは空の文字列
""
とは異なります)。 - デフォルト: 選択した場合、着信外部値が複数のローカル値にマップされている場合に、このローカル値が使用されることを示します。
SP側
- Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
- 「フェデレーション」セクションの「サービス・プロバイダ管理」をクリックします。
- 「アイデンティティ・プロバイダ属性プロファイル」タブを選択し、「検索」をクリックします。
- 編集のために、検索結果から必要なアイデンティティ属性プロファイルを選択します。
- 「属性マッピング」表で、「作成」をクリックし、値をマップする必要がある各属性の属性名マッピングを作成します。
- 「属性値マッピング」表で、「作成」をクリックし、「属性値マッピング」ウィンドウの次のフィールドに入力します:
- 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コンソールを使用して属性値フィルタリングを定義するには、次のステップを実行します。
- Oracle Access Managementコンソールで、ウィンドウの上部にある「フェデレーション」をクリックします。
- 「フェデレーション」セクションの「アイデンティティ・プロバイダ管理」をクリックします。
- 「サービス・プロバイダ属性プロファイル」タブを選択し、「検索」をクリックします。
- 編集のために、検索結果から必要なサービス属性プロファイルを選択します。
- 「属性マッピング」表で、「作成」をクリックし、値をフィルタ処理する必要がある各属性の属性名マッピングを作成します。
- 「属性値フィルタ」表で、「作成」をクリックし、「属性値フィルタ」ウィンドウの次のフィールドに入力します:
- メッセージ属性名: 前のステップで作成した必須属性名を選択します。
- 条件演算子: 次のいずれかを選択します
- すべての条件を満たす必要があることを示すには、
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 を返します。
ノート:
|
例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セッション属性 | 挿入要求 |
---|---|---|
|
|
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から:
|
saml11-sp-partner-profile |
urn:oasis:names:tc:SAML:1.0:am:passwordから:
|
詳細は、次の各トピックを参照してください。
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に、属性共有プラグインの大まかな設計を示します。
属性共有プラグインは、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属性リクエスタを使用する場合
- パートナ/IdP名(フェデレーション・エンジンからリクエストが発行されている場合)。
- 認証で使用されるプラグインで構成されているIdP。
- リクエストのサブジェクトDN(構成済SubjectDN-IdPマップから問合せを取得するIdPを判断)。具体性が最も高いレベル(cn=Joe User,ou=Finance,o=Company,c=US)から最も低いレベル(c=US)にSubjectDNをマッピング。
- デフォルト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.2 属性共有の構成
属性共有プラグインには、オプションの構成パラメータがあります。
表29-12に、属性共有プラグインを示します。
表29-12 属性共有プラグインの構成パラメータ
パラメータ | 説明 |
---|---|
NameIDValueAttribute |
ユーザーの名前IDを取得できるセッション属性の名前。 |
NameIDFormatAttribute |
名前IDフォーマットとして使用する値を含む属性の名前。 |
AttributeAuthorityAttribute |
SPが<AttributeQuery>を送信する先のIdPとして使用する値を含む属性の名前。 |
RequestedAttributes |
このパラメータは、 |
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を決定するには、次の検索が順に実行されます。
属性共有プラグインが次のことを行います。
-
NameIDValueAttributeが指定されている場合、セッションから指定の属性値を取得し、それを名前IDとして使用します。
-
NameIDValueAttributeが指定されていない場合、名前IDとして
fed.nameidvalue
の値を使用します。 -
前述の方法で判断できない場合、属性共有プラグインは、nullまたは空の名前IDでフェデレーション・エンジンを起動し、ユーザーID (KEY_USERNAME_DNセッション属性で指定)がSP属性リクエスタに送信されます。
属性リクエスタ(SP)は次のことを行います。
-
名前IDがリクエストに含まれていれば、ユーザーの名前としてこの値を使用します。
-
名前IDの指定がなく、ユーザーIDがある場合(認証プラグイン起動時に発生)、
defaultattrrequestnameiduserattribute
属性の値を取得し(このIdPのSP構成で検出)、これを名前IDとして使用します。 -
SAML 2.0を使用している場合のみ: 名前IDが決定されていない状態でSSOがシンプル名前IDマッピングで構成されている場合、
nameiduserattribute
属性を使用します(このIdPのSP構成で検出)。たとえば、この属性値が$user.attr.mail
である場合、この属性からユーザーの名前を抽出し、これを名前IDとして使用します。 -
名前IDがまだ決定されない場合、エラーがスローされます。
29.7.2.2 名前IDフォーマット
これは、ユーザーの名前IDのフォーマットです。
名前IDフォーマットを決定するには、次の検索が順に実行されます。属性共有プラグインが次のことを行います。
-
NameIDFormatAttributeパラメータが指定されている場合、指定の属性の値を取得し、それを名前IDフォーマットとして使用します。
表29-12を参照してください。
-
fed.nameidformat
属性の値を名前IDフォーマットとして使用します。表29-13を参照してください。
-
DefaultNameIDFormat
の値を名前IDフォーマットとして使用します。表29-12を参照してください。
-
名前IDフォーマットがまだ決定されない場合、属性共有プラグインがフェデレーションをnull/空の名前IDフォーマットで起動します。
属性リクエスタ(SP)は次のことを行います。
-
リクエストで指定されている名前IDフォーマットを使用します。
-
defaultattrrequestnameidformat
属性の値(このIdPのSP構成で検出)を使用します。 -
SAML 2.0を使用している場合のみ: 名前IDフォーマットがまだ決定されていない場合、
defaultauthnrequestnameidformat
属性の値(このIdPのSP構成で検出)を使用します。 -
名前IDフォーマットがまだ決定されない場合、エラーがスローされます。
29.7.2.3 IdP
これは、属性リクエストが送信されるIdPパートナです。
IdPパートナを決定するには、次の検索が順に実行されます。属性共有プラグインが次のことを行います。
-
AttributeAuthorityAttributeが指定されている場合、その値を取得し、それをIdP名として使用します。
表29-12を参照してください。
-
fed.partner
属性の値をIdP名として使用します。表29-13を参照してください。
-
DefaultAttributeAuthority
パラメータの値をIdP名として使用します。表29-12を参照してください。
-
IdPがまだ決定されない場合、属性共有プラグインがフェデレーションをnull/空の名前IDフォーマットで起動します。
属性リクエスタ(SP)は次のことを行います。
-
属性共有プラグインに送信されたリクエストに含まれていたIdP名を使用します。
-
x509を使用している場合のみ: DN-IdPマッピングを検出し、このユーザーDNのIdPを決定します。
-
defaultattrauthority
属性の値(SP構成で検出)を使用します。 -
defaultssoidp
属性の値(SP構成で検出)を使用します。 -
IdP名がまだ決定されない場合、エラーがスローされます。
29.7.2.4 RequestedAttributes
これらは、属性認証局に対して要求された属性です。
属性を決定するには、次の検索が順に実行されます。属性共有プラグインが次のことを行います。
RequestedAttributes
パラメータが定義されている場合、指定の属性を使用します。何も指定されていない場合、属性は送信されません。
表29-12を参照してください。
属性リクエスタ(SP)は次のことを行います。
-
RequestedAttributes
パラメータが定義されている場合、指定の属性を使用します。表29-12を参照してください。
-
属性をIdPパートナ・プロファイル内の
request from partner(send-with-sso)
属性に追加します。
属性レスポンダ(IdP)は次のことを行います。
-
SPからの<AttributeQuery>に特定の属性値に対するリクエストが含まれている場合、これらの属性の値を返します。
-
属性値が要求されていない場合、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コマンド・リファレンスを参照してください。