45.4 トークン検証テンプレートの管理

検証テンプレートは、着信トークンの検証に使用します。

リクエスタ・パートナまたはユーザー・レコードに着信トークンをマップするのに使用することもできます。

OnBehalfOfユースケースの場合、WS-Trust検証テンプレートが存在する必要があります。
アサーションを検証するためには、発行局パートナ・プロファイルが存在する必要があります。

セキュリティ・トークン・サービス・エンドポイントは、WSSヘッダー内のトークンを検証する方法とトークンとバインディング・データをリクエスタにマップする方法を示すWSS検証テンプレートにリンクされます。

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

45.4.1 トークン検証テンプレートの管理について

セキュリティ・トークン・サービス・エンドポイントは常に、リクエストをリクエスタ・エントリまたはユーザーにマップする方法を示すWS-Security検証テンプレートでマップされます。

マッピングが必要で一致が見つからない場合、処理は失敗します。
マッピングが不要な場合は、デフォルトのリクエスタ・パートナ・プロファイルが使用されます。
どちらの場合も、リクエスタ・パートナ・プロファイルが取得されます。
ユーザー・レコードへのマッピングが実行される場合は、デフォルトのリクエスタ・パートナ・プロファイルが使用されます。
リクエスタ・パートナ・エントリへのマッピングが実行される場合は、このパートナのリクエスタ・パートナ・プロファイルが使用されます。

検証テンプレートによってトークン検証ルールが決定されます。

着信トークンを検証およびマップするかどうか。
マッピングが有効な場合に使用されるマッピング・ルール。

表45-8に示すように、検証テンプレートはトークン・タイプおよびプロトコルに固有です。

表45-8 検証テンプレートのプロトコル

プロトコル	説明
WS-Security	WS-Securityトークンのみを検証: 使用可能なマッピング・アクション: アクションなし、パートナへのバインディング・データのマップ、パートナへの着信トークンのマップ、ユーザーへの着信トークンのマップ、パートナへのバインディング・データのマップ、ユーザーへの着信トークンのマップサポートされているトークン・タイプ: SAML 1.1、SAML 2.0、ユーザー名、X.509、Kerberos、なし。トークン・プロトコルをWS-TrustからWS-Securityに切り替えても、「トークン・タイプ」リストのオプションは変更されません。ただし、必要な「デフォルト・パートナ・プロファイル」リストが表示され、ここからWS-Securityのプロファイルの1つを選択する必要があります。
WS-Trust	RST (リクエスト)のOBO (代理)フィールドに含まれるトークンのみを検証: 使用可能なマッピング・アクション: なし、ユーザーへの着信トークンのマップサポートされているトークン・タイプ: SAML 1.1、SAML 2.0、ユーザー名、X.509、Kerberos、OAM、カスタム。

プロトコル

説明

WS-Security

WS-Securityトークンのみを検証:

使用可能なマッピング・アクション: アクションなし、パートナへのバインディング・データのマップ、パートナへの着信トークンのマップ、ユーザーへの着信トークンのマップ、パートナへのバインディング・データのマップ、ユーザーへの着信トークンのマップ
サポートされているトークン・タイプ: SAML 1.1、SAML 2.0、ユーザー名、X.509、Kerberos、なし。

トークン・プロトコルをWS-TrustからWS-Securityに切り替えても、「トークン・タイプ」リストのオプションは変更されません。ただし、必要な「デフォルト・パートナ・プロファイル」リストが表示され、ここからWS-Securityのプロファイルの1つを選択する必要があります。

WS-Trust

RST (リクエスト)のOBO (代理)フィールドに含まれるトークンのみを検証:

使用可能なマッピング・アクション: なし、ユーザーへの着信トークンのマップ
サポートされているトークン・タイプ: SAML 1.1、SAML 2.0、ユーザー名、X.509、Kerberos、OAM、カスタム。

検証テンプレートのマッピング・ルールは、着信トークンからのデータを使用して、ユーザーまたはパートナへの着信データのマップ方法を決定します。

ユーザー名トークンのユーザー名
KerberosトークンのユーザーID
SAMLトークンの名前IDおよび属性
X.509トークンのDNコンポーネント
カスタムからの属性

マッピングは次のように実行されます。

簡易マッピング: ある着信属性をユーザー・レコード属性と照合
複雑なLDAP問合せ: 着信データのプレースホルダを含むLDAP問合せ(例: (&(sn=%lastname%)(mail=%email%)))
SAMLトークンの名前IDマッピング表

図45-7に、「新規検証テンプレート」ページのデフォルトの一般詳細を示します。

図45-7 「新規検証テンプレート」ページ: 「一般」ページのデフォルト

「図45-7 「新規検証テンプレート」ページ: 「一般」ページのデフォルト」の説明

表45-9に、「新規検証テンプレート」の「一般」ページの要素を示します。

表45-9 新規検証テンプレート: 一般詳細

要素	説明
戻る	前のページに戻るには、このボタンをクリックします。
次	次のページに進むには、このボタンをクリックします。
取消	ページを閉じるには、このボタンをクリックします。
検証テンプレート名	このテンプレート用に選択する名前。次に例を示します。 `email-wstrust-valid-temp`
説明	オプション。
トークン・プロトコル	作成される検証テンプレートのタイプ。タイプは次のいずれかになります。 WS-Trust: このテンプレートは、WS-TrustリクエストのOnBehalfOf要素に含まれるトークンを検証およびマップするために使用されます。 WS-Security: このテンプレートは、着信メッセージのSecurity SOAPヘッダーにあるトークンを検証およびマップするために使用されます。
トークン・タイプ	このテンプレートに使用するトークン・タイプを選択するインバウンド・トークン・タイプのリスト。トークン・タイプのオプションはプロトコル・タイプによって異なります。 WS-Trust: SAML 1.1、SAML 2.0、ユーザー名、X.509、Kerberos、OAM、カスタム WS-Security: SAML 1.1、SAML 2.0、ユーザー名、X,509、Kerberos、なし
デフォルト・パートナ・プロファイル	WS-Security検証テンプレートにのみ適用されます。着信リクエストがリクエスタ・パートナにマップされない場合、使用するデフォルトのリクエスタ・パートナ・プロファイルを参照します。たとえば、かわりにリクエストがユーザーにマップされる場合などです。リクエスタ・パートナ・プロファイルには、リクエスト処理中に使用される設定が含まれています。着信リクエストがリクエスタ・パートナにマップされた場合、そのリクエスタのパートナ・プロファイルが取得され、リクエスタ・パートナ・プロファイルとして使用されます。
タイムスタンプの存続期間	ユーザー名およびSAML検証テンプレートにのみ適用されます。トークンの有効性を決定します(ユーザー名トークンの場合は、作成された瞬間を示すCreated要素が含まれている場合のみ)。デフォルト: 1000 (秒)
認証の詳細	ユーザー名トークン検証テンプレートに固有です。
資格証明検証の有効化	ユーザー名トークンに含まれる資格証明を使用して検証を有効にするには、このボックスを選択します。有効にすると、セキュリティ・トークン・サービスでは、指定された検証ソースを使用して、ユーザー名トークンに含まれるusernameおよびpassword要素が検証されます。ノート: ユーザー名トークンのWS-Securityプロファイルに定義されているパスワード・ダイジェストは、このリリースではサポートされていません。関連項目: 表45-10

図45-8に、「資格証明検証の有効化」が選択されている「一般」詳細ページを示します。

選択の結果として、ページの「認証の詳細」セクションにデフォルト値が表示されています。これは、ユーザー名トークン検証に固有です。

図45-8 新規検証テンプレート: 「一般」の「認証の詳細」

「図45-8 新規検証テンプレート: 「一般」の「認証の詳細」」の説明

表45-10に、「資格証明検証の有効化」を選択した場合に使用できる認証関連の詳細を示します。

表45-10 新規検証テンプレート: 認証の詳細

要素	説明
検証ソース	資格証明検証ソースを選択できるリストユーザー名トークンに含まれる資格証明を検証する場合、次に示す4つのタイプの検証ソースがあります。 LDAP: 資格証明の検証にはスタンドアロンLDAPサーバーが使用されます。接続情報を入力する必要があります。組込みLDAP: 資格証明の検証には、WebLogicサーバーに組み込まれたLDAPサーバーが使用されます。情報を入力する必要はありません。 UserStore: 資格証明の検証には、「共通構成」->「データ・ソース」で構成されているデフォルトのユーザー・アイデンティティ・ストアが使用されます。この検証テンプレート画面で情報を入力する必要はありません。パートナ: 資格証明は、「リクエスタ・パートナ」エントリに入力されたユーザー名/パスワード情報に対して検証されます。ノート: 選択した場合、「トークン・マッピング」構成セクションが無効になります。これは、資格証明の検証操作後にトークンがリクエスタ・パートナにマップされているためです。
LDAP URL	LDAPサーバーのURL。
管理者ユーザー	LDAPサーバーの参照に使用されるアカウントのユーザー名。
管理者パスワード	LDAPサーバーの参照に使用されるアカウントのパスワード。
ベースDN	ユーザー・レコードの参照時に使用される基本検索DN。
HAの有効化	LDAPサーバーがHAモードで、前にロード・バランサがあるかどうかを示します。
個人オブジェクト・クラス	ユーザー・レコードに関連付けられた個人オブジェクト・クラス。
一意のID	ユーザーの一意の識別子データを含むユーザー・レコードの属性。ほとんどの場合、「資格証明ID」フィールドと同じです。
資格証明ID	ユーザー名データを含むユーザー・レコードの属性。このフィールドは、ユーザー名に基づいてユーザー・レコードを参照するために使用されます。
最大接続数	開いている同時LDAP接続の最大数。デフォルト: 50
接続待機タイムアウト	新しい接続を開くときに待機する最大時間。デフォルト: 5000 (秒)
接続の非アクティブのタイムアウト	LDAP接続を閉じるまでの非アクティブの最大時間。デフォルト: 5000 (秒)
接続の読込みのタイムアウト	開いている同時LDAP接続の最大数。デフォルト: 5000 (秒)

トークン・マッピング

「トークン・マッピング」セクションは次の内容を示します。

着信トークンをマップする必要があるかどうか。
着信トークンをマップする必要があるかどうか、実行されるマッピングの種類。たとえば、ユーザーへのトークンのマッピング、パートナへのトークンのマッピングなどです。
マッピングの実行方法。たとえば、パートナ/ユーザー属性へのトークン属性のマッピング、複数のトークン属性を含むLDAP問合せの使用などです。

マッピング・ルールは、着信データをユーザーまたはパートナにマップする方法を決定します。着信トークンの次のデータが使用されます。

UNTのユーザー名
KerberosのユーザーID
SAMLの名前IDおよび属性
X.509のDNコンポーネント
カスタムからの属性

マッピングは次のものを使用して実行されます。

簡易マッピング: ある着信属性をユーザー・レコード属性と照合
複雑なLDAP問合せ: 着信データのプレースホルダを含むLDAP問合せ。例: (&(sn=%lastname%)(mail=%email%))
SAMLの名前IDマッピング表

新しい検証テンプレートのトークン・マッピングの例を次に示します。

図45-9に、マッピング構成設定を示します。

この設定は、次の名前IDフォーマットに基づいて、一致する属性を持つユーザー・レコードと名前ID値を照合することでユーザー・レコードにトークンをマップするために、セキュリティ・トークン・サービスに必要です。

「トークンの宛先ユーザーのマップ」の有効化
簡易ユーザー・マッピングの有効化
属性ベース・ユーザー・マッピングの無効化

図45-9 トークン・マッピング: SAML2 WS-Security検証テンプレート

「図45-9 トークン・マッピング: SAML2 WS-Security検証テンプレート」の説明

図45-10に、マッピング構成設定を示します。

この設定は、一致するuidを持つユーザー・レコードとユーザー名トークンのusername要素を照合することでユーザー・レコードにトークンをマップするために、セキュリティ・トークン・サービスに必要です。

必要な設定は次のとおりです。

「トークンの宛先ユーザーのマップ」の有効化
簡易ユーザー・マッピングの有効化
データストア属性: 「uid」に設定
属性ベース・ユーザー・マッピングの無効化

図45-10 トークン・マッピング: username-wstrust-validation-template

「図45-10 トークン・マッピング: username-wstrust-validation-template」の説明

図45-11に、マッピング構成設定を示します。

この設定は、SSLクライアント証明書DN識別属性が一致するリクエスタ・パートナと証明書のサブジェクトDNを照合することでリクエスタ・パートナ・エントリにトークンをマップするために、セキュリティ・トークン・サービスに必要です。

必要な設定は次のとおりです。

トークンの宛先パートナのマップ
簡易ユーザー・マッピングの無効化
属性ベース・ユーザー・マッピングの無効化
簡易パートナ・マッピングの有効化

図45-11 トークン・マッピング: x509-wss-validation-template

「図45-11 トークン・マッピング: x509-wss-validation-template」の説明

すべての要素がすべてのトークン・タイプおよびトークン・プロトコルに適用されるわけではありません。定義する必要がある要素は異なります。

表45-11に、検証テンプレートのトークン・マッピング要素を示します。

表45-11 新規検証テンプレート: トークン・マッピング

要素	説明
トークンのマップ先	WS-Security検証テンプレート: 「トークンのマップ先」リスト <empty>: トークン・マッピング操作は行われませんトークンの宛先パートナのマップ: トークンはリクエスタ・パートナにマップされますトークンの宛先ユーザーのマップとバインディング・データの宛先パートナのマップ: トークンはユーザーにマップされ、バインディング・データ(SSLクライアント証明書DN、HTTP Basic認証ユーザー名など)を使用して、HTTPリクエストがリクエスタ・パートナにマップされます。トークンの宛先ユーザーのマップ: トークンはユーザーにマップされます。 - - - - - - - - - - WS-Trust検証テンプレート: トークンの宛先ユーザーのマップ有効にする場合はボックスを選択します(無効にする場合はチェックボックスをクリアします)。
簡易ユーザー・マッピングの有効化	簡易ユーザー・マッピングでは、単一のトークン属性を使用して、単一のユーザー・レコード属性と照合することで、着信トークンをユーザー・レコードにマップします。 WS-Security検証テンプレート: ユーザー名、SAMLアサーション、KerberosおよびX.509のみ。 WS-Trust検証テンプレート: ユーザー名、SAMLアサーション、Kerberos、X.509、OAMおよびカスタム・トークン。この検証テンプレートのトークン・タイプによって、レイアウトは異なります。ユーザー名トークン: データストア属性は、ユーザー名トークンのusername要素と照合されるユーザー・レコード属性を参照します。 SAMLアサーション: ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。値は、名前ID値のSTS_SUBJECT_ID、またはアサーションのAttributeStatementに含まれる属性の名前になります。 SAML検証テンプレートの「トークン・マッピング」セクションで、「ユーザー・トークン属性」は、ドロップダウンから選択する「名前ID」か、テキスト・フィールドに入力するSAML属性名のいずれかになります。データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。 SAML検証テンプレートの「トークン・マッピング」セクションの「データストア属性」は、LDAPの一致問合せに使用されるディレクトリ属性の名前です。 Kerberos: ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。「ユーザー・トークン属性」を指定するには、事前に移入された属性(「Kerberosプリンシパル」、「Kerberosプリンシパル・プライマリ」または「Kerberosプリンシパル・ドメインなし」)の1つを選択するか、特定の値を入力します。データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。 X.509: ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。「ユーザー・トークン属性」を指定するには、事前に移入された属性(「サブジェクトDN」、「共通名」、「国名」、「都道府県名」、「地方名」、「組織名」、「組織単位名」または「ドメイン・コンポーネント」)のいずれかを選択するか、特定の値(###を大文字のX.500コンポーネント名に置換することでSTS_X509_###に設定可能、たとえば、STS_X509_CNは証明書サブジェクトの共通名コンポーネントを参照)を入力します。データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。 OAM: データストア属性は、ユーザー名トークンのusername要素と照合されるユーザー・レコード属性を参照します。デフォルトの「ユーザー・アイデンティティ・ストア」に定義されているユーザーID属性であることが必要です。カスタム: ユーザー・トークン属性は、ユーザー・レコードの(次に定義する)データストア属性に対応する着信トークンから属性を参照します。使用可能な値は、カスタム・トークン検証モジュールによって返される属性の名前です。データストア属性は、前に参照したユーザー・トークン属性と照合されるユーザー・レコード属性を参照します。
ユーザー名識別子マッピングの有効化	有効な場合、次のものを定義します。 WSSおよびWS-Trust検証テンプレートには、「名前識別子」マッピング設定の同じセクションが含まれます。名前IDユーザー・マッピング操作では、名前IDフォーマットに基づいて名前ID値を単一のユーザー・レコード属性にマップすることで、着信SAMLアサーションをユーザーにマップします。有効な場合、セキュリティ・トークン・サービスでは名前IDフォーマットが評価され、ユーザー・レコード属性が照合される「名前識別子」マッピング表に基づいて、名前ID値がアサーションに含まれます。「名前識別子」マッピング表は、マッピング操作に使用されるユーザー・レコード属性を保持します。標準の名前IDフォーマットを含みますが、カスタム名前IDフォーマットを定義してカスタマイズすることもできます。カスタム名前IDフォーマットを追加するには、「名前識別子」マッピング表の追加ボタンをクリックし、カスタムURIを入力します。マッピング操作に使用される特定の名前IDフォーマットの属性を設定するには、そのフォーマットの行でユーザー・レコード属性を設定します。
属性ベース・ユーザー・マッピングの有効化	WSS検証テンプレート: ユーザー名、SAMLアサーション、KerberosおよびX.509のみ。 WS-Trust検証テンプレート: ユーザー名、SAMLアサーション、Kerberos、X.509およびカスタム・トークンのみ。属性ベース・ユーザー・マッピング操作では、LDAP問合せおよびトークン属性を使用することで、着信トークンをユーザー・レコードにマップします。LDAP問合せのフォーマットによりマッピング・ルールが定義され、使用するトークン属性が、パーセント(%)文字で囲まれた名前によって指定されます。たとえば、2つのトークン属性(firstnameおよびlastname)に基づいてトークンをマップするLDAP問合せは、(&(sn=%lastname)(givenname=%firstname%))のようになります。使用可能なトークン属性は、トークン・タイプによって異なります。ユーザー名トークン STS_SUBJECT_IDは、ユーザー名トークンのusername要素を含む使用可能な唯一のトークン属性です。 SAMLアサーション STS_SUBJECT_IDには名前ID値が含まれます。 STS_NAMEID_FORMATには名前IDフォーマットが含まれます。 STS_NAMEID_QUALIFIERには名前ID修飾子が含まれます。 STS_SAML_ASSERTION_ISSUERにはアサーションの発行者が含まれます。アサーションのAttributeStatementに含まれる属性 Kerberos STS_KERBEROS_PRINCIPAL_SHORTには「Kerberosプリンシパル」属性が含まれます。 STS_KERBEROS_PRINCIPAL_FULLには「Kerberosプリンシパル・プライマリ」属性が含まれます。 STS_KERBEROS_PRINCIPAL_NODOMAINには「Kerberosプリンシパル・ドメインなし」属性が含まれます。 X.509 STS_SUBJECT_IDには「サブジェクトDN」が含まれます。 STS_X509_CNには「共通名」が含まれます。 STS_X509_Cには「国名」が含まれます。 STS_X509_STには「都道府県名」が含まれます。 STS_X509_Lには「地方名」が含まれます。 STS_X509_Oには「組織名」が含まれます。 STS_X509_OUには「組織単位名」が含まれます。 STS_X509_DCには「ドメイン・コンポーネント」が含まれます。カスタム・トークン使用可能な値は、カスタム・トークン検証モジュールによって返される属性の名前です。
簡易パートナ・マッピングの有効化	WSS検証テンプレートおよび次のトークン・タイプの場合のみ: ユーザー名、SAMLアサーション、KerberosおよびX.509。簡易パートナ・マッピング操作では、単一のトークン属性を使用して、パートナ識別属性と照合することで、着信トークンをパートナ・リクエスタにマップします。この検証テンプレートのトークン・タイプによって、レイアウトは異なります。ユーザー名トークンパートナ・データストア属性は、ユーザー名トークンのusername要素と照合されるパートナ識別属性を参照します。 SAMLアサーションパートナ・トークン属性は、リクエスタ・パートナの(次に定義する)パートナ・データストア属性に対応する着信トークンから属性を参照します。値は、名前ID値のSTS_SUBJECT_ID、またはアサーションのAttributeStatementに含まれる属性の名前になります。パートナ・データ属性は、前に参照したパートナ・トークン属性に対して照合されるパートナ識別属性を参照します。 Kerberos パートナ・トークン属性は、リクエスタ・パートナの(次に定義する)パートナ・データストア属性に対応する着信トークンから属性を参照します。「パートナ・トークン属性」を指定するには、事前に移入された属性(「Kerberosプリンシパル」、「Kerberosプリンシパル・プライマリ」または「Kerberosプリンシパル・ドメインなし」)の1つを選択するか、特定の値を入力します。パートナ・データ属性は、前に参照したパートナ・トークン属性に対して照合されるパートナ識別属性を参照します。 X.509 パートナ・トークン属性は、リクエスタ・パートナの(次に定義する)パートナ・データストア属性に対応する着信トークンから属性を参照します。「パートナ・トークン属性」を指定するには、事前に移入された属性(「サブジェクトDN」、「共通名」、「国名」、「都道府県名」、「地方名」、「組織名」、「組織単位名」または「ドメイン・コンポーネント」)のいずれかを選択するか、特定の値(###を大文字のX.500コンポーネント名に置換することでSTS_X509_###に設定可能、たとえば、STS_X509_CNは証明書サブジェクトの共通名コンポーネントを参照)を入力します。パートナ・データ属性は、前に参照したパートナ・トークン属性に対して照合されるパートナ識別属性を参照します。
パートナ名識別子マッピングの有効化	有効な場合、WSS検証テンプレートおよびSAMLトークン・タイプについてのみ次のものを定義します。名前IDユーザー・マッピング操作では、名前IDフォーマットに基づいて名前ID値を単一のリクエスタ・パートナ識別属性にマップすることで、着信SAMLアサーションをユーザーにマップします。有効な場合、セキュリティ・トークン・サービスでは名前IDフォーマットが評価され、パートナ識別属性が照合される「名前識別子」マッピング表に基づいて、名前ID値がアサーションに含まれます。「名前識別子」マッピング表は、マッピング操作に使用されるリクエスタ・パートナ識別属性を保持します。標準の名前IDフォーマットを含みますが、カスタム名前IDフォーマットを定義してカスタマイズすることもできます。カスタム名前IDフォーマットを追加するには、「名前識別子」マッピング表の追加ボタンをクリックし、カスタムURIを入力します。マッピング操作に使用される特定の名前IDフォーマットの属性を設定するには、そのフォーマットの行でリクエスタ・パートナ識別属性を設定します。

45.4.2 トークン検証テンプレートの管理

有効な管理者の資格証明を持つユーザーは、トークン検証テンプレートを追加、検索、編集または削除できます。

これはサーバー側の構成です。デフォルトの「トークン検証テンプレート」が存在します。不要なステップはスキップしてください。セキュリティ・トークン・サービス・エンドポイントを、次のものを示すWSセキュリティ検証テンプレートにリンクする必要があります。

Webservice Securityヘッダー内のトークンを検証する方法
トークンおよびバインディング・データをリクエスタにマップする方法

ここに示す情報は、次のものを検証するときに適用できます。

SOAPヘッダーに含まれる、次のタイプのWS-Securityトークン: ユーザー名、SAML 1.1、SAML 2.0、X.509およびKerberos。
WS-TrustリクエストのOnBehalfOf要素またはValidateTarget要素に含まれる、次のタイプのWS-Trustトークン: ユーザー名、SAML 1.1、SAML 2.0、X.509、Kerberos、OAMセッション伝播トークンおよびカスタム・トークン。

次の手順では、次の特定のパラメータを入力するいくつかの例を示します。また、カッコ()内には簡単な解釈も示します。たとえば、名前(ユーザー名トークン): email-wstrust-valid-tempなどです。値は使用する環境によって異なります。