11 Oracle Web Services Managerを使用した認証の構成
現在のリリースで使用可能な認証ポリシーのサマリーは、「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.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アサーションの署名を検証します。
-
SAMLアサーションの署名に含まれるか参照される署名証明書を取得します。
-
証明書が、キー・ストアにある証明書チェーンによって信頼されていることを検証します。
-
署名証明書の公開鍵でSAMLアサーション署名を検証します。
-
-
SAMLアサーション条件を検証します。
-
Not beforeおよびnot after。
-
SAML対象ユーザー制限。
-
-
SAMLアサーション発行者の信頼を検証します。
-
発行者が信頼できるかどうかを検証します。
-
署名証明書のDNが信頼できるものであるかどうかを検証します。
-
トークン属性ルール。
-
-
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でサポートされる認証プロバイダ」で説明されています。
複数のアイデンティティ・ストアを構成しており、すべてのアイデンティティ・ストアでユーザーを検索する場合は、すべての構成済アイデンティティ・ストアで検索を有効にするために、次の手順に従います。
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発行者を追加する方法として、次の項の説明に従って、ドメイン・レベルの構成を使用することをお薦めします。
-
WLSTセクションへのリンク
前述の説明に従って発行者を追加する場合は、ドメイン内のすべてのサービスに適用されることと、サーバーの再起動が必要ではないことに注意してください。
後方互換性のために、セキュリティ・プロバイダのSAMLまたはSAML2ログイン・モジュールを構成することによって、Fusion Middleware Controlで発行者を追加することもできますが、望ましい方法はドメイン・レベルの構成を使用することです。SAMLログイン・モジュールでSAML発行者を定義しない場合、発行者はjps-config.xml
内で永続化されます。また、変更を有効化するにはドメインのサーバーを再起動する必要があります。
注意:
OWSMでは、次の階層を使用して、実行時に使用される信頼できる発行者を決定します。
-
最初に、ポリシーに対して構成された信頼できる発行者のリストがチェックおよび使用されます。これにより、ドメイン・レベルで信頼できる発行者がオーバーライドされます。
-
信頼できる発行者がポリシー・レベルで定義されていない場合は、ドメイン・レベルの構成がチェックおよび使用されます。
-
最後に、信頼できる発行者がポリシー・レベルかドメイン・レベルで定義されていない場合、SAMLログイン・モジュールで定義される発行者リストがチェックおよび使用されます。
別のSAMLアサーション発行者をSAMLログイン・モジュール内の「発行者」リストに追加するには:
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参照バインディング・コンポーネントにシステム権限として追加するには、次の手順に従います。
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
に設定する必要があります。
クローンのポリシーを使用してアイデンティティ伝播を構成するには:
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.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にログインすることなく、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は資格証明委任に特有です。
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アサーションを返します。
-
ユーザー名トークン。このトークン・タイプの場合:
-
Webサービス・クライアントは、ユーザー名とパスワードをSTSに送信します。
-
STSはパスワードを検証し、SAMLアサーションを返します。
-
クライアントは、WebサービスにSAMLアサーションを送信します。
このシナリオは、Webサービスにはパスワードを検証する機能がなく、したがってパスワードの検証をSTSに依存する場合に役立ちます。
-
-
Kerberosトークン。このトークン・タイプの場合:
-
クライアントはユーザー名とパスワードをKDCに送信し、Kerberosトークンを取得します。
-
クライアントはKerberosトークンをSTSに送信し、SAMLアサーションを取得します。
-
クライアントは、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 自動ポリシー構成のためのポリシーの構成
この項では、自動ポリシー構成のポリシーを構成する方法について説明します。
自動ポリシー構成のポリシーを構成するには、次の手順を実行します。
11.7.4.2.2 自動ポリシー構成のためのWebサービス・クライアントの構成
この項では、自動ポリシー構成のWebサービス・クライアントを構成する方法について説明します。
自動ポリシー構成のWebサービス・クライアントを構成するには、次の手順を実行します。
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サービスを構成する方法について説明します。
次の手順を実行します。
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クライアントを構成します。
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 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非対称鍵所有者。非対称証明鍵は、次のように動作します。
-
クライアントは公開鍵/秘密鍵ペアを生成します。
-
クライアントは秘密鍵を保存し、そのトークン(ユーザー名トークン、Kerberos、X509など)とともに公開鍵を安全にSTSに送信します。
-
STSはクライアントのトークンを検証し、公開鍵を含むSAMLアサーションを返します。(公開鍵を含む)SAMLアサーション全体がSTSによって署名され、クライアントに返されます。
-
次に、クライアントはSAML HOK非対称アサーションをWebサービスに送信し、その公開鍵/秘密鍵ペアの秘密鍵により署名します。
-
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.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");
on.behalf.of
をtrueに設定する必要があります。
On Behalf Ofユーザー名と要求者トークン・ユーザー名のOn Behalf Ofトークンの交換 - 対称証明鍵によるSAML
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_ON_BEHALF_OF_CSF_KEY, "my-on-behalf-of-csf-key"); (BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");
on.behalf.of
をtrueに設定する必要があります。
On Behalf Ofユーザー名と要求者トークンx509のOn Behalf Ofトークンの交換 - 対称証明鍵によるSAML
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_ON_BEHALF_OF_CSF_KEY, "my-on-behalf-of-csf-key"); (BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");
on.behalf.of
をtrueに設定する必要があります。
サブジェクトからのOn Behalf Ofユーザー名と要求者トークン・ユーザー名のOn Behalf Ofトークンの交換 - 非対称証明鍵によるSAML
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");
on.behalf.of
をtrueに設定する必要があります。
On Behalf Ofユーザー名と要求者トークン・ユーザー名のOn Behalf Ofトークンの交換 - 非対称証明鍵によるSAML
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_ON_BEHALF_OF_CSF_KEY, "my-on-behalf-of-csf-key"); (BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");
on.behalf.of
をtrueに設定する必要があります。
On Behalf Ofユーザー名と要求者トークンx509のOn Behalf Ofトークンの交換 - 非対称証明鍵によるSAML
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_ON_BEHALF_OF_CSF_KEY, "my-on-behalf-of-csf-key"); (BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");
on.behalf.of
をtrueに設定する必要があります。
11.7.10 JWKドキュメントの信頼構成の概要
OWSMはJSON Webキー(JWK)をサポートしています。JWKは、キーまたは証明書を事前にインポートせずに、リアルタイムでトークンを検証できる動的なアプローチを提供します。これは、多数の外部アイデンティティ・プロバイダがセキュリティ対策としてトークン署名鍵を定期的にローテーションする場合に役に立ち、OWSMはこれらの変更を動的に自動更新できます。
JSON Webキー(JWK)およびJWK Set
JWKは、暗号キーを表すJSONオブジェクトです。オブジェクトのメンバーは、その値を含むキーのプロパティを表します。JWK Setは、JWKのセットを表すJSONオブジェクトです。JSONオブジェクトには、JWKの配列である「キー」メンバーが必要です。
パラメータ | 説明 |
---|---|
kty |
キー・タイプ。RSAなど、キーとともに使用する暗号化アルゴリズム・ファミリを特定します。 |
alg |
アルゴリズム。キーとともに使用するアルゴリズムを特定します。 |
use |
公開鍵の使用。公開鍵の意図する使用を特定します。値は次のとおりです。
|
kid |
キーID。キーのロールオーバー中にJWK Set内のキーのセットから選択するためなど、特定のキーと一致させるために使用されます。 |
x5u |
X.509 URL。X.509公開鍵証明書または証明書チェーンのリソースを参照するURI。 |
x5c |
X.509証明書チェーン。1つ以上のPKIX証明書のチェーンが含まれます。証明書チェーンは、証明書値文字列のJSON配列として表されます。配列の各文字列は、Base64でエンコードされたDER PKIX証明書値です。 |
x5t |
X.509証明書のSHA-1拇印。X.509証明書のDERエンコーディングのBase64URLでエンコードされたSHA-1拇印。 |
x5t#S256 |
X.509証明書のSHA-256拇印。X.509証明書のDERエンコーディングのBase64URLでエンコードされたSHA-256拇印。 |
n |
係数。公開鍵の係数部分です。 |
e |
指数。公開鍵の指数部分です。 |
関連項目:
-
JWKドキュメントから構成をインポートおよび取り消すためのCLIコマンドについては、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』トークン発行者信頼構成コマンドに関する項を参照してください。
-
JWKドキュメントから構成をインポートおよび取り消すためのREST APIメソッドについては、『Oracle Web Services Managerでの資格証明およびキーストアの管理のためのREST API』のトークン発行者の信頼構成の管理に関する項を参照してください。
11.7.11 IDCS検出サービスについて
OWSMは、信頼を構成するための動的なオープンID接続検出をサポートしています。
検出サービスは、トークンに署名して信頼を構成するために使用するキーまたは証明書を事前にインポートせずに、リアルタイムでトークンを検証する動的なアプローチを提供します。OWSMはOpenIDプロバイダ・メタデータを活用して、信頼を動的に構成します。
-
<base-url>/.well-known/idcs-configuration
(パブリックおよび固有) -
<base-url>/.well-known/openid-configuration
(パブリックおよび標準)
関連項目:
-
構成をインポートおよび取り消すためのCLIコマンドについては、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』トークン発行者信頼構成コマンドに関する項を参照してください。
-
構成をインポートおよび取り消すためのREST APIメソッドについては、『Oracle Web Services Managerでの資格証明およびキーストアの管理のためのREST API』のトークン発行者の信頼構成の管理に関する項を参照してください。
11.7.12 トークン・オーディエンス構成について
OWSMは、外部アイデンティティ・プロバイダによって異なる方法で使用される外部トークンを検証するための、トークン・オーディエンス構成をサポートしています。
OWSMでは、トークン内で指定された1つ以上のオーディエンス値が、呼び出されるURL(またはその接頭辞)と一致することを保証して、トークン・オーディエンスを検証します。場合によっては、外部アイデンティティ・プロバイダがオーディエンス要求/属性を異なる方法で使用することがあります。そのような場合、OWSMはデフォルトのオーディエンス値をオーバーライドする1つ以上のオーディエンス値を指定できます。
デフォルトのオーディエンス値のオーバーライドは、1つ以上のオーディエンス値を構成することで行います。トークンのオーディエンス値リストに構成済のいずれかの値と一致する1つ以上の値がある場合、OWSMはトークンが有効であるとみなします。
トークン・オーディエンス構成は、Mobile Cloud Service (MCS)が外部アイデンティティ・プロバイダと連携して動作するのをサポートします。
関連項目:
-
構成をインポートおよび取り消すためのCLIコマンドについては、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』トークン発行者信頼構成コマンドに関する項を参照してください。
-
構成をインポートおよび取り消すためのREST APIメソッドについては、『Oracle Web Services Managerでの資格証明およびキーストアの管理のためのREST API』の信頼ドキュメント名の構成のインポートに関する項を参照してください。