Oracle Web Services Managerを使用した認証の構成

11 Oracle Web Services Managerを使用した認証の構成

OWSMでは、認証のみ、およびメッセージ保護付き認証を提供するセキュリティ・ポリシーを提供します。

現在のリリースで使用可能な認証ポリシーのサマリーは、「Webサービスに使用する事前定義済ポリシーの決定」の「認証のみのポリシー」および「メッセージ保護および認証のポリシー」を参照してください。認証の詳細は、『Oracle Web Services Managerの理解』の認証の概要に関する項を参照してください。

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

11.1 認証の構成の概要

認証とは、ユーザーが表明しているとおりのユーザーであることを検証することを意味します。ユーザーのアイデンティティは、ユーザー名/パスワード、デジタル証明書、標準のSecurity Assertion Markup Language (SAML)トークンまたはKerberosトークンなど、ユーザーによって提示された資格証明に基づいて検証されます。

SAMLおよびKerberosポリシーの両方が、サービス側とクライアント側の両方においていくつかの構成を行う必要があります。ポリシーの加えて、SAMLおよびKerberosには、ログイン・モジュールが関連付けられています。これらのモジュールは、通常、Fusion Middleware Controlを使用して構成され、Webサービスへのアクセスを制御します。

SAMLトークンでは、ポリシーに対して検証するため、ユーザー属性、ユーザー・ロールおよび発行者名を追加できます。これらの属性は、Oracle Platform Security Services (OPSS)によって検証されます。詳細は、「SAMLの構成について」を参照してください。

Kerberosでは、キー配布センター(KDC)をWebサービス・クライアントとWebサービスで使用できるように初期化および構成します。KDCユーザー・レジストリでプリンシパルを作成し、適切なKDCを使用するようにサービスとクライアントを構成します。Kerberosトークンの構成の理解を参照してください。

認証に関連するポリシーのすべてのリストは、「認証のみのポリシー」、「メッセージ保護および認証のポリシー」および「WS-Trustポリシー」を参照してください。

11.2 WebLogic Serverでサポートされる認証プロバイダ

ユーザー名、X.509、Kerberos、SAML、HTTP BASICなど、サポートされるトークン・タイプを使用するポリシーでは、WebLogic ServerにWebLogicデフォルト認証プロバイダなどの認証プロバイダを構成する必要があります。

WebLogic Serverの構成の詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』の認証プロバイダの構成に関する項を参照してください。

現在のリリースで使用可能な認証ポリシーのリストは、「Webサービスに使用する事前定義済ポリシーの決定」の「認証のみのポリシー」および「メッセージ保護および認証のポリシー」を参照してください。

WebLogic Serverセキュリティの詳細は、次のマニュアルを参照してください。

Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)
Oracle WebLogic Server管理コンソール・オンライン・ヘルプ

OWSMポリシーで使用されるトークン・タイプにかかわらず、OWSMで使用するように次のいずれかのWebLogic Server認証プロバイダを構成できます。

WebLogic認証プロバイダ(DefaultAuthenticatorとも呼ばれています)。
Oracle Internet DirectoryオーセンティケータまたはOracle Virtual Directoryオーセンティケータ。
LDAPオーセンティケータまたはOpen LDAPオーセンティケータ。
RDBMS認証プロバイダ

注意:

RDBMS認証プロバイダまたは他の非LDAPベースのプロバイダを使用する場合、OWSMにより生成されるSAMLアサーションに追加されるカスタム属性を指定できないという制限があります。この制限は、LDAPベースのプロバイダには存在しません。

OWSMを使用する場合、SAML、Kerberos、X.509トークンなどの特定のトークン・タイプを処理するためにWebLogic Serverプロバイダを構成する必要はありません。特に、OWSMランタイムでは、次のような他のWebLogic Serverプロバイダを使用しません(下記を含みますが、下記に限定されるわけではありません)。

X509プロバイダ: X509トークン・ベースのOWSMポリシーは、WebLogic Server X509アイデンティティ・アサーション・プロバイダを使用しません。
SAMLプロバイダ: SAMLトークン・ベースのOWSMポリシーは、WebLogic Server SAMLプロバイダを使用しません。
資格証明マッパー・プロバイダ
認可プロバイダ
ロール・マッパー・プロバイダ
証明書パス・プロバイダ
監査プロバイダ

11.3 ダイジェスト認証の構成について

Digest認証は、WebアプリケーションがサーバーにDigest(パスワード、nonceおよびタイムスタンプの暗号ハッシュ)を送ることによって、Webサービスに対して自身を認証する認証メカニズムです。

OWSMでは、username-token認証ポリシーのすべてに対してダイジェスト・ベース認証がサポートされています。

この項には次のトピックが含まれます:

11.3.1 ダイジェスト認証の構成の前提条件

ダイジェスト認証を構成するには、一定の前提条件を満たす必要があります。

Webサービスがデプロイされているホスト・システムは、組込みLDAP認証プロバイダ(デフォルト・オーセンティケータ)で構成されている必要があります。これは、Webサービス・クライアントがダイジェストの形式でパスワードを送信するためです。また、サービス側で認証するため、認証プロバイダはクリアテキスト・パスワード、Nonceおよびタイムスタンプを使用してダイジェストを再作成する必要があります。デフォルト・オーセンティケータは必要なクリア・テキストでパスワードを取得できます。

ダイジェストベースのクライアント・ポリシーには制限がありません。アタッチされるWebサービス・クライアントはすべてのサポートされているプラットフォームから実行できます。

11.3.2 デフォルト・オーセンティケータおよびアイデンティティ・アサータの構成

WebLogic Server管理コンソールで、デフォルトのオーセンティケータおよびデフォルトのアイデンティティ・アサータを構成できます。

WebLogic Server管理コンソールから次の手順を実行して、セキュリティ・レルムにデフォルト・オーセンティケータとデフォルトのアイデンティティ・アサータを構成します。

デフォルト・オーセンティケータのプロバイダ固有のページで「パスワード・ダイジェストの有効化」チェック・ボックスを設定します。詳細は、認証およびアイデンティティ・アサーション・プロバイダの構成を参照してください。
図11-1に示されているように、DefaultIdentityAsserterの共通ページでアクティブ・タイプとしてwsse:PasswordDigestを設定します。詳細は、認証およびアイデンティティ・アサーション・プロバイダの構成を参照してください。

図11-1 アクティブ・タイプとしてのwsee:PasswordDigest

「図11-1 アクティブ・タイプとしてのwsee:PasswordDigest」の説明
WebLogic Serverを再起動します。
ダイジェスト認証を構成した後に作成されたユーザーは、ダイジェスト・ベースのメカニズムを使用して認証できます。

ただし、ダイジェスト認証を構成する前に作成されたユーザーは、ダイジェスト・ベースのメカニズムを使用して認証できません。これはWebLogic Serverセキュリティ・ランタイムがすでに作成されたユーザー用にパスワード・ダイジェスト(クリアテキスト・パスワードではない)をすでに格納しているためです。

ダイジェストではなく、クリアテキスト・パスワードがパスワード・データベースに格納されるように、これらのユーザーを再作成する必要があります。

11.3.3 ポリシーのアタッチとダイジェスト認証の有効化

この項では、ポリシーをアタッチしてダイジェスト認証を有効にする方法について説明します。

ポリシーをアタッチしてダイジェスト認証を有効化するには、次の手順を実行します。

まだ実行していない場合は、ダイジェスト認証をサポートするWebサービス・ポリシーのいずれかのコピーをアタッチします。ポリシーをコピーおよびアタッチする方法の詳細は、Webサービスを管理および保護するためのポリシーのアタッチを参照してください。
ポリシーを開いて、図11-2に示すように、「パスワード・タイプ」ドロップダウン・メニューを「ダイジェスト」に変更します。

図11-2 「パスワード・タイプ」ドロップダウン・メニューからの「ダイジェスト」の選択

「図11-2 「パスワード・タイプ」ドロップダウン・メニューからの「ダイジェスト」の選択」の説明
「必要な作成時間」コントロールを設定します。
「必要なNonce」コントロールを設定します。
ポリシーのクライアント・バージョンに対して手順1から4を繰り返します。

注意:

パスワード・タイプとして「ダイジェスト」を選択し、ポリシーを有効にするために「必要な作成時間」および「必要なNonce」コントロールの両方を設定する必要があります。

11.4 SAMLの構成について

SAML標準は、Web上のソフトウェア・エンティティの間でセキュリティ・アサーションを作成、リクエスト、交換するための共通XMLフレームワークを定義します。

SAMLトークン・プロファイルは、WS-Security標準のコア・セットの一部であり、WebサービスのセキュリティのためにSAMLアサーションを使用する方法が指定されています。SAMLでは、ビジネス・プロセスまたはトランザクションの複数のステップ間で、ブラウザからポータル、Webサービスのネットワークへと渡すことのできるセキュリティ・トークンを表す標準的な方法も提供されます。

事前定義済SAMLポリシーは、名前にsamlが含まれていて、Oracle Web Services Managerの事前定義済ポリシーに一覧表示されています。

注意:

事前定義済SAMLポリシーを編集することはできません。設定または構成プロパティを変更するには、編集するポリシーのクローンを作成するか、ポリシーのアタッチ後に構成オーバーライドを使用して構成プロパティを設定する必要があります。

次のセクションで、SAML構成の詳細を説明しています。

11.4.1 SAMLトークン検証のフローの概要

SAMLログイン・モジュールは、WebサービスにかわってSAMLトークンを検証します。次に、SAMLログイン・モジュールは認証を完了するために、検証されたトークンからユーザー名を抽出し、Oracle Platform Security Services (OPSS)に(間接的に)渡します。

「WebLogic Serverでサポートされる認証プロバイダ」の説明に従って、任意の構成済認証プロバイダを起動できます。

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

11.4.1.1 SAMLアサーションの検証

この項では、SAMLアサーションの検証方法について説明します。

メッセージを保護するために使用されるSAMLアサーションおよびメカニズムのタイプによって、次の手順の1つ以上を使用してSAMLアサーションを検証します。

SAMLアサーションの署名を検証します。
1. SAMLアサーションの署名に含まれるか参照される署名証明書を取得します。
2. 証明書が、キー・ストアにある証明書チェーンによって信頼されていることを検証します。
3. 署名証明書の公開鍵でSAMLアサーション署名を検証します。
SAMLアサーション条件を検証します。
- Not beforeおよびnot after。
- SAML対象ユーザー制限。
SAMLアサーション発行者の信頼を検証します。
1. 発行者が信頼できるかどうかを検証します。
2. 署名証明書のDNが信頼できるものであるかどうかを検証します。
3. トークン属性ルール。
SAMLアサーションでユーザーを認証します。

注意:

通常、メッセージ全体が署名され、暗号化されます。たとえば、oracle/wss10_saml_token_with_message_protection_client_policyを考えてみます。デフォルトで、このポリシーを使用する場合は、メッセージ全体が署名され、暗号化されます。ただし、「Fusion Middleware Controlを使用した部分的な暗号化の構成について」で説明しているように、アサーション・テンプレートでは、メッセージ本文の完全な署名および暗号化のみでなく、部分的な署名および暗号化もサポートされています。

メッセージ本文の一部を署名または暗号化しない場合は、SAMLトークンのみが署名されます。

oracle/wss10_saml_token_with_message_protection_client_policyポリシーの前の例では、SAML送信者保証の場合は、SAMLトークンがクライアントのプライベート証明書によって署名されます。

11.4.1.2 SAMLトークン検証のユースケース

この項は、SAMLトークンが様々な用例で検証される方法を説明します。

表11-1は、様々なSAMLタイプとセキュリティ・メカニズムの異なる組合せと、それぞれの場合にSAMLアサーションがどのように検証されるかを示しています。

表11-1 SAMLトークンの検証

ユースケース	説明	検証方法
SAML送信者保証とメッセージ保護。	メッセージ保護のSAML送信者保証は署名されていますが、この場合は、メッセージ本文とSAMLトークンが、クライアントのプライベート証明書の1つの署名によって一緒に署名されています。	手順: 1-4
SAML送信者保証と双方向SSL。例: oracle/wss_saml20_token_over_ssl_service_policy	メッセージはSSLのみによって保護されます。 SAMLトークンはクライアントのプライベート証明書によって署名されます。	手順: 1b。クライアントのSSL証明書が信頼されていることを検証します。 2, 3, 4
SAML送信者保証と保護なし。例: oracle/wss10_saml20_token_service_policy	このポリシーはセキュアではなく、デモの目的でのみ提供されています。SAML発行者の名前は存在しますが、SAMLトークンは署名されません。 SAML 2.0トークンの資格証明は、SAML 2.0ログイン・モジュールに対して認証されます。	手順: 2、3a、4
SAML Bearerトークンと一方向SSL。例: oracle/wss_saml20_token_bearer_over_ssl_service_policy	SAMLベアラーの場合、SAMLトークンが署名され、署名はSAMLトークン内に存在します。これは本文が署名されているかどうかとは無関係です。	手順: 1、2、3、4
SAML未署名トークン・ベアラーと一方向SSL。(デフォルトでは無効ですが、下位互換性のために有効にできます。)	SAMLトークンは署名されません。	手順: 2、3、4
SAML鍵所有者とメッセージ保護。本体全体がHOKによって署名されています。	SAMLトークンが署名され、署名はSAMLトークン内に存在します。本体もHOKによって署名されます。	手順: 1、2、3、4 追加手順5。署名を鍵で検証することにより、送信者が秘密鍵を所有していることを検証します。
SAML鍵所有者とタイムスタンプの署名のみ。メッセージ本文は署名されていません。	SAMLトークンが署名され、署名はSAMLトークン内に存在します。タイムスタンプもHOKによって署名されます。	手順: 1、2、3、4 追加手順5。署名を鍵で検証することにより、送信者が秘密鍵を所有していることを検証します。

11.4.2 設計時のSAML Webサービス・クライアントの構成

SAMLアサーションのユーザー名を構成する必要があります。

設計時にSAML Webサービス・クライアントを構成するには、この項で説明する手順を実行します。(デプロイ時にWebサービス・クライアントにSAMLポリシーをアタッチする場合、これらのプロパティは構成が不要で、Fusion Middleware Controlに表示されることもありません。)

これ以降の項で説明するように、ユーザー・ロールをアサーションに含め、SAMLアサーション発行者名を変更することもできます。

SAMLアサーションのユーザー名を構成するには:

JSEクライアント・アプリケーションの場合、次のようにユーザー名をBindingProviderプロパティとして構成します。

Map<String,Object>  reqContext = ((BindingProvider) proxy).getRequestContext()   reqContext.put( BindingProvider.USERNAME_PROPERTY, "jdoe")

ここで、proxyは、実際のWebサービスの起動に使用されるWebサービス・プロキシを示します。

Java EEクライアントの場合は、ユーザーが認証済で、サブジェクトがコンテナ内で確立されていれば、ユーザー名はサブジェクトから自動的に取得されるため、追加の構成は必要ありません。

たとえば、ユーザーjdoeがすでにJava EEアプリケーションに対して認証され、Java EEアプリケーションからWebサービス・コールを行う場合、ユーザー名jdoeは自動的に伝播されます。

ただし、ユーザーが認証されていない場合、JSEと同様にBindingProviderにユーザー名を構成する必要があります。

11.4.3 アサーションへのユーザー属性の組込み

構成プロパティを使用してSAMLアサーションにユーザー属性を追加できます。

SAMLクライアント・ポリシーには、SAMLアサーションにユーザー属性を追加するために使用できるuser.attributes構成プロパティが含まれます。

このために、含める属性をカンマ区切りリストとして指定します。たとえば、attrib1,attrib2のようにします。指定する属性名は、構成済アイデンティティ・ストア内の有効な属性に正確に一致する必要があります。

user.attributesは、サブジェクトが有効であり、subject.precedence構成プロパティがtrueに設定されている必要があります。(subject.precedenceがtrueである場合、SAMLアサーションを作成するためのユーザー名はサブジェクトのみから取得されます。)

OWSMランタイムは、構成済アイデンティティ・ストアからこうした属性の値を読み取り、属性とその値をSAMLアサーションに含めます。

user.attributes構成プロパティは、1つのアイデンティティ・ストアに対してサポートされ、デフォルトではリスト内の最初のアイデンティティ・ストアのみが使用されます。そのため、ユーザーは、構成済WebLogic Serverの認証プロバイダで使用されるアイデンティティ・ストアに存在し、有効になっている必要があります。認証プロバイダは、「WebLogic Serverでサポートされる認証プロバイダ」で説明されています。

複数のアイデンティティ・ストアを構成しており、すべてのアイデンティティ・ストアでユーザーを検索する場合は、すべての構成済アイデンティティ・ストアで検索を有効にするために、次の手順に従います。

「ターゲット・ナビゲーション」ペインで、「WebLogicドメイン」を開いて、アイデンティティ・ストア・プロバイダを構成するために必要なドメインを表示します。ドメインを選択します。
「WebLogicドメイン」メニューから「セキュリティ」→「セキュリティ・プロバイダ構成」を選択します。
ページの「アイデンティティ・ストア・プロバイダ」セクションで、「構成」をクリックしてアイデンティティ・ストアを操作するパラメータを構成します。

図11-3に示すように、「アイデンティティ・ストア構成」ページが表示されます。

図11-3 「アイデンティティ・ストア構成」ページ

「図11-3 「アイデンティティ・ストア構成」ページ」の説明
「追加」をクリックしてカスタム・プロパティを追加します。

「新規プロパティの追加」ウィンドウが表示されます。
図11-4に示すように、値「true」のプロパティ「virtualize」を追加します。

図11-4 virtualizeプロパティの追加

「図11-4 virtualizeプロパティの追加」の説明
「OK」をクリックして変更内容を送信します。
「アイデンティティ・ストア構成」ページで「OK」をクリックします。
サーバーを再起動します。

11.4.4 アサーションへのユーザー・ロールの組込み

ユーザーのロールをSAMLアサーションの属性文として渡すことができます

SAMLアサーションの属性文としてユーザーのロールを渡すには、デプロイ後にuser.role.includeプロパティにtrueを構成します。このポリシーのデフォルト値は「false」です。

設計時にユーザーのロールを構成するには、BindingProviderのuser.role.includeプロパティをtrueに設定します。

11.4.5 SAMLポリシーに関するOracle Platform Security Services (OPSS)の構成の理解

事前定義済SAMLポリシーに関してOPSSを構成する必要があります。

事前定義済SAMLポリシーに関してOPSSを構成するには、次の手順に従います。

「Fusion Middleware Controlを使用したSAMLおよびSAML2ログイン・モジュールの構成」の説明に従って、SAMLログイン・モジュールを構成します。

デフォルトでは、SAMLアサーション発行者名はwww.oracle.comです。Webサービス・クライアント側とWebサービス側の両方で事前定義済SAMLポリシー(またはアサーション)が使用されている場合は、saml.issuer.nameクライアント・プロパティはwww.oracle.comであることが必要です。このため、通常はデフォルト値を使用でき、発行者の構成は不要です。

発行者の追加の詳細は、「別のSAMLアサーション発行者名の追加」を参照してください。
WebLogic Server管理コンソールで認証プロバイダを構成します。
SAML鍵所有者ポリシーなど、SAMLアサーションに関連する署名が含まれるポリシー(アサーションから参照される鍵がメッセージの署名に使用される)、または送信者保証ポリシー(送信者の鍵がメッセージの署名に使用される)を使用する場合、「メッセージ保護に関するキーストアの構成の概要」の説明に従って、署名と検証のための鍵と証明書を構成する必要があります。
SSLが必要なポリシーを使用する場合、「SSLに関するキーストアの構成について」の説明に従ってSSLを構成する必要があります。

11.4.6 別のSAMLアサーション発行者名の追加

信頼できる発行者のリストに発行者を追加する必要がある3つのシナリオがあります。

Webサービス・クライアント側とWebサービス側の両方で事前定義済SAMLポリシー(またはアサーション)が使用されている場合は、SAML発行者名はwww.oracle.comとして指定されます。このため、通常はデフォルト値を使用でき、発行者の構成は不要です。

SAML事前定義済Webサービス・ポリシーまたはアサーションのsaml.trusted.issuers構成オーバーライド・プロパティを使用して信頼できる発行者を指定した場合。ここで定義される信頼できる発行者は、アプリケーション・レベルに適用され、ドメイン・レベルで定義される信頼できる発行者をオーバーライドします。
SAML事前定義済Webサービス・クライアント・ポリシーまたはアサーションのsaml.issuer.name構成プロパティを使用してSAML発行者を指定した場合。
別のクライアント、たとえば.NET/STSが事前定義済SAMLポリシーによって保護されたWebサービスと通信する場合。

SAML発行者を追加する方法として、次の項の説明に従って、ドメイン・レベルの構成を使用することをお薦めします。

Fusion Middleware Controlを使用した信頼できるSAML発行者およびDNリスト
WLSTセクションへのリンク

前述の説明に従って発行者を追加する場合は、ドメイン内のすべてのサービスに適用されることと、サーバーの再起動が必要ではないことに注意してください。

後方互換性のために、セキュリティ・プロバイダのSAMLまたはSAML2ログイン・モジュールを構成することによって、Fusion Middleware Controlで発行者を追加することもできますが、望ましい方法はドメイン・レベルの構成を使用することです。SAMLログイン・モジュールでSAML発行者を定義しない場合、発行者はjps-config.xml内で永続化されます。また、変更を有効化するにはドメインのサーバーを再起動する必要があります。

注意:

OWSMでは、次の階層を使用して、実行時に使用される信頼できる発行者を決定します。

最初に、ポリシーに対して構成された信頼できる発行者のリストがチェックおよび使用されます。これにより、ドメイン・レベルで信頼できる発行者がオーバーライドされます。
信頼できる発行者がポリシー・レベルで定義されていない場合は、ドメイン・レベルの構成がチェックおよび使用されます。
最後に、信頼できる発行者がポリシー・レベルかドメイン・レベルで定義されていない場合、SAMLログイン・モジュールで定義される発行者リストがチェックおよび使用されます。

別のSAMLアサーション発行者をSAMLログイン・モジュール内の「発行者」リストに追加するには:

ターゲット・ナビゲーション・ペインで「WebLogicドメイン」を開き、発行者の追加が必要なドメインを表示します。ドメインを選択します。
コンテンツ・ペインで、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」を選択します。
「ログイン・モジュール」セクションで、必要に応じてSAMLまたはSAML2ログイン・モジュールを選択して、「編集」をクリックします。

「ログイン・モジュールの編集」ページが表示されます。
ページの「SAML固有の属性」セクションで「追加」をクリックします。
「発行者の追加」ウィンドウの「発行者」フィールドに発行者名を入力して、「OK」をクリックします。
サーバーを再起動します。
クライアント・ポリシーの発行者を次のように構成します。
- デプロイ後、アタッチされたSAMLクライアント・ポリシーのsaml.issuer.nameプロパティの構成オーバーライド値を指定します。事前定義済Oracle SAMLクライアント・ポリシーのクローンを作成した場合、ポリシーをアタッチする前に、saml.issuer.name構成プロパティの値を設定できます。
- 設計時に、BindingProviderのsaml.issuer.nameプロパティを設定します。

11.4.7 アイデンティティ切替えのためのSAML Webサービス・クライアントの構成について

アイデンティティ切替えとは、ポリシーが、認証されたサブジェクトに基づいたアイデンティティとは異なるアイデンティティを伝播することを意味します。

OWSMには、アイデンティティ切替えを有効にするwss11_saml_token_identity_switch_with_message_protection_client_policyポリシーが含まれます。アイデンティティ切替えとは、ポリシーが、認証されたサブジェクトに基づいたアイデンティティとは異なるアイデンティティを伝播することを意味します。アイデンティティ切替えの詳細は、次のトピックを参照してください。

11.4.7.1 アイデンティティ切替えのユースケース・シナリオの理解

SOAアプリケーションではクライアント側のWebサービス・ポリシーで使用されるユーザー・アイデンティティを指定する必要があり、アウトバウンドWebサービス・リクエストでSAMLトークンに関連するユーザーに動的に切り替えるシナリオが考えられます。このポリシーにより、サブジェクトから取得したユーザー名を使用するかわりに、SAML Webサービス・リクエストの送信時に新しいユーザー名を設定できます。

wss11_saml_token_identity_switch_with_message_protection_client_policyポリシーは、プロパティjavax.xml.ws.security.auth.usernameを介してユーザーIDセットに基づいてSAMLトークンを作成します。

Webサービス・クライアントがSOAアプリケーションを呼び出し、SOAアプリケーションがWebサービスのクライアントとなる次のようなユースケースについて検討します。

client -> SOA -> web service

このユースケースでは、次のようになります。

クライアントは、wss11_username_with_message_protection_client_policy policyポリシーにより保護されます。そして、ユーザーend_user1としてSOAエントリ・ポイントと通信します。
SOAエントリ・ポイントは、wss11_username_with_message_protection_service_policyによって保護されます。SOAアプリケーションはエンド・ユーザーを認証し、end_user1に基づいてサブジェクトを確立します。ただし、外部Webサービスには別のアイデンティティを伝播することが求められます。

そのため、アイデンティティ切替えを行うために、wss11_saml_identity_switch_message_protection_client_policyポリシーをSOA参照のバインディング・コンポーネントにアタッチします。
伝播されるユーザー名は、SOAアプリケーションのコンポーネントであるBPELプロセスによって動的に決定されます。ユーザー名は、動的に決定されたユーザー名の値を含むBPELプロパティjavax.xml.ws.security.auth.usernameとして設定されます。外部Webサービスは、wss11_saml_with_message_protection_service_policyによって保護できます。この場合は、end_user1ではなく切り替えられたユーザーを受信します。
エンド・ユーザーに基づいてサブジェクトを確立するが、別のアイデンティティを伝播する必要があるJava EEアプリケーションにも、同様のシナリオが適用できます(このシナリオのSOAをJava EEアプリケーションに置き換えます)。Java EEの場合は、次のようにユーザー名をプログラムによって設定できます。
```
((BindingProvider) port).getRequestContext().put(BindingProvider.USERNAME_PROPERTY, config.get(USERNAME));
```
Fusion Middleware Controlを使用して、WSIdentityPermission権限をSOA参照バインディング・コンポーネントに追加します。

wss11_saml_token_identity_switch_with_message_protection_client_policyポリシーでは、このポリシーをアタッチするアプリケーションがWSIdentityPermission権限を持つことが要求されます。つまり、OWSMが外部から提供されるアイデンティティをアプリケーションから受け入れるには、そのアプリケーションがWSIdentityPermission権限を持つ必要があります。

これにより、OWSMが潜在的に悪質なアプリケーションからアイデンティティを提供されるのを回避します。

注意:

wss11_saml_token_identity_switch_with_message_protection_client_policyポリシーは、ローカルの最適化を無効にします(同じサーバー上でのSOA間のやり取りについては、「OWSMポリシーでのローカルの最適化の使用(SOAコンポジット)」を参照してください)。

このポリシーは、Webサービスのwss11_saml_token_with_message_protection_service_policyポリシーと互換性があります。

11.4.7.2 javax.xml.ws.security.auth.usernameプロパティの設定

この項では、ユーザー名プロパティを設定するためのSOAおよびBPELプロセスに関する情報を提供します。

SOAの場合:

SOAコンポジットは、1つのSOAサービス・コンポーネントとしてBPELプロセスを持ちます。BPELプロセスは、同期および非同期プロセスのプロセス編成と格納を行います。

BPELプロパティは、正確な名前javax.xml.ws.security.auth.usernameを使用して定義できます。このプロパティの値を、SOAアプリケーションが伝播するアイデンティティにすることができます。これは潜在的にBPELプロセスによって動的に決定できます。

Java EEの場合:

BindingProvider.USERNAME_PROPERTYプロパティを設定します。

11.4.7.3 WSIdentityPermissionを使用した権限の設定

この手順では、SOA参照バインディング・コンポーネントにシステム権限として権限を設定する方法を示しています。

wss11_saml_token_identity_switch_with_message_protection_client_policyポリシーをアタッチするWebサービス・クライアント(たとえば、SOA参照バインディング・コンポーネント)は、oracle.wsm.security.WSIdentityPermission権限を持つ必要があります。

Fusion Middleware Controlを使用して、oracle.wsm.security.WSIdentityPermission権限をSOA参照バインディング・コンポーネントにシステム権限として追加するには、次の手順に従います。

ターゲット・ナビゲーション・ペインで「WebLogicドメイン」を開き、アプリケーションの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「システム・ポリシー」をクリックします。システム・ポリシーは、現在のWebLogicドメインにデプロイされるすべてのアプリケーションに適用されるシステム全体のポリシーです。
「システム・ポリシー」ページで、「権限」フィールドの矢印アイコンを選択し、システム・セキュリティ権限を検索します。
コードベース権限のいずれかを選択して開始点として使用し、「類似作成」をクリックします。
ページの「権限の詳細」セクションで、「コードベース」フィールドにfile:${common.components.home}/modules/oracle.wsm.common_${jrf.version}/wsm-agent-core.jarと入力します。

注意:

権限付与の詳細を定義する場合、ディレクトリまたはJARの名前で製品バージョン番号の使用は避けることをお薦めします。これによって、将来の新しいリリースへのアップグレード時に影響を最小限に抑えることができます。
ページの「権限」セクションで、開始点の権限クラスを選択して「編集」をクリックします。
「権限クラス」フィールドにoracle.wsm.security.WSIdentityPermissionと入力します。リソース名はSOAのコンポジット名で、Java EEクライアントのアプリケーション名です。図11-5に示すように、アクションは常にassertです。

図11-5 WSIdentityPermissionの編集

「図11-5 WSIdentityPermissionの編集」の説明

WLSTを使用してoracle.wsm.security.WSIdentityPermission権限を追加するには、次のコマンドを実行します。

grantPermission(codeBaseURL="file:${common.components.home}/modules/
oracle.wsm.common_${jrf.version}/wsm-agent-core.jar",
     permClass="oracle.wsm.security.WSIdentityPermission",
     permTarget="resource=yourAppName",
     permActions="assert")

コマンドの説明は次のとおりです。

codeBaseURLでは、wsm-agent-core.jarを参照する必要があります。
permTargetの構文は、"resource=yourAppName/compositeName"です。リソース名はSOAのコンポジット名で、Java EEクライアントのアプリケーション名です。
permActionsは常に"assert"です。

11.4.8 SAML署名証明書の信頼できる発行者および信頼できる識別名リストの理解

セキュリティを高めるために、SAML署名証明書の信頼できる識別名(DN)のリストを定義できます。

デフォルトの場合、OWSMでは、受信した発行者名を構成済の発行者のリストと照合してチェックし、SAML署名をOWSMキーストアにある構成済の証明書と照合してチェックします。また、信頼できるDNリストを定義する場合は、SAML署名がその発行者に関連付けられている特定の証明書に基づいて署名されているかどうかが検証されます。

信頼できるDNリストの構成はオプションです。詳細な制御を必要とするユーザーは、これにより各発行者を1つ以上の署名証明書のリストに関連付けることができます。信頼できる発行者のDNリストが定義されていない場合、証明書がOWSMキーストアに存在する証明書によって信頼されているかぎり、その証明書に基づいて署名できます。

SAML署名証明書の信頼できるDNリストの定義の詳細は、「Fusion Middleware Controlを使用した信頼できるSAML発行者およびDNリスト」を参照してください。

11.4.9 SAMLポリシーによる匿名ユーザーの使用方法の理解

1つのポリシーで認証ユーザーおよび匿名ユーザーの両方をサポートできる利便性のために、SAML経由での匿名ユーザーが許可されています。

すべてのSAMLポリシーで、匿名ユーザーの伝播が許可されます。たとえば、認証ユーザーまたは匿名ユーザーのいずれかが操作できるADFアプリケーションが存在し、このADFアプリケーションでWebサービスへのコールを行い、現在のユーザーを伝播する必要がある場合、いずれかのSAMLポリシーを使用して認証ユーザーおよび匿名ユーザーの両方を伝播できます。セキュリティの観点からは、SAML経由での匿名ユーザーの伝播は、サービスに認証トークンを送信しないクライアントと等価です。

1つのポリシーで認証ユーザーおよび匿名ユーザーの両方をサポートできる利便性のために、SAML経由での匿名ユーザーが許可されています。ただし、SAML経由での匿名の伝播は非標準であり、他のベンダーとは相互運用できないことに注意してください。これは、クライアントおよびWebサービスの両方でOWSMを使用している場合にのみ使用してください。

11.5 OWSMによるアイデンティティ・コンテキストの伝播について

アイデンティティ・コンテキストにより、組織は、Oracle Access Managementプラットフォームに組み込まれているコンテキストを意識したポリシー管理および認可機能を使用することで、増大するセキュリティの脅威に対応できます。

この項では、次の項目について説明します。

11.5.1 アイデンティティ・コンテキストの概要

アイデンティティ・コンテキストでは、従来のセキュリティ制御(ロールやグループなど)とともに、認証および認可中に確立される動的データ(認証強度、リスク・レベル、デバイス・トラストなど)を使用することで、リソースへのアクセスのセキュリティが確保されます。

たとえば、アプリケーションでは、次のためにアイデンティティ・コンテキストを使用できます。

ユーザーがスマート・カードなど強力な資格証明を使用して認証されていない場合、特定のビジネス機能を無効化します。
組織が(Identity Federationを使用して)取引しているビジネス・パートナによって提供されたアイデンティティ・データに基づいてトランザクションへのアクセスのセキュリティを確保します。
不正行為で知られる場所からアクセスされていることが検出された場合、追加の認証資格証明を要求します。
管理者の(サードパーティで管理されている)業界認定証が有効期限切れになっている場合、管理権限の範囲を制限します。
不明なデバイスからアクセスされていることが検出された場合、特定のビジネス機能を無効化します。

OWSMは、Webサービス・クライアントからWebサービスにアイデンティティ・コンテキストを伝播した後、認証および認可の目的のために、他のコンポーネントに対して使用可能に(公開)できます。

アイデンティティ・コンテキストは、Webサービス・クライアントおよびWebサービスに対して不透過であり、ポリシーのアイデンティティ・コンテキストの伝播を有効にした後、アイデンティティ・コンテキストのサポートのためにWebサービス・クライアントまたはWebサービスで追加コーディングまたは追加処理を実行する必要はありません。

注意:

アイデンティティ・コンテキストの伝播は、SOA WebCenterおよびJava EE (WebLogic) Webサービス・アプリケーションではサポートされません。

アイデンティティ・コンテキスト、アイデンティティ・コンテキスト・サービスの構成、アイデンティティ・コンテキストAPIの使用に関する詳細は、『Oracle Access Management管理者ガイド』のアイデンティティ・コンテキストの使用tに関する項を参照してください。

11.5.2 SAMLポリシーを使用したアイデンティティ・コンテキストの伝播

OWSMは、SAML 1.1またはSAML 2.0アサーションを使用することにより、Webサービス・クライアントからWebサービスにアイデンティティ・コンテキストを伝播します。

この機能を使用するには、Webサービス・クライアント・ポリシーおよびWebサービス・ポリシーの両方について、propagate.identity.context構成プロパティを使用することにより、アイデンティティ・コンテキストの伝播を明確に有効にする必要があります。つまり、Webサービス・クライアント・ポリシーおよびWebサービス・ポリシーの両方で明確に許可する場合にのみ、OWSMでアイデンティティ・コンテキストを伝播できます。

OWSMは、SAML 1.1またはSAML 2.0アサーションを使用することにより、Webサービス・クライアントからWebサービスにアイデンティティ・コンテキストを伝播します。したがって、SAMLポリシーにのみpropagate.identity.context構成プロパティが含まれます。

アイデンティティ・コンテキストをサポートするOWSMポリシーは、「アイデンティティ・コンテキストでサポートされるOWSMポリシー」にリストされています。

11.5.3 アイデンティティ・コンテキストの伝播の構成: メイン手順

ポリシーの「構成」ページで値を指定するか、ポリシーをアタッチするときにオーバーライドできます。

ここでの説明に従ってポリシーの「構成」ページで propagate.identity.contextに値を指定するか、ポリシーのアタッチ時にこの値をオーバーライドできます。

注意:

ポリシーにこのプロパティを設定する場合は、「アイデンティティ・コンテキストでサポートされるOWSMポリシー」にリストされている必要な事前定義済SAMLポリシーのコピー(クライアントとサーバーの両方)を作成する必要があります。事前定義済ポリシーからの新規ポリシーの作成の詳細は、「Webサービス・ポリシーのクローンの作成」を参照してください。ポリシーを作成したら、それらのポリシーを編集し、この項の説明に従ってpropagate.identity.contextプロパティを設定します。

ポリシーをアタッチするときにpropagate.identity.contextプロパティをオーバーライドする方法の詳細は、「ポリシー構成プロパティのオーバーライド」を参照してください。

デフォルトでは、propagate.identity.context構成プロパティは未設定であり、これはfalseと等価です。アイデンティティ・コンテキストの伝播を使用するには、propagate.identity.contextを明確にtrueに設定する必要があります。

クローンのポリシーを使用してアイデンティティ伝播を構成するには:

「ターゲット・ナビゲーション」ペインで「WebLogicドメイン」を開き、アイデンティティ・コンテキストの伝播の構成が必要なドメインを選択します。
「WebLogicドメイン」メニューから、「Webサービス」→「WSMポリシー」を選択します。
アイデンティティ・コンテキストの伝播を有効にするクローンのSAMLポリシーを選択し、「開く」をクリックします。

Webサービス・クライアントおよびWebサービス・ポリシーの両方についてアイデンティティ・コンテキストの伝播を有効にする必要があることに注意してください。
「アサーション」タブを選択します。
「構成」をクリックします。

「構成」ページには、ポリシーの構成プロパティのリストが表示されます。
propagate.identity.contextプロパティの「値」フィールドにtrueを入力します。
「OK」をクリックします。

図11-6 propagate.identity.contextプロパティをTrueに設定する

「図11-6 propagate.identity.contextプロパティをTrueに設定する」の説明
「保存」をクリックして変更を送信します。
対応するクライアント・ポリシーまたはサービス・ポリシーについて、必要に応じて手順3および8を繰り返します。
Webサービスを管理および保護するためのポリシーのアタッチで説明しているように、ポリシーを目的のエンドポイントにアタッチします。

11.6 Kerberosトークンの構成の理解

この項では、Kerberosトークン構成の概要を説明します。

Kerberos認証プロトコルの詳細は、『Oracle Web Services Managerの理解』のKerberosプロトコルの概要に関する項を参照してください。

事前定義済Kerberosポリシーは、名前にkerberosが含まれていて、Oracle Web Services Managerの事前定義済ポリシーに一覧表示されています。事前定義済Kerberosアサーション・テンプレートは、名前にkerberosが含まれていて、Oracle Web Services Managerの事前定義済アサーション・テンプレートに一覧表示されています。

次の項に記載されている手順に従って、KerberosをWebサービス・クライアントとWebサービスで使用できるように構成します。

11.6.1 MIT Kerberosについて

KDCとしてMIT Kerberosを使用できます。

この項では、KDCとしてMIT Kerberosを使用する場合の次のタスクについて説明します。

11.6.1.1 MIT Kerberos KDCの初期化および起動

この項では、MIT Kerberos KDCを初期化および起動する方法について説明します。

KDCデータベースを初期化します。たとえば、UNIXでは次のコマンドをルートとして実行する場合があります。ここで、example.comはデフォルトのレルムです。

root# /usr/kerberos/sbin/krb5_util -r example.com -s

kerberosサービス・プロセスを起動します。たとえば、UNIXでは次のコマンドをルートとして実行します。

root# /usr/kerberos/sbin/krb5kdc &
root# /usr/kerberos/sbin/kadmind &

11.6.1.2 プリンシパルの作成

KDCユーザー・レジストリに2つのアカウントを作成します。最初のアカウントは、エンド・ユーザー用のもの、つまりWebサービス・クライアント・プリンシパルです。2つ目のアカウントは、Webサービス・プリンシパル用のものです。

KDCユーザー・レジストリに2つのアカウントを作成します。これらのアカウントを作成する方法には、kadmin.localツールを使用する方法があります。このツールは通常、MIT KDCの配布に含まれています。次に例を示します。

>sudo su - # become root
>cd /usr/kerberos/sbin/kadmin.local
>kadmin.local>addprinc fmwadmin -pw password
>kadmin.local> addprinc SOAP/myhost.example.com -randkey
>kadmin.local>listprincs # to see the added principals

この例のWebサービス・プリンシパル名(SOAP/myhost.example.com)は、ランダム・パスワードを使用して作成されています。Webサービス・プリンシパルは、キー表(サービス・プリンシパル名とキーを格納するファイル)を使用して、Kerberosシステムにログインします。ランダム・パスワードを使用することにより、セキュリティが強化されます。

11.6.1.3 正しいKDCを使用するためのWebサービス・クライアントの構成

正しいKDCに対してWebサービス・クライアントを認証するように構成する必要があります。

KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。

この項の例には、サンプルのkrb5.confが示されています。次の点に注意してください。

ファイルは、Kerberosランタイムに対して、操作のレルムと接続先のKDCエンドポイントを通知します。
Kerberosトークン・ポリシーが動作するためには、このファイルのlibdefaultsセクションで、次の3つの追加プロパティが指定されている必要があります。
- default_tkt_enctypes
- default_tgs_enctypes
- permitted_enctypes
暗号スイートの順序は重要であり、クライアント側Kerberosポリシーで使用されているアルゴリズム・スイートに従う必要があります。たとえば、KDC-supported enc-typesがdes3-cbc-sha1、des-cbc-md5、des-cbc-crc、arcfour-hmacである場合、次のポリシーについてクライアントのkrb5.confで次の順序でenc-typesエントリを使用する必要があります。
- wss11_kerberos_with_message_protection_client_policy:
  - default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac
  - default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac
  - permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac
- wss11_kerberos_with_message_protection_basic128_client_policy:
  - default_tkt_enctypes = arcfour-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
  - default_tgs_enctypes = arcfour-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
  - permitted_enctypes = arcfour-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc

次の例は、krb5.confファイルのサンプルを示しています。

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac
default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac
permitted_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc arcfour-hmac
 
[realms]
example.com =
{kdc = someadminserver.com:88  admin_server = someadminserver.com:749   
 
 
default_domain = us.example.com  }
[domain_realm]
us.example.com = example.com
 
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
 
[appdefaults]
pam =
{   debug = false    ticket_lifetime = 36000   renew_lifetime = 36000    
 
 
forwardable = true    krb4_convert = false  }

11.6.2 Microsoft Active Directoryとキー配布センターの併用について

Microsoft Active Directoryをキー配布センター(KDC)とともに使用することもできます。

この項では、Active DirectoryをKerberosとメッセージ保護とともに使用する場合のKDCの構成方法について説明します。

この項では、Active Directoryに習熟していることを前提として説明します。詳細については、Active Directoryのドキュメントを参照してください。

注意:

メッセージ保護のシナリオでKDCとして2008より前のバージョンのMicrosoft Active Directoryを使用する場合、次のポリシーを使用しないでください。

oracle/wss11_kerberos_token_with_message_protection_client_policy
oracle/wss11_kerberos_token_with_message_protection_service_policy

これらのポリシーはTriple DES暗号化を使用しており、これは前のバージョンのMicrosoft Active Directoryではサポートされていません。

かわりに、ポリシー名にbasic128を含むKerberosメッセージ保護ポリシーを使用してください。具体的には次のようになります。

oracle/wss11_kerberos_token_with_message_protection_basic128_client_policy
oracle/wss11_kerberos_token_with_message_protection_basic128_service_policy

これらの2つのポリシーは、Microsoft Active Directoryのサポートされているすべてのバージョンと互換性があります。

この節では、以下のトピックについて説明します。

11.6.2.1 Webサービス・クライアントのセットアップ・タスク

この項では、Webサービス・クライアントをセットアップする方法について説明します。この項で説明するタスクは、次のとおりです。

11.6.2.1.1 ユーザー・アカウントの作成

この項では、ユーザー・アカウントを作成する方法について説明します。

Active Directoryを使用してユーザー・アカウントを新規作成します。DES暗号化は使用しないでください。デフォルトでは、ユーザー・アカウントはRC4-HMACを使用して作成されます。

たとえば、ユーザーtestpolをユーザー・ログオン名test/testpolで作成できます。

ユーザー・ログオン名はgroup/nameの形式にする必要があります。

11.6.2.1.2 サービス・プリンシパル名の設定

この項では、サービス・プリンシパル名を設定する方法について説明します。

setSpnを使用して、サービス・プリンシパル名をユーザーにマッピングします。

setSpn -A test/testpol testpol
setSpn -L testpol (this should display the availabel mapping)

ユーザーにマッピングするサービス・プリンシパル名は1つのみにする必要があります。ユーザーにマッピングされたサービス・プリンシパル名が複数ある場合は、setSpn -D <spname> <username>を使用して削除します。

11.6.2.1.3 Keytabファイルの作成

この項では、キータブ・ファイルの作成方法を説明します。

ktpassを使用してkeytabファイルを作成します。

ktpass -princ test/testpol@{domain} -pass {...}  -mapuser testpol -out
 testpol.keytab -ptype KRB5_NT_PRINCIPAL  -target {domain}

ここで、test/testpolはサービス・プリンシパル名で、ユーザーtestpolにマッピングされています。/desonlyを指定したり、cryptoにdes-cbc-crcは指定しないでください。

11.6.2.2 Webサービスの設定

この項では、Webサービスをセットアップする方法について説明します。

次の手順を実行して、Webサービスを設定します。

KerberosポリシーをWebサービスにアタッチします。
正しいKDCに対してWebサービス・クライアントを認証するように構成します。
KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。

デフォルトのドメインとレルムをkrb5.confまたはkrb5.iniファイルで構成します。RC4-HMAC暗号化タイプを有効にします(JDK6で使用可能)。
```
[libdefaults]
 
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
permitted_enctypes = rc4-hmac
```
「Keytabファイルの作成」で作成したkeytabファイルを、Webサービスのホストとなるシステムにエクスポートします。キー・タブはバイナリ・ファイルです。これをFTPで転送する場合は、バイナリ・モードを使用してください。
次のように、kinitを使用してkeytabファイルを検証します。
```
kinit -k -t <absolute path the the keytab file> <Service Principal Name> 
```
「Kerberosログイン・モジュールの構成」の説明に従って、krb5ログイン・モジュールを変更し、keytabの場所とサービス・プリンシパル名を指定します。
keytabファイルへの絶対パスを使用してください。また、サービス・プリンシパル名には必ず@realmnameを追加してください。次に例を示します。
```
principal value=test/testpol@example.com
```

11.6.3 Webサービス・クライアントでのサービス・プリンシパル名の設定

Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。

この項では、サービス・プリンシパル名を設定する手順について説明します。

「構成」ページでservice.principal.nameの値を指定できます。または、ポリシーをアタッチするときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。デフォルト(プレースホルダ)値は、HOST/localhost@EXAMPLE.COMです。

または、構成のオーバーライドを使用して設計時に次のようにサービス・プリンシパル名を指定できます。

JAX-WS Clients: 
((BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSS_KERBEROS_SERVICE_PRINCIPAL, 
SOAP/myhost.example.com@example.com);

11.6.4 正しいKDCを使用するためのWebサービスの構成

適切なKDCに対してWebサービスを認証するように構成します。

KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。

Webサービス・クライアント用のサンプルのKDC構成は、正しいKDCを使用するためのWebサービス・クライアントの構成の例に示されています。この例は、WebサービスのKDC構成にも適用されます。

11.6.5 Enterprise Managerでの正しいkeytabファイルの使用について

Enterprise Managerで正しいkeytabファイルを使用する必要があります。

正しいkeytabファイルを使用するには、次の作業を行います。

keytabファイルの抽出とインストール
keytabファイルのエクスポート
krb5ログイン・モジュールの変更

これらのタスクについては、次の各項で説明します。

11.6.5.1 Keytabファイルの抽出

この項では、キータブ・ファイルの抽出手順を説明します。

KDCからサービス・プリンシパル・アカウントのキー表ファイル(キー・タブとも呼ばれる)を抽出し、Webサービス実装のホストとなるマシンにインストールする必要があります。

たとえば、kadmin.localなどのツールを使用し、次のようにサービス・プリンシパル名のキー・タブを抽出できます。

>kadmin.local>ktadd -k /tmp/krb5.keytab SOAP/myhost.example.com

11.6.5.2 keytabファイルのエクスポート

この項では、キータブ・ファイルのエクスポート手順を説明します。

keytabファイルを、Webサービスのホストとなるマシンにエクスポートする必要があります。キー・タブはバイナリ・ファイルです。これをFTPで転送する場合は、バイナリ・モードを使用してください。

11.6.5.3 keytabファイルを使用するためのkrb5ログイン・モジュールの変更

この項では、keytabファイルを使用するためにkrb5モジュールを変更する手順について説明します。

「Kerberosログイン・モジュールの構成」の説明に従って、WebサービスのKDCファイルの場所を識別するようにkrb5ログイン・モジュールを変更します。

たとえば、keytabファイルが/scratch/myhome/krb5.keytabにインストールされているとします。キー・タブとプリンシパルのプロパティを次のように変更します。

principal値=SOAP/myhost.example.com@example.com
useKeyTab value=true
storeKey value=true
keyTab値=/scratch/myhome/krb5.keytab
doNotPrompt value=true

11.6.6 サービス・プリンシパルに対応するユーザーの認証

Webサービス・ランタイムでは、Kerberosトークンの妥当性を確認できる必要があります。

トークンが有効の場合、Oracle Platform Security Services (OPSS)は、サービス・プリンシパルに対応するユーザーを、構成済のWebLogic Server認証プロバイダのいずれかに対して認証できる必要があります。認証プロバイダの詳細は、「WebLogic Serverでサポートされる認証プロバイダ」を参照してください。

そのため、ユーザーは、認証プロバイダで使用されるアイデンティティ・ストアに存在し、有効になっている必要があります。

たとえば、SOAP/myhost.example.com@example.comなどのサービス・プリンシパルについて考えます。この例では、SOAP/myhost.example.comという名前のユーザーがアイデンティティ・ストアに存在する必要があります。@domainは、ユーザー・エンティティに含めないでください。

11.6.7 Webサービス・クライアントのチケット・キャッシュの作成

Webサービス・クライアントのチケット・キャッシュを作成できます。

Webサービス・クライアントのチケット・キャッシュを作成するには、次の手順を実行します。

クライアント用に作成したユーザー・プリンシパルを使用して、Kerberosシステムにログインします。
```
>kinit fmwadmin password
```
これにより、チケット認可チケットを含むファイルシステムにチケット・キャッシュが作成されます。このことを確認するには、次のコマンドを入力します。
```
>klist -e
```
次のような情報が表示されます。
```
Credentials cache: /tmp/krb5cc_36687
Default principal: fmwadmin@example.com, 1 entry found.
[1]  Service Principal:  krbtgt/example.com@example.com
     Valid starting:  Sep 28, 2007 17:20
     Expires:         Sep 29, 2007 17:20
         Encryption type: DES3 CBC mode with SHA1-KD
```
暗号化タイプが前述の情報を反映していることを確認します。
Webサービス・クライアントを実行します。

また、最初にKerberosにログインすることなく、Webサービス・クライアントを実行できます。Kerberosユーザー名およびパスワードに対するプロンプトが表示されます。この場合、チケット・キャッシュはファイルシステムに作成されず、メモリーに保持されます。

11.6.8 SSLを介したKerberosの構成

Kerberosの2つの基本的なアサーション・テンプレート、oracle/wss11_kerberos_token_client_templateおよびoracle/wss11_kerberos_token_service_templateは、Kerberosトークンを使用した認証を提供しますが、メッセージ保護のフォームは提供しません。

OWSMでは、Kerberosトークンを使用したBasic認証にSSLトランスポート・レベルのセキュリティを使用してメッセージ保護を追加する次のアサーション・テンプレートを提供します。

これらのアサーション・テンプレートを使用するには、「SSLに関するキーストアの構成について」の説明に従ってSSLを構成する必要があります。

これらのアサーションは、認証とタイムスタンプの署名にKerberosトークンを使用し、基礎となる一方向SSLトランスポートを使用してメッセージを保護します。また、EndorsingSupportingTokenとしてKerberosトークンを通知します。

11.6.9 SPNEGOネゴシエーションによるKerberos構成

SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism)は、クライアントおよびサービスが認証に使用する方法をネゴシエートすることを可能にする標準です。SPNEGOではネゴシエーションを実行するためにHTTPヘッダーを使用するので、Webなどのクロス・プラットフォームのコンテキストで特に役立ちます。

SPNEGOとKerberosの使用方法の詳細は、『Oracle Web Services Managerの理解』のKerberosとSPNEGOに関する項を参照してください。

OWSMは、SPNEGOネゴシエーションを使用して、クライアントおよびサービスで認証用にKerberosを使用できるようにするために、次のアサーション・テンプレートを提供します。

これらのアサーション・テンプレートは、SOAPまたはRESTのエンドポイントにアタッチされたポリシーによって使用できます。

これらのアサーション・テンプレートを使用して、新規ポリシーを作成したり、SPNEGOアサーションを既存のマルチトークン・ポリシーに追加できます。ポリシーの作成またはポリシーへのアサーションの追加の詳細は、次の項を参照してください。

11.6.10 資格証明委任の構成について

Kerberosには、クライアント・リクエストで(クライアントにかわって)あるサービスが別のサービスを使用してリクエストを満たすように要求するシナリオをサポートする資格証明委任と呼ばれる機能が含まれています。このようなシナリオを満たすために、クライアントは、最初のサービスに転送されたTGT(チケット認可チケット)を提供します。最初のサービスはこれを使用して、KDCから2番目のサービスのためのサービス・チケットを取得します。

資格証明委任の詳細は、『Oracle Web Services Managerの理解』のKerberosの資格証明委任に関する項を参照してください。

資格証明委任を構成するには、次のタスクを実行する必要があります。

資格証明委任を許可するようにKerberosを構成します。
OWSMがクライアントにかわってサービスにKerberosチケットを転送できるように、クライアントがデプロイされるドメインを構成します。
クライアント・ポリシーおよびサービス・ポリシーで資格証明委任を有効にします。

Active Directoryのサービスとともに資格証明委任を使用する場合、委任が信頼されるようにサービスのSPNアカウントを構成する必要もあります。

次の各項では、これらのタスクについて説明します。

11.6.10.1 Kerberosの資格証明委任の構成

この手順は、kerberosに資格証明委任を構成する方法について説明しています。

資格証明委任をサポートするようにKerberosを構成するには、krb5.confファイルのlibdefaultsセクションにあるforwardableオプションをtrueに設定する必要があります。たとえば次のようになります。

[libdefaults]
forwardable = true

11.6.10.2 OWSMへの委任権限の構成

資格証明を委任するには、OWSMにクライアントにかわってサービスにKerberosチケットを転送する権限が必要です。

この権限を提供するには、このフォームのgrantPermission WLSTコマンドを使用します。

grantPermission(
  codeBaseURL="file:${common.components.home}/modules/oracle.wsm.common_12.1.2/wsm-agent-core.jar",
  permClass="javax.security.auth.kerberos.DelegationPermission",
  permTarget="\"service_principal@REALM_NAME\" \"krbtgt/REALM_NAME@REALM_NAME\"")

このコマンドで、service_principalはサービス・プリンシパルで、REALM_NAMEはセキュリティ・レルムです。

grantPermissionはオンライン・コマンドであるため、WebLogic Serverインスタンスへの接続に、最初にconnect WLSTコマンドを使用する必要があります。grantPermissionコマンドの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のgrantPermissionに関する項を参照してください。

11.6.10.3 クライアント・ポリシーおよびサービス・ポリシーでの資格証明委任の有効化

この手順は、クライアント・ポリシーおよびサービス・ポリシーで資格証明委任を有効にする方法を示しています。

資格証明委任は、クライアント・ポリシーおよびサービス・ポリシーのKerberosアサーションで、credential.delegation構成プロパティの値をtrueに設定することにより有効にします。このプロパティは、Kerberosアサーション・テンプレートのすべてで使用可能です。デフォルトで、この値はfalseであり、資格証明委任が無効であることを示しています。

11.6.10.4 Active Directoryのサービス用の資格証明委任の構成

Active DirectoryのサービスとともにKerberos資格証明委任を使用する場合、委任が信頼されるようにサービスのSPNドメイン・アカウントを構成する必要があります。

ドメイン・コントローラで、「Active Directoryユーザーとコンピューター」を起動します。
左側のペインで、「ユーザー」をクリックします。
右側のペインで、サービスのSPNを作成するときに使用したドメイン・アカウント名を右クリックして、「プロパティ」をクリックします。
「委任」タブで、「アカウントは委任に対して信頼されている」オプションを選択して、「OK」をクリックします。
「Active Directoryユーザーとコンピューター」を終了します。

注意:

Kerberos用の標準のJDKライブラリを使用するJavaクライアントは、JDKの制限により、Active Directoryでのこの設定は無視します。

11.6.10.5 資格証明委任の構成の例

この手順は、資格証明委任を構成する方法について説明しています。

次の例は、次のシナリオを使用して、資格証明委任を構成する方法を示しています。

ある銀行がその顧客に対して、口座保持者がその口座に関する情報を表示できる、MyBankerというクライアント・アプリケーションを提供しています。口座の取引情報を取得するため、MyBankerクライアントはTransactionsサービスをコールします。このサービスは、前回の口座明細以降の口座取引に直接アクセスできます。より古い取引に関する情報を取得するには、OldTransactionsサービスをコールします。OldTransactionsからの情報を取得するために、TransactionsはMyBankerクライアントの資格証明を認証する必要があります。

前提条件

この例では、MyBankerクライアントと、TransactionsおよびOldTransactionサービスすべてが同じKerberos KDCを使用して認証する必要があります。

手順

次の手順で、手順2、3および4は、OWSMを使用してクライアントとサービスを接続する際に通常実行する手順と非常に似ています。手順1および5は資格証明委任に特有です。

「OWSMへの委任権限の構成」の説明に従って、<grant>要素をsystem-jazn-data.xmlファイルに追加して、OWSMがMyBankerにかわってTransactionにチケットを転送できるようにMyBankerがデプロイされるドメインを構成します。
適切なKerberosまたはSPNEGOサービス・ポリシーをTransactionsサービスにアタッチします。通常の場合と同様にポリシーを構成します。さらに
- credential.delegationプロパティをtrueに設定します。
対応するKerberosまたはSPNEGOクライアント・ポリシーをMyBankerクライアントにアタッチします。通常の場合と同様にポリシーを構成します。さらに
- service.principal.nameプロパティをTransactionsサービスのプリンシパル名に設定します。
- caller.principal.nameとkeytab.locationプロパティが設定されていることを確認します。
- credential.delegationプロパティをtrueに設定します。
適切な事前定義済KerberosまたはSPNEGOサービス・ポリシーをOldTransactionsサービスにアタッチします。通常の場合と同様にポリシーを構成します。
対応する事前定義済KerberosまたはSPNEGOクライアント・ポリシーをTransactionsサービスにアタッチします。このポリシーを次のように構成します。
- service.principal.nameプロパティをOldTransactionsサービスのプリンシパル名に設定します。
- caller.principal.nameとkeytab.locationプロパティが設定されていないことを確認します。

MyBankerの資格証明の追加の委任に対応できるようにこの例を拡張するには、追加の委任ごとにこれらのタスクを実行する必要があります。

「OWSMへの委任権限の構成」の説明に従って、委任資格証明を受信するサービスにチケットを転送する権限をOWSMに付与します。
委任資格証明を転送するサービスのサービス・ポリシーのcredential.delegationプロパティをtrueに設定します。
委任資格証明を受信するサービスにサービス・ポリシーを追加します。
委任資格証明を転送するサービスに対応するクライアント・ポリシーを追加し、それを手順例の手順5で説明するように構成します。

11.7 WS-Trustの構成について

セキュリティ・トークン・サービス(STS)を使用して、WS-TrustのOWSMポリシーを構成および使用できます。

最初の項であるWebサービスWS-Trustの概要では、WS-Trustの概要、およびSTSを使用してWebサービス・クライアントとWebサービスの間で信頼を仲介する方法について説明します。残りの項では、WS-Trustに関連する特定の構成トピックについて説明します。

11.7.1 WebサービスWS-Trustの概要

WS-Trust 1.3仕様は、セキュリティ・トークンのリクエストおよび発行を行う際の枠組みを提供するWS-Securityへの拡張機能と、ブローカ・トラスト関係への拡張機能を定義します。WS-Trust拡張機能は、セキュリティ・トークンの発行、更新および検証を行う方法を提供しています。

Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。WS-Trust仕様で定義されているように、これらの資格証明は、信頼ブローカとして機能する信頼できるセキュリティ・トークン・サービス(STS)から取得できます。つまり、Webサービス・クライアントおよびWebサービスは、明示的に相互に信頼し合っていませんが、両方がSTSを信頼しているため、暗黙的に相互に信頼し合っています。

信頼ブローカとしてSTSを使用する場合、認証は次のように進みます。

Webサービス・クライアントはSTSに対して自身を認証し、セキュリティ・トークンを発行するように要求します。これはRequestSecurityToken (RST)メッセージと呼ばれます。
STSはWebサービス・クライアントの資格証明を確認し、セキュリティ・トークン・リクエストに応答します。これはRequestSecurityTokenResponse (RSTR)メッセージと呼ばれます。
Webサービス・クライアントは、STSが発行したセキュリティ・トークンをWebサービスに提示します。
Webサービスは、発行されたセキュリティ・トークンの有効性を確認します。

このプロセスが正常に完了すると、Webサービス・クライアントはWebサービスをリクエストできます。

OWSMを使用して認証を管理する場合は、前述の一般的なプロセスを取得する実際のプロセスは次のようになります。

Webサービス・クライアントでWebサービスを起動する必要があります。OWSMエージェントは、WebサービスのWSDLをフェッチし、発行済トークン・サービス・ポリシーの抽出を試みます。OWSMエージェントは、WSDLで識別されたSTSと対話するために、(必要に応じてオーバーライドされた)ローカル・クライアント・ポリシーを使用します。

Webサービス・ポリシーでは、特定のSTSから発行されるトークンを求めることができます。
OWSMエージェントはRSTをSTSに発行します。
STSはRSTRを使用して応答します。
OWSMエージェントは、STSによって送信されたRSTRを処理し、発行済トークンをWebサービスに伝播します。
Webサービスを処理するOWSMは、発行済トークンを処理および検証し、レスポンスを生成します。

Web Services Federation

信頼ブローカとして機能するすることで、STSは次の2つの主要なサービスを提供します。

トークンを認証済Webサービス・クライアントに発行します。
トークンをWebサービスによる要求に応じて検証します。

また、STSは別のSTSによって発行されたトークンを受信し、受信したトークンの内容に基づいて独自のトークンを発行できます(他のSTSを信頼している場合)。相互に信頼し合い、発行済トークンを変換するこのSTSの機能により、Web Service Federationと呼ばれる、セキュリティ・ドメイン間のフェデレーテッド信頼を可能にします。

一例として、あるセキュリティ・ドメイン内のWebサービス・クライアントが別のセキュリティ・ドメイン内に存在するWebサービスを起動する必要があるとします。各ドメインにSTSがあり、互いに信頼し合っている場合、Webサービス・クライアントは次のようにWebサービスを起動できます。

Webサービス・クライアントはセキュリティ・ドメイン内のSTSに対して自身を認証し、セキュリティ・トークンを発行するように要求します。このSTSは、IDプロバイダSTSまたはIP-STSと呼ばれます。
IP-STSはWebサービス・クライアントの資格証明を確認し、セキュリティ・トークン・リクエストに応答し、発行済トークンを提供します。
Webサービス・クライアントはIP-STSから発行されたトークンをWebサービスのセキュリティ・ドメイン内のSTSに提示し、セキュリティ・トークンを発行するように要求します。この2番目のSTSは、リライイング・パーティSTSまたはRP-STSと呼ばれます。
RP-STSはIP-STSから発行されたトークンの有効性を確認します。IP-STSのトークンからのデータを使用して、独自のトークンを作成し、それをWebサービス・クライアントに提供します。
Webサービス・クライアントは、RP-STSから発行されたトークンをWebサービスに提示します。
Webサービスは、信頼するSTS (自身のセキュリティ・ドメイン内のRP-STS)から発行されたトークンの有効性を確認します。

前述のプロセスは、Webサービス・クライアントが、異なるセキュリティ・ドメイン内にあるWebサービスと、2つのドメインのSTS間で共有される信頼によって通信する方法を示しています。ただし、このSTS間で共有される信頼はさらに拡張可能です。IP-STSとRP-STSが直接的には互い信頼し合っていないが、同一の中間STSとの信頼を共有している場合、信頼のチェーンをIP-STSから中間STSへ、中間STSからRP-STSに形成できます。さらに、信頼のチェーンをIP-STSからRP-STSまで形成できる場合には、追加の中間STSをIP-STSとRP-STSの間に配置できます。

OWSMを使用してWeb Services Federationを構成する方法の詳細は、「Web Services Federationの構成について」を参照してください。

11.7.1.1 STS構成を取得するためのメカニズムの理解

このSTSもまた、Webサービスです。クライアント・アプリケーションは、STSと通信するために、port-uri、port-endpoint、wsdl-uri、さらに認証しようとするクライアントから受け入れることができるセキュリティ・トークンなど、STSの詳細を認識する必要があります。

2つのメカニズムにより、STS情報はクライアントで使用可能になります。

自動(クライアントSTS)ポリシー構成(「STSの自動ポリシー構成の設定」を参照してください)を使用する場合。自動ポリシー構成では、STS WSDLドキュメントを解析することにより、STSに関する情報を動的に生成します。

自動ポリシー構成は、STS構成ポリシーがクライアントではなくWebサービスにアタッチされたときにトリガーします。また、STS構成ポリシーで提供される情報は、ターゲットSTSのport-uriのみです。

このポリシーが発行済トークン・サービス・ポリシーとともにWebサービスにアタッチされた場合、STSのport-uriがWebサービスWSDLのIssuedTokenアサーションに発行者アドレスとして示されます。その結果として、STS WSDLにアクセスすることによって他のすべてのSTS情報(ターゲット・ネームスペース、サービス名、エンドポイントなど)が取得され、STS構成としてメモリー内に保存されます。この情報はメモリー内にのみ格納され、OWSMリポジトリ内で永続化されません。リポジトリの詳細は、Oracle Web Services Managerリポジトリの管理を参照してください。

WebサービスSTS構成ポリシーでSTS URIを指定し、それをWebサービスにアタッチした場合、クライアントでそのSTSの使用が強制されます。オーバーライドはできません。
自動ポリシー構成を使用せず、かわりにWebサービスを起動する前に、クライアントにSTS構成ポリシーをアタッチし、STSに関連する情報(port-endpoint、port-uri、公開鍵別名、STSへの認証に使用されるOWSMクライアント・ポリシーへの参照)をすべて指定します。この場合、STS構成ポリシーからのすべての情報が実行時にすでに使用可能です。

11.7.1.2 交換されるトークン・タイプの理解

STSは、理論的にはクライアントから任意のトークンを受信でき、それを他の任意のトークンに交換できますが、実際には一般に次のいずれかのトークンを受け入れ、SAMLアサーションを返します。

ユーザー名トークン。このトークン・タイプの場合:
1. Webサービス・クライアントは、ユーザー名とパスワードをSTSに送信します。
2. STSはパスワードを検証し、SAMLアサーションを返します。
3. クライアントは、WebサービスにSAMLアサーションを送信します。
このシナリオは、Webサービスにはパスワードを検証する機能がなく、したがってパスワードの検証をSTSに依存する場合に役立ちます。
Kerberosトークン。このトークン・タイプの場合:
1. クライアントはユーザー名とパスワードをKDCに送信し、Kerberosトークンを取得します。
2. クライアントはKerberosトークンをSTSに送信し、SAMLアサーションを取得します。
3. クライアントは、WebサービスにSAMLアサーションを送信します。
このシナリオは、Windows環境で役立ちます。Windowsマシン上で実行するクライアントはログオン済ユーザー・コンテキストを持ち、このコンテキストを使用して該当ユーザーのSTSからSAMLアサーションを取得できます。

このシナリオでは、クライアントはパスワードを持たず、したがってユーザー名トークンは使用できません。Kerberosのみを使用できます。
X509トークン。このトークン・タイプでは、クライアントは自身をSTSに対して認証するために秘密鍵を使用します。

これを受けてSTSは、一般に次のいずれかのトークンを返します。

SAML対称鍵所有者
SAML非対称鍵所有者
SAMLベアラー

これらのトークンの詳細は、「発行済トークンとしてのSAML鍵所有者およびSAMLベアラーの概要」を参照してください。

STSはSAML送信者保証トークンを返す場合もあります。詳細は、「発行済トークンとしてのSAML送信者保証の理解」を参照してください。

11.7.2 サポートされるSTSサーバー

OWSMでは、標準WS-Trustクライアントを提供しています。このクライアントは、次のセキュリティ・トークン・サービスとの相互運用が動作保証されています。

Oracle Security Token Service (OSTS)
Oracle OpenSSO STS
Microsoft ADFS 2.0 Security Token Service (STS)

11.7.3 トークンの存続期間およびトークンのキャッシュの理解

この項では、トークンの存続期間およびトークンのキャッシュについて説明します。

STSからのRSTRレスポンス・メッセージには、返されたトークンの妥当性を示す存続期間要素(<trust:Lifetime>)が含まれる場合があります。存続期間要素が存在する場合、OWSMはタイムスタンプを検証し、レスポンスが期限切れであればメッセージを拒否します。

また、OWSMでは返されたトークンのキャッシュをサポートします。発行済トークン・クライアント・ポリシーの構成プロパティissued.token.lifetimeが、返されたトークンのキャッシュを制御します。

STSにリクエストする場合、OWSMはSTSへのRSTリクエスト・メッセージでissued.token.lifetimeによって指定された期間に返されたトークンの存続期間をリクエストします。

STSがリクエストされたissued.token.lifetime値とは異なるトークン存続期間の値を返す場合、OWSMは返されたトークンをキャッシュするための期間として戻り値を使用します。STSが空のトークン期限切れ値を返した場合、OWSMは返されたトークンをキャッシュしません。

したがって、issued.token.lifetimeプロパティは、返されたトークンの特定の存続期間をリクエストするためにのみ使用されます。STSは値を受け取る義務はなく、OWSMはSTSによって返された実際の存続期間の値に基づいてトークン・キャッシュを実行します。

issued.token.lifetimeの値を指定しない場合、OWSMは28800000ミリ秒(8時間)のデフォルト・ドメイン値を使用します。このデフォルトのドメイン値を変更するには、「Fusion Middleware Controlを使用した発行済トークンの存続期間の構成」を参照してください。

11.7.4 STSの自動ポリシー構成の設定

自動ポリシー構成では、STS WSDLドキュメントを解析することにより、STSに関する情報を動的に生成します。

STS構成ポリシーが(クライアントではなく) Webサービスにアタッチされている場合、クライアントからサーバーへの最初の接続で実行時に自動ポリシー構成が行われます。

STS構成ポリシー(oracle/sts_trust_config_service_policy)で提供する情報は、ターゲットSTSのポートURIのみです。このポリシーが(発行済トークン・サービス・ポリシーとともに) Webサービスにアタッチされた場合、STSのport-uriがWebサービスWSDLのIssuedTokenアサーションに発行者アドレスとして示されます。

その結果としてOWSMは、STS WSDLにアクセスすることによって他のSTS情報(ターゲット・ネームスペース、サービス名、エンドポイントなど)を取得し、STS構成としてメモリー内に保存します。この情報はメモリー内に保存されますが、MDS内で永続化されません。

この節では、以下のトピックについて説明します。

11.7.4.1 自動ポリシー構成の要件の理解

自動ポリシー構成を使用してSTSと正常に通信するには、次の要件があります。

自動ポリシー構成は、JSEクライアントでは動作しません。WS-TRUSTのシナリオでJSEクライアントを使用する場合は、sts_trust_config_client_policyポリシーおよび発行済トークン・クライアント・ポリシーの両方をアタッチすることにより、クライアントにすべてのSTS構成情報を提供する必要があります。
oracle/sts_trust_config_service_policyポリシーは、Webサービスにアタッチする必要があります。そうしない場合は、自動ポリシー構成を使用できず、そのかわりに「Webサービス・クライアントからのSTS構成ポリシーの手動による構成: メイン手順」の説明に従って、クライアントのoracle/sts_trust_config_client_policyポリシーを手動で構成する必要があります。
信頼はWebサービスとクライアント間に存在するために、SAML送信者保証確認に自動ポリシー構成は使用できません。WebサービスのWSDLには、STSに関する情報は含まれません。
STSの証明書および公開鍵の別名がキーストアに存在する必要があります。デフォルトの別名はsts-csf-keyです。この方法の詳細は、「メッセージ保護に関するキーストアの構成の概要」を参照してください。
STSキーストアでクライアントの公開鍵が使用可能であることが必要です。

11.7.4.2 自動ポリシー構成の設定の主な手順

この項では、自動ポリシー構成を設定するために実行する必要があるタスクについて説明します。

この項には次のトピックが含まれます:

11.7.4.2.1 自動ポリシー構成のためのポリシーの構成

この項では、自動ポリシー構成のポリシーを構成する方法について説明します。

自動ポリシー構成のポリシーを構成するには、次の手順を実行します。

Webサービスが信頼するSTSを決定し、そのSTSの公開証明書をOWSMキーストアにインポートします。
必要に応じて、「SAML署名証明書の信頼できる発行者および信頼できる識別名リストの理解」の説明に従って、信頼できるSTSリストにSTSの識別名を追加します。
SAML HOK対称を使用する場合は、WebサービスおよびWebサービスの証明書のエントリをSTS構成に追加する必要があります。STSは、この証明書を使用して対称鍵を暗号化します。
sts_trust_config_service_policyポリシーのコピーを作成します。
「ポートURI」設定を編集し、STSのポートURIを追加します。

STSは通常、様々な入出力トークン・タイプの複数のURIポイントを公開しているので、必要なトークンに対応するURIを使用します。

11.7.4.2.2 自動ポリシー構成のためのWebサービス・クライアントの構成

この項では、自動ポリシー構成のWebサービス・クライアントを構成する方法について説明します。

自動ポリシー構成のWebサービス・クライアントを構成するには、次の手順を実行します。

Webサービスが必要とするタイプのトークンに応じて、Webサービス・クライアントに発行トークン・ポリシーをアタッチします。
事前定義された次の発行済トークン・ポリシーが提供されています。
- SAML HOKではoracle/wss11_sts_issued_saml_hok_with_message_protection_client_policy。
- SAMLベアラーではoracle/wss_sts_issued_saml_bearer_token_over_ssl_client_policy。
ユースケースに応じて、発行済トークン・ポリシーの次のプロパティを設定またはオーバーライドします。これらのプロパティの詳細は、Oracle Web Servicesの事前定義済アサーション・テンプレートを参照してください。
- sts.auth.user.csf.key
- sts.auth.x509.csf.key
- sts.keystore.recipient.alias
- sts.auth.keytab.location
- sts.auth.caller.principal.name
- sts.auth.service.principal.name
- sts.auth.on.behalf.of.csf.key
- on.behalf.of
sts.keystore.recipient.aliasは、メッセージ保護のためにSTS通信のクライアントにより使用されます。STS通信のクライアントがwss11メッセージ保護を使用している場合には、十分なものです。

ただし、wss10メッセージ保護を使用している場合、クライアントの署名鍵および暗号化鍵を追加設定した後、これらの鍵に対する信頼をSTS構成にインポートする必要があります。
STSの公開証明書および資格証明がキーストア内にあり、クライアントの公開鍵がSTSキーストア内で使用可能であることを確認します。この方法の詳細は、「メッセージ保護に関するキーストアの構成の概要」を参照してください。

11.7.4.2.3 自動ポリシー構成のためのWebサービスの構成

この項では、自動ポリシー構成のWebサービスを構成する方法について説明します。

自動ポリシー構成のWebサービスを構成するには、次の手順を実行します。

編集したsts_trust_config_service_policyをWebサービスにアタッチします。

注意:

sts_trust_config_service_policyポリシーおよびSTS発行済トークン・サービス・ポリシーの両方をアタッチする必要があります。ポリシーはペアとして動作します。
(クライアントにアタッチされたポリシーに対応する)発行済トークンのサービス・ポリシーをアタッチします。事前定義された2つの発行済トークン・ポリシーがあります。
- oracle/wss11_sts_issued_saml_hok_with_message_protection_service_policy - サービスで非対称または対称のSAML HOKを受け入れる場合に使用します。このポリシーに対してSSLを使用しないでください。
  
  その他すべてのwss11メッセージ保護ポリシーの場合と同様に、暗号化鍵を設定する必要があります。
  
  このポリシーでは、いくつかのオプションを変更できます。たとえば、SAML 1.1または2.0のいずれを要求するか、非対称鍵または対称鍵のいずれを要求するかなどです。
- oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_policy - SAMLベアラーが必要な場合に使用します。ただし、SSLでこのポリシーを使用するためにWebサービスを設定する必要があります。
  
  SAML 1.1または2.0のいずれを要求するかを指定できます。
必要に応じて、発行済トークン・サービス・ポリシーでkeystore.enc.csf.keyをオーバーライドします。
OWSMキーストアでクライアントの公開鍵が使用可能であることを確認します。

11.7.4.3 Webサービス・クライアントからのSTS構成ポリシーの手動による構成: メイン手順

STSの自動ポリシー構成を設定することにより、WebサービスからSTS構成ポリシーを構成する必要があります。ただし、状況によっては自動ポリシー構成が機能しないため、Webサービス・クライアントから手動で構成する必要があります。

次の状況が該当します。

WebサービスからSTS構成ポリシーを構成しなかった場合
SAML送信者保証確認の方法を使用している場合
JSEクライアントを使用している場合。自動ポリシー構成は、JSEクライアントでは動作しません。

Fusion Middleware Controlを使用してWebサービス・クライアントからSTS構成ポリシーを構成するには、次の手順を実行します。

Webサービス・クライアントに両方のWebサービス・クライアントおよび構成ポリシーをアタッチします。ポリシーは次の順序でアタッチする必要があります。
- STS信頼構成ポリシー(oracle/sts_trust_config_client_policy)
- 発行済トークン・クライアント・ポリシー
注意:
sts_trust_config_client_policyの複数のインスタンスをアタッチした場合に、エラーは生成されません。しかし、実行されるのは1つのインスタンスのみであり、それをどのインスタンスにするかを制御できません。
ユース・ケースに応じて、次のプロパティをオーバーライドします。これらのプロパティの詳細は、Oracle Web Servicesの事前定義済アサーション・テンプレートを参照してください。
- BindingProvider.USERNAME_PROPERTY(javax.xml.ws.security.auth.username)
- BindingProvider.PASSWORD_PROPERTY(javax.xml.ws.security.auth.password)
- oracle.wsm.security.util.SecurityConstants.ClientConstants.ATTESTING_MAPPING_ATTRIBUTE
- oracle.wsm.security.util.SecurityConstants.ClientConstants.CALLER_PRINCIPAL_NAME
- oracle.wsm.security.util.SecurityConstants.ClientConstants.ON_BEHALF_OF
- oracle.wsm.security.util.SecurityConstants.ClientConstants.SAML_AUDIENCE_URI
- oracle.wsm.security.util.SecurityConstants.ClientConstants.STS_KEYSTORE_RECIPIENT_ALIAS
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_INCLUDE_USER_ROLES
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_ISSUED_TOKEN_LIFETIME
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_PASSWORD_PROPERTY
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_SAML_ASSERTION_FILE_NAME
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_STS_AUTH_ON_BEHALF_OF_CSF_KEY
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_SUBJECT_PRECEDENCE
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_USERNAME_PROPERTY
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_CSF_KEY
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_ENC_KEY_ALIAS
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_ENC_KEY_PASSWORD
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KERBEROS_SERVICE_PRINCIPAL
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_LOCATION
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_PASSWORD
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_TYPE
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_RECIPIENT_KEY_ALIAS
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_SAML_ISSUER_NAME
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_SIG_KEY_ALIAS
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_SIG_KEY_PASSWORD
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_WSDL_URI
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_PORT_URI
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_PORT_ENDPOINT
- oracle.wsm.security.util.SecurityConstants.ClientConstants.WSM_POLICY_REFERENCE_URI
変更を保存します。

11.7.5 Web Services Federationの構成について

Web Services FederationのWebサービス、Webサービス・クライアントおよびSTSを構成する必要があります。

次の各項では、Web Services FederationのWebサービス、Webサービス・クライアントおよびSTSの構成方法について説明します。

11.7.5.1 Web Services FederationのWebサービスの構成

この項では、Web Services FederationのWebサービスを構成する方法について説明します。

次の手順を実行します。

必要な発行済トークン・サービス・ポリシーをサービスにアタッチします。OWSMは次の事前定義済ポリシーを提供します。
- oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_policy
- oracle/wss11_sts_issued_saml_hok_with_message_protection_service_policy
オプションで、oracle/sts_trust_config_service_policyポリシーをアタッチして、それをRP-STSを参照するように構成します。このポリシーをアタッチおよび構成することにより、RP-STSの自動ポリシー構成が可能になり、Webサービス・クライアントがRP-STSに対してoracle/sts_trust_config_client_policyポリシーをアタッチする必要性を回避するためのサービスを使用できるようになります。詳細は、「STSの自動ポリシー構成の設定」を参照してください。
RP-STSの署名証明書をOWSMキーストアにインポートします。
必要に応じて、「SAML署名証明書の信頼できる発行者および信頼できる識別名リストの理解」の説明に従って、信頼できる発行者および信頼できるDNとしてRP-STSを定義します。

11.7.5.2 Web Services FederationのWebクライアントの構成について

Web Services FederationのWebクライアントの構成方法は、発行者情報がWebサービス用のWSDLかRP-STS用のWSDLで提供されるかどうかによって異なります。

次のシナリオで構成されています。

11.7.5.2.1 発行者がサービスWSDL内に存在し、RP-STS WSDL内に存在しない場合のWebクライアントの構成

これは最も一般的なユースケースで、WebサービスがRP-STSの自動ポリシー構成用に構成される場合のユースケースです。

このユースケースでは、次の手順を実行して、Webクライアントを構成します。

Webポリシーにアタッチする発行済トークン・サービス・ポリシーに対応する発行済トークン・クライアント・ポリシーをアタッチして、それをWebサービスを参照するように構成します。また、メッセージ保護ポリシーを使用している場合は、sts.keystore.recipient.alias構成プロパティをRP-STSの証明書別別名に設定します。SSLポリシーを使用している場合は、このプロパティを設定しないでください。
oracle/sts_trust_config_client_policyポリシーをアタッチして、それをIP-STSを参照するように構成します。

11.7.5.2.2 発行者がサービスWSDL内に存在せず、RP-STS WSDL内にも存在しない場合のWebクライアントの構成

これは、RP-STSの自動ポリシー構成に対してWebサービスが構成されていない場合のあまり一般的ではないユースケースです。

このユースケースでは、次の手順を実行して、Webクライアントを構成します。

Webポリシーにアタッチする発行済トークン・サービス・ポリシーに対応する発行済トークン・クライアント・ポリシーをアタッチして、それをWebサービスを参照するように構成します。また、sts.in.order構成プロパティをRP-STSのエンドポイントURIとそれに続くIP-STSのエンドポイントURIに設定します。2つのURIはセミコロン(;)で区切ります。次に例を示します。
```
http://m2.example.com:14100/sts/wssbearer;
http://http://m1.example.com/adfs/services/trust/13/usernamemixed
```
oracle/sts_trust_config_client_policyポリシーをアタッチして、それをIP-STSを参照するように構成します。
oracle/sts_trust_config_client_policyポリシーをアタッチして、それをRP-STSを参照するように構成します。

11.7.5.2.3 発行者がサービスWSDL内に存在し、RP-STS WSDL内にも存在する場合のWebクライアントの構成

これはまれなユースケースで、WebサービスがRP-STSの自動ポリシー構成用に構成される場合のユースケースです。

このユースケースでは、次の手順を実行して、Webクライアントを構成します。

Webポリシーにアタッチする発行済トークン・サービス・ポリシーに対応する発行済トークン・クライアント・ポリシーをアタッチして、それをWebサービスを参照するように構成します。また、メッセージ保護ポリシーを使用している場合は、sts.keystore.recipient.alias構成プロパティをRP-STSの証明書別別名に設定します。SSLポリシーを使用している場合は、このプロパティを設定しないでください。
oracle/sts_trust_config_client_policyポリシーをアタッチして、それをIP-STSを参照するように構成します。

11.7.5.2.4 発行者がサービスWSDL内に存在せず、RP-STS WSDL内に存在する場合のWebクライアントの構成

これはまれなユースケースです。

このユースケースでは、次の手順を実行して、Webクライアントを構成します。

Webポリシーにアタッチする発行済トークン・サービス・ポリシーに対応する発行済トークン・クライアント・ポリシーをアタッチして、それをWebサービスを参照するように構成します。また、メッセージ保護ポリシーを使用している場合は、sts.in.order構成プロパティをRP-STSのエンドポイントURIとそれに続くIP-STSのエンドポイントURIに設定します。SSLポリシーを使用している場合は、このプロパティを設定しないでください。
メッセージ保護ポリシーを使用している場合は、oracle/sts_trust_config_client_policyポリシーをアタッチして、それをIP-STSを参照するように構成します。SSLポリシーを使用している場合は、この手順を実行しないでください。
oracle/sts_trust_config_client_policyポリシーをアタッチして、それをRP-STSを参照するように構成します。

11.7.5.3 Web Services FederationのSTSの構成

この項では、Web Services FederationのSTSを構成する方法について説明します。

RP-STSまたはIP-STSとしてSTSを構成する次の手順は、一般的で大まかな手順です。詳細は、特定のSTSのマニュアルを参照してください。Oracle STSについては、http://www.oracle.com/technetwork/middleware/id-mgmt/overview/oraclests-166231.htmlを参照してください。

Microsoft ADFS 2.0 STSについては、http://technet.microsoft.com/en-us/library/adfs2(v=ws.10).aspxを参照してください。

Web Services Federation用にRP-STSを構成するには、これらの手順を実行するためにRP-STSの管理インタフェースを使用します。

Webサービスをリライイング・パーティとして追加します。
信頼できるIDプロバイダとしてIP-STSを追加します。

Oracle STSでは、信頼できるIDプロバイダは発行局と呼ばれます。

Microsoft ADFS 2.0 STSは、信頼できるIDプロバイダはクレーム・プロバイダと呼ばれます。

Web Services FederationのIP-STSを構成するには、これらの手順を実行するためのIP-STSの管理インタフェースを使用します。

RP-STSをリライイング・パーティとして追加します。

11.7.6 発行済トークンとしてのSAML鍵所有者およびSAMLベアラーの概要

一般に、STSはSAMLアサーションのトークンを返します。

STSは、一般にSAMLアサーションの次のいずれかのトークンを返します。

SAML対称鍵所有者。STSによって返されるSAMLアサーションは、自身のクライアント・トークン(ユーザー名トークン、Kerberos、X509など)をSTSに送信した特定のクライアントのみが対象になります。

ローグ・クライアントがこのSAMLアサーションを盗難し、使用することを許すべきではありません。このために、対称または非対称のいずれかの「証明鍵」を使用できます。

対称証明鍵は、SAML HOKのみの証明鍵の決定で説明されているように、STS側、クライアント側またはその両側の入力から生成されます。

STSは、Webサービスのみが復号化できる暗号化された形式でSAML HOKアサーションにこの対称証明鍵を格納します。次に、(暗号化された証明鍵を含む)SAMLアサーション全体に署名し、それをクライアントに送信します。

また、クライアントがサーバーにこのSAMLアサーションを送信する場合は、この証明鍵による署名も必要になります。Webサービスは、まずSAMLアサーションのSTS署名を検証し、SAMLアサーションから証明鍵を抽出した後に復号化し、クライアントの署名を検証します。このクライアントの署名は、クライアントが証明鍵を持つことをサーバーに「証明」します。

この証明鍵はクリア・テキストで送信されないので、ローグ・クライアントがネットワーク・スニッフィングによって取得することはできません。ローグ・クライアントがネットワーク・スニッフィングによってSAMLアサーションを取得しても、証明鍵を持たず、証明鍵で署名できないので、利用することはできません。したがって、ローグ・クライアントはSAMLアサーションの使用が許可されていることをサーバーに証明できません。
SAML非対称鍵所有者。非対称証明鍵は、次のように動作します。
1. クライアントは公開鍵/秘密鍵ペアを生成します。
2. クライアントは秘密鍵を保存し、そのトークン(ユーザー名トークン、Kerberos、X509など)とともに公開鍵を安全にSTSに送信します。
3. STSはクライアントのトークンを検証し、公開鍵を含むSAMLアサーションを返します。(公開鍵を含む)SAMLアサーション全体がSTSによって署名され、クライアントに返されます。
4. 次に、クライアントはSAML HOK非対称アサーションをWebサービスに送信し、その公開鍵/秘密鍵ペアの秘密鍵により署名します。
5. Webサービスは、SAMLアサーションのSTSの署名を検証した後、SAMLアサーションから公開鍵を抽出し、その公開鍵を使用してクライアントの署名を検証します。
  
  このクライアントの署名は、SAMLアサーションが正しく使用されており、盗難およびリプレイされていないことをWebサービスに証明します。
注意:

SAML HOK対称鍵の場合とは異なり、SAML HOK内のこの公開鍵は暗号化されません。これによって、STS側で必要な構成が軽減されます。

SAML HOK対称の場合、Webサービスの対称鍵を暗号化できるように、各Webサービスの証明書によりSTSを構成する必要があります。これは、非対称SAML HOKでは必要ありません。

また、特定のWebサービスの鍵により暗号化されないので、同じSAML HOK非対称トークンを任意のWebサービスに送信できます。

注意:

公開鍵/秘密鍵ペアが存在しても、関連する証明書はありません。つまり、証明書のリクエストのために公開鍵が認証局に送信されることはありません。

その代りに、STSはCAと同様に動作します。CAは公開鍵を取得し、証明書を返します。この場合、STSは公開鍵を取得し、SAMLアサーションを返します。

ただし、存続期間が通常は数年にわたる証明書とは異なり、STSによって発行されるSAMLアサーションの存続期間は通常は数時間であり、その後クライアントは新しい鍵ペアを生成し、新しいSAMLアサーションをリクエストする必要があります。

この短い存続期間のために、証明書で必要になる失効チェックは不要です。これは、クライアントの鍵を管理する必要がないので、クライアント側で魅力的になります。
SAMLベアラー。SAMLベアラー鍵には、関連付けられた証明鍵はありません。したがって、ローグ・クライアントによる盗難およびリプレイを防止するために、SSL経由で使用する必要があります。

11.7.6.1 SAML HOKのみの証明鍵の決定

SAML鍵所有者(HOK)にとっては、クライアントとWebサービス間の通信を保護するために証明鍵が必要です。証明鍵は、リクエストされたセキュリティ・トークンに関連付けられたトークンを所有していることを証明します。

<sp:IssuedToken>ポリシー・アサーションの<key-type>エントリのoracle/wss11_sts_issued_saml_hok_with_message_protection_service_policyポリシーで、証明鍵タイプの要件を指定します。次に例を示します。

<orasp:request-security-token-templateorasp:key-type = "Symmetric"

または

orasp:key-type = "Public"

対称鍵および非対称鍵がサポートされます。また、証明鍵がなくてもかまいません(非定義)。

こうした<key-type>の可能な値は、WS-Trust 1.3仕様に含まれています。

http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey
http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey

この項では、次の項目について説明します。

11.7.6.1.1 対称証明鍵について

Webサービスのセキュリティ・ポリシーによって対称証明鍵が求められる場合、要求者は証明鍵の計算に含めることができる鍵の内容の一部(エントロピ)を渡すことができます。Webサービス・ポリシーでは、クライアント・エントロピ、STSエントロピ、またはその両方が必要であるかどうかを示すことができます。

ただし、証明鍵として何を使用するかはSTSが判断します。STSは、トークン・リクエストの処理時に次のことを実行できます。

証明鍵の単独鍵の内容としてクライアント・エントロピを受け入れます。この場合、RSTR内に<wst:RequestedProofToken>要素は存在しません。証明鍵は暗黙に示されます。

OWSMエージェントは、署名および暗号化のための鍵の内容としてクライアント・エントロピを使用します。
鍵の部分的内容としてクライアント・エントロピを受け入れ、両鍵の部分的内容の関数として証明鍵を計算するために、鍵の部分的内容として追加STSサーバー側エントロピを提示します。

STSにより提供されたエントロピを含む<wst:Entropy>要素がRSTR内に存在します。また、RSTRには<wst:RequestedProofToken>要素があり、この要素には計算鍵のメカニズムが含まれます。アルゴリズムのデフォルト値は、http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1です。

OWSMエージェントおよびSTSは、指定された計算鍵メカニズムを使用して両方のエントロピを組み合せることにより、証明鍵を計算します。
クライアント側エントロピを拒否し、単独鍵の内容としてSTSサーバー側エントロピを証明鍵に使用します。

証明鍵を含む<wst:RequestedProofToken>要素がRSTR内に存在します。OWSMエージェントは、署名および暗号化のための鍵の内容としてSTSエントロピを使用します。

11.7.6.1.2 非対称証明鍵について

非対称証明鍵は秘密鍵/公開鍵ペアを使用し、公開鍵と秘密鍵が異なるために「非対称」と呼ばれています。

非対称鍵のトークンをリクエストする場合、URIとしてhttp://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKeyを含むwst:KeyType要素がRSTに存在します。

11.7.7 発行済トークンとしてのSAML送信者保証の理解

STSは一般に、SAML HOKまたはSAMLベアラー・トークンを返します。ただし、STSはSAML送信者保証トークンを返す場合もあります。

SAML送信者保証の信頼モデルは完全に異なります。HOKおよびベアラー内で、SAMLアサーションがSTSによって発行され、STSによって署名されます。この場合、Webサービスはクライアントを直接信頼せず、STSを信頼します。WebサービスがHOKまたはベアラーのトークンを受信した場合、信頼できるSTSに対して署名を検証します。

この間接的な信頼モデルにより、トラスト・ストアの管理が大幅に単純化されます。つまり、5つのクライアントがメッセージ保護を使用して5つのWebサービスと通信する場合、各Webサービスは5つのクライアントの公開鍵を認識する必要があります。ただし、中間にSTSが存在する場合、WebサービスはSTSの公開鍵のみを認識するだけで済みます。

SAML送信者保証では、Webサービスはクライアントを直接信頼します。SAML送信者保証トークンは一般的に、クライアントによって直接生成され、クライアントの秘密鍵によって署名されます。ただしクライアントは、トークンを生成するようにSTSに要求できます。この場合、STSはSAMLアサーションに署名せず、そのままクライアントに返します。クライアントは、前述と同様にSAML送信者保証トークンに署名し、それをWebサービスに送信します。Webサービスは、クライアントがSTSからSAML送信者保証トークンを取得したことを認識しておらず、クライアントの署名をチェックします。

WS-TrustでSAML送信者保証を設定するには、発行済トークン・ポリシーを含めないでWebサービスを構成します。つまり、oracle/wss11_saml_token_with_message_protection_service_policyポリシーを使用します。

発行済トークン・ポリシーを使用してクライアントを構成します。SAML送信者保証用に想定されているoracle/wss11_sts_issued_saml_with_message_protection_client_policyに加えて、STS構成ポリシーも使用します。

WebサービスWSDLにはSTSに関する情報が含まれないので、SAML送信者保証に自動ポリシー構成機能は使用できません(「STSの自動ポリシー構成の設定」を参照してください)。

11.7.8 On Behalf Ofユースケースの概要

「On Behalf Of」は、Webサービス・クライアントが別のエンティティにかわってSTSトークンをリクエストするアイデンティティ伝播ユースケースです。

次の使用例を考えてみます。

Webサービス・クライアントは、別のエンティティのトークンを取得するためにSTSを起動します。このエンティティは、エンド・ユーザーまたはその他の外部エンティティでもかまいません。エンティティの資格証明は、onBehalfOf要素のRSTに含まれます。
STSは、Webサービス・クライアントによって提示された資格証明を検証し、onBehalfOf要素内で識別済エンティティのセキュリティ・トークンを発行します。
Webサービス・クライアントはRSTRを検証し、トークンを抽出し、Webサービスに渡します。
Webサービスは、エンド・ユーザーのSAMLアサーションを受信し、トークンが信頼できるSTSによって発行されたことを確認します。

「On Behalf Of」ユースケースは、Oracle Web Services Managerの事前定義済アサーション・テンプレートに記載されているsts.auth.on.behalf.of.csf.keyプロパティおよびon.behalf.ofプロパティに依存します。サブジェクトから「On Behalf Of」ユーザー名が取得された場合、パスワードを持たないユーザー名です。

sts.auth.on.behalf.of.csf.keyで「On Behalf Of」ユーザー・エンティティのCSF鍵が識別された場合、CSF鍵を使用して確立されたアイデンティティが他のエンティティに代わって送信されます。この場合は、パスワードを持つユーザー名またはパスワードを持たないユーザー名です。

11.7.9 WS-Trustクライアント・ポリシーのプログラムによるポリシー構成オーバーライド

プログラムによる構成のオーバーライドを利用して特定のポリシーのプロパティを設定できます。

表5-1に、プログラムによる構成のオーバーライドを利用して特定のポリシーに設定できるプロパティを示します。

次のリストは、STSプロパティをプログラムによってオーバーライドする方法を示す一連のサンプル・ユースケースを示しています。

トークン交換ユーザー名トークン - 対称証明鍵によるSAML

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

トークン交換x509トークン - 対称証明鍵によるSAML

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

トークン交換ユーザー名トークン - 非対称証明鍵によるSAML

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

トークン交換x509トークン - 非対称証明鍵によるSAML

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");

サブジェクトからのOn Behalf Ofユーザー名と要求者トークン・ユーザー名のOn Behalf Ofトークンの交換 - 対称証明鍵によるSAML

(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");