Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.1.3) E59414-02 |
|
前 |
次 |
この章では、認証の構成方法を説明します。OWSMでは、認証のみ、およびメッセージ保護付き認証を提供するセキュリティ・ポリシーを提供します。
現在のリリースで使用可能な認証ポリシーのサマリーは、第3章「使用する事前定義済ポリシーの決定」の「認証のみのポリシー」および「メッセージ保護および認証のポリシー」を参照してください。認証の詳細は、『Oracle Web Services Managerの理解』の認証のサマリーに関する項を参照してください。
この章の内容は次のとおりです。
認証とは、ユーザーが表明しているとおりのユーザーであることを検証することを意味します。ユーザーのアイデンティティは、ユーザー名/パスワード、デジタル証明書、標準の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ポリシー」を参照してください。
ユーザー名、X.509、Kerberos、SAML、HTTP BASICなど、サポートされるトークン・タイプを使用するポリシーでは、WebLogic ServerにWebLogicデフォルト認証プロバイダなどの認証プロバイダを構成する必要があります。構成の詳細は、『Oracle WebLogic Serverセキュリティの管理』の認証プロバイダの構成に関する項を参照してください。
現在のリリースで使用可能な認証ポリシーのリストは、第3章「使用する事前定義済ポリシーの決定」の「認証のみのポリシー」および「メッセージ保護および認証のポリシー」を参照してください。
WebLogic Serverセキュリティの詳細は、次のマニュアルを参照してください。
Oracle WebLogic Serverセキュリティの管理
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プロバイダを使用しません。
資格証明マッパー・プロバイダ
認可プロバイダ
ロール・マッパー・プロバイダ
証明書パス・プロバイダ
監査プロバイダ
『Oracle Web Services Managerの理解』のダイジェスト認証に関する項で説明しているように、ダイジェスト認証とは、Webアプリケーションがパスワード、Nonceおよびタイムスタンプの暗号化ハッシュであるダイジェストをサーバーに送信することによってWebサービスに対してそれ自体を認証する認証メカニズムです。
OWSMでは、username-token認証ポリシーのすべてに対してダイジェスト・ベース認証がサポートされています。
Webサービスがデプロイされているホスト・システムは、組込みLDAP認証プロバイダ(デフォルト・オーセンティケータ)で構成されている必要があります。これは、Webサービス・クライアントがダイジェストの形式でパスワードを送信するためです。また、サービス側で認証するため、認証プロバイダはクリアテキスト・パスワード、Nonceおよびタイムスタンプを使用してダイジェストを再作成する必要があります。デフォルト・オーセンティケータは必要なクリア・テキストでパスワードを取得できます。
ダイジェストベースのクライアント・ポリシーには制限がありません。アタッチされるWebサービス・クライアントはすべてのサポートされているプラットフォームから実行できます。
WebLogic Server管理コンソールから次の手順を実行して、セキュリティ・レルムにデフォルト・オーセンティケータとデフォルトのアイデンティティ・アサータを構成します。
デフォルト・オーセンティケータのプロバイダ固有のページで「パスワード・ダイジェストの有効化」チェック・ボックスを設定します。詳細は、認証およびアイデンティティ・アサーション・プロバイダの構成を参照してください。
図10-1に示されているように、DefaultIdentityAsserterの共通ページでアクティブ・タイプとしてwsse:PasswordDigestを設定します。詳細は、認証およびアイデンティティ・アサーション・プロバイダの構成を参照してください。
WebLogic Serverを再起動します。
ダイジェスト認証を構成した後に作成されたユーザーは、ダイジェスト・ベースのメカニズムを使用して認証できます。
ただし、ダイジェスト認証を構成する前に作成されたユーザーは、ダイジェスト・ベースのメカニズムを使用して認証できません。これはWebLogic Serverセキュリティ・ランタイムがすでに作成されたユーザー用にパスワード・ダイジェスト(クリアテキスト・パスワードではない)をすでに格納しているためです。
ダイジェストではなく、クリアテキスト・パスワードがパスワード・データベースに格納されるように、これらのユーザーを再作成する必要があります。
ポリシーをアタッチし、ダイジェスト認証を有効化するには、次の手順を実行します。
まだ実行していない場合は、ダイジェスト認証をサポートするWebサービス・ポリシーのいずれかのコピーをアタッチします。ポリシーのコピーとアタッチ方法の詳細は、第4章「ポリシーのアタッチ」を参照してください。
ポリシーを開いて、図10-2に示すように、「パスワード・タイプ」ドロップダウン・メニューを「ダイジェスト」に変更します。
「必要な作成時間」コントロールを設定します。
「必要なNonce」コントロールを設定します。
ポリシーのクライアント・バージョンに対して手順1から4を繰り返します。
注意: パスワード・タイプとして「ダイジェスト」を選択し、ポリシーを有効にするために「必要な作成時間」および「必要なNonce」コントロールの両方を設定する必要があります。 |
SAML標準は、Web上のソフトウェア・エンティティの間でセキュリティ・アサーションを作成、リクエスト、交換するための共通XMLフレームワークを定義します。SAMLトークン・プロファイルは、WS-Security標準のコア・セットの一部であり、WebサービスのセキュリティのためにSAMLアサーションを使用する方法が指定されています。SAMLでは、ビジネス・プロセスまたはトランザクションの複数のステップ間で、ブラウザからポータル、Webサービスのネットワークへと渡すことのできるセキュリティ・トークンを表す標準的な方法も提供されます。
事前定義済SAMLポリシーは、名前にsaml
が含まれていて、第17章「事前定義済ポリシー」に一覧表示されています。
注意: 事前定義済SAMLポリシーを編集することはできません。設定または構成プロパティを変更するには、編集するポリシーのクローンを作成するか、ポリシーのアタッチ後に構成オーバーライドを使用して構成プロパティを設定する必要があります。 |
次のセクションで、SAML構成の詳細を説明しています。
SAMLログイン・モジュールは、WebサービスにかわってSAMLトークンを検証します。次に、SAMLログイン・モジュールは認証を完了するために、検証されたトークンからユーザー名を抽出し、Oracle Platform Security Services (OPSS)に(間接的に)渡します。
メッセージを保護するために使用されるSAMLアサーションおよびメカニズムのタイプによって、次の手順の1つ以上を使用してSAMLアサーションを検証します。
SAMLアサーションの署名を検証します。
SAMLアサーションの署名に含まれるか参照される署名証明書を取得します。
証明書が、キー・ストアにある証明書チェーンによって信頼されていることを検証します。
署名証明書の公開鍵でSAMLアサーション署名を検証します。
SAMLアサーション条件を検証します。
Not beforeおよびnot after。
SAML対象ユーザー制限。
SAMLアサーション発行者の信頼を検証します。
発行者が信頼できるかどうかを検証します。
署名証明書のDNが信頼できるものであるかどうかを検証します。
トークン属性ルール。
SAMLアサーションでユーザーを認証します。
注意: 通常、メッセージ全体が署名され、暗号化されます。たとえば、oracle/wss10_saml_token_with_message_protection_client_policyを考えてみます。デフォルトで、このポリシーを使用する場合は、メッセージ全体が署名され、暗号化されます。ただし、第7.5項「Fusion Middleware Controlを使用した部分的な暗号化の構成」で説明しているように、アサーション・テンプレートでは、メッセージ本文の完全な署名および暗号化のみでなく、部分的な署名および暗号化もサポートされています。メッセージ本文の一部を署名または暗号化しない場合は、SAMLトークンのみが署名されます。 oracle/wss10_saml_token_with_message_protection_client_policyポリシーの前の例では、SAML送信者保証の場合は、SAMLトークンがクライアントのプライベート証明書によって署名されます。 |
表10-1は、様々なSAMLタイプとセキュリティ・メカニズムの異なる組合せと、それぞれの場合にSAMLアサーションがどのように検証されるかを示しています。
表10-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。署名を鍵で検証することにより、送信者が秘密鍵を所有していることを検証します。 |
設計時にSAML Webサービス・クライアントを構成するには、この項で説明する手順を実行します。(デプロイ時にWebサービス・クライアントにSAMLポリシーをアタッチする場合、これらのプロパティは構成が不要で、Fusion Middleware Controlに表示されることもありません。)
これ以降の項で説明するように、ユーザー・ロールをアサーションに含め、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にユーザー名を構成する必要があります。
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ドメイン」メニューから「セキュリティ」→「セキュリティ・プロバイダ構成」を選択します。
ページの「アイデンティティ・ストア・プロバイダ」セクションで、「構成」をクリックしてアイデンティティ・ストアを操作するパラメータを構成します。
図10-3に示すように、「アイデンティティ・ストア構成」ページが表示されます。
「追加」をクリックしてカスタム・プロパティを追加します。
「新規プロパティの追加」ウィンドウが表示されます。
図10-4に示すように、値「true」のプロパティ「virtualize」を追加します。
「OK」をクリックして変更内容を送信します。
「アイデンティティ・ストア構成」ページで「OK」をクリックします。
サーバーを再起動します。
ユーザーのロールをSAMLアサーションの属性文として渡すことができます。このためには、デプロイ後にuser.role.include
プロパティを「true」に構成します。このポリシーのデフォルト値は「false」です。
設計時にユーザーのロールを構成するには、BindingProviderのuser.role.include
プロパティをtrueに設定します。
事前定義済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を構成する必要があります。
Webサービス・クライアント側とWebサービス側の両方で事前定義済SAMLポリシー(またはアサーション)が使用されている場合は、SAML発行者名はwww.oracle.com
として指定されます。このため、通常はデフォルト値を使用でき、発行者の構成は不要です。
信頼できる発行者のリストに発行者を追加する必要がある3つのシナリオがあります。
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ログイン・モジュール内の「発行者」リストに追加するには:
ターゲット・ナビゲーション・ペインで「WebLogicドメイン」を開き、発行者の追加が必要なドメインを表示します。ドメインを選択します。
コンテンツ・ペインで、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」を選択します。
「ログイン・モジュール」セクションで、必要に応じてSAMLまたはSAML2ログイン・モジュールを選択して、「編集」をクリックします。
「ログイン・モジュールの編集」ページが表示されます。
ページの「SAML固有の属性」セクションで「追加」をクリックします。
「発行者の追加」ウィンドウの「発行者」フィールドに発行者名を入力して、「OK」をクリックします。
サーバーを再起動します。
クライアント・ポリシーの発行者を次のように構成します。
デプロイ後、アタッチされたSAMLクライアント・ポリシーのsaml.issuer.name
プロパティの構成オーバーライド値を指定します。事前定義済Oracle SAMLクライアント・ポリシーのクローンを作成した場合、ポリシーをアタッチする前に、saml.issuer.name
構成プロパティの値を設定できます。
設計時に、BindingProviderのsaml.issuer.name
プロパティを設定します。
OWSMには、アイデンティティ切替えを有効にするwss11_saml_token_identity_switch_with_message_protection_client_policy
ポリシーが含まれます。アイデンティティ切替えとは、ポリシーが、認証されたサブジェクトに基づいたアイデンティティとは異なるアイデンティティを伝播することを意味します。
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サービスの |
SOAの場合:
SOAコンポジットは、1つのSOAサービス・コンポーネントとしてBPELプロセスを持ちます。BPELプロセスは、同期および非同期プロセスのプロセス編成と格納を行います。
BPELプロパティは、正確な名前javax.xml.ws.security.auth.username
を使用して定義できます。このプロパティの値を、SOAアプリケーションが伝播するアイデンティティにすることができます。これは潜在的にBPELプロセスによって動的に決定できます。
Java EEの場合:
BindingProvider.USERNAME_PROPERTY
プロパティを設定します。
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クライアントのアプリケーション名です。図10-5に示すように、アクションは常にassertです。
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"
です。
セキュリティを高めるために、SAML署名証明書の信頼できる識別名(DN)のリストを定義できます。
デフォルトの場合、OWSMでは、受信した発行者名を構成済の発行者のリストと照合してチェックし、SAML署名をOWSMキーストアにある構成済の証明書と照合してチェックします。また、信頼できるDNリストを定義する場合は、SAML署名がその発行者に関連付けられている特定の証明書に基づいて署名されているかどうかが検証されます。
信頼できるDNリストの構成はオプションです。詳細な制御を必要とするユーザーは、これにより各発行者を1つ以上の署名証明書のリストに関連付けることができます。信頼できる発行者のDNリストが定義されていない場合、証明書がOWSMキーストアに存在する証明書によって信頼されているかぎり、その証明書に基づいて署名できます。
SAML署名証明書の信頼できるDNリストの定義の詳細は、「Fusion Middleware Controlを使用した信頼できるSAML発行者およびDNリストの構成」を参照してください。
すべてのSAMLポリシーで、匿名ユーザーの伝播が許可されます。たとえば、認証ユーザーまたは匿名ユーザーのいずれかが操作できるADFアプリケーションが存在し、このADFアプリケーションでWebサービスへのコールを行い、現在のユーザーを伝播する必要がある場合、いずれかのSAMLポリシーを使用して認証ユーザーおよび匿名ユーザーの両方を伝播できます。セキュリティの観点からは、SAML経由での匿名ユーザーの伝播は、サービスに認証トークンを送信しないクライアントと等価です。
1つのポリシーで認証ユーザーおよび匿名ユーザーの両方をサポートできる利便性のために、SAML経由での匿名ユーザーが許可されています。ただし、SAML経由での匿名の伝播は非標準であり、他のベンダーとは相互運用できないことに注意してください。これは、クライアントおよびWebサービスの両方でOWSMを使用している場合にのみ使用してください。
アイデンティティ・コンテキストにより、組織は、Oracle Access Managementプラットフォームに組み込まれているコンテキストを意識したポリシー管理および認可機能を使用することで、増大するセキュリティの脅威に対応できます。アイデンティティ・コンテキストでは、従来のセキュリティ制御(ロールやグループなど)とともに、認証および認可中に確立される動的データ(認証強度、リスク・レベル、デバイス・トラストなど)を使用することで、リソースへのアクセスのセキュリティが確保されます。
たとえば、アプリケーションでは、次のためにアイデンティティ・コンテキストを使用できます。
ユーザーがスマート・カードなど強力な資格証明を使用して認証されていない場合、特定のビジネス機能を無効化します。
組織が(Identity Federationを使用して)取引しているビジネス・パートナによって提供されたアイデンティティ・データに基づいてトランザクションへのアクセスのセキュリティを確保します。
不正行為で知られる場所からアクセスされていることが検出された場合、追加の認証資格証明を要求します。
管理者の(サードパーティで管理されている)業界認定証が有効期限切れになっている場合、管理権限の範囲を制限します。
不明なデバイスからアクセスされていることが検出された場合、特定のビジネス機能を無効化します。
OWSMは、Webサービス・クライアントからWebサービスにアイデンティティ・コンテキストを伝播した後、認証および認可の目的のために、他のコンポーネントに対して使用可能に(公開)できます。
アイデンティティ・コンテキストは、Webサービス・クライアントおよびWebサービスに対して不透過であり、ポリシーのアイデンティティ・コンテキストの伝播を有効にした後、アイデンティティ・コンテキストのサポートのためにWebサービス・クライアントまたはWebサービスで追加コーディングまたは追加処理を実行する必要はありません。
注意: アイデンティティ・コンテキストの伝播は、SOA、WebCenterおよびJava EE (WebLogic) Webサービス・アプリケーションではサポートされません。 |
アイデンティティ・コンテキスト、アイデンティティ・コンテキスト・サービスの構成、アイデンティティ・コンテキストAPIの使用に関する詳細は、『Oracle Access Management管理者ガイド』のアイデンティティ・コンテキストの使用tに関する項を参照してください。
この機能を使用するには、Webサービス・クライアント・ポリシーおよびWebサービス・ポリシーの両方について、propagate.identity.context
構成プロパティを使用することにより、アイデンティティ・コンテキストの伝播を明確に有効にする必要があります。つまり、Webサービス・クライアント・ポリシーおよびWebサービス・ポリシーの両方で明確に許可する場合にのみ、OWSMでアイデンティティ・コンテキストを伝播できます。
OWSMは、SAML 1.1またはSAML 2.0アサーションを使用することにより、Webサービス・クライアントからWebサービスにアイデンティティ・コンテキストを伝播します。したがって、SAMLポリシーにのみpropagate.identity.context
構成プロパティが含まれます。
アイデンティティ・コンテキストをサポートするOWSMポリシーは、「アイデンティティ・コンテキストでサポートされるOWSMポリシー」にリストされています。
ここでの説明に従ってポリシーの「構成」ページで propagate.identity.context
に値を指定するか、ポリシーのアタッチ時にこの値をオーバーライドできます。
注意: ポリシーにこのプロパティを設定する場合は、「アイデンティティ・コンテキストでサポートされるOWSMポリシー」にリストされている必要な事前定義済SAMLポリシーのコピー(クライアントとサーバーの両方)を作成する必要があります。事前定義済ポリシーからの新規ポリシーの作成の詳細は、「Webサービス・ポリシーのクローンの作成」を参照してください。ポリシーを作成したら、それらのポリシーを編集し、この項の説明に従ってpropagate.identity.context プロパティを設定します。
ポリシーをアタッチするときに |
デフォルトでは、propagate.identity.context
構成プロパティは未設定であり、これはfalse
と等価です。アイデンティティ・コンテキストの伝播を使用するには、propagate.identity.context
を明確にtrue
に設定する必要があります。
クローンのポリシーを使用してアイデンティティ伝播を構成するには:
「ターゲット・ナビゲーション」ペインで「WebLogicドメイン」を開き、アイデンティティ・コンテキストの伝播の構成が必要なドメインを選択します。
「WebLogicドメイン」メニューから、「Webサービス」→「WSMポリシー」を選択します。
アイデンティティ・コンテキストの伝播を有効にするクローンのSAMLポリシーを選択し、「開く」をクリックします。
Webサービス・クライアントおよびWebサービス・ポリシーの両方についてアイデンティティ・コンテキストの伝播を有効にする必要があることに注意してください。
「アサーション」タブを選択します。
「構成」をクリックします。
「構成」ページには、ポリシーの構成プロパティのリストが表示されます。
propagate.identity.context
プロパティの「値」フィールドにtrue
を入力します。
「OK」をクリックします。
図10-6 propagate.identity.context
プロパティをTrueに設定する
propagate.identity.context
プロパティをTrueに設定する」の説明「保存」をクリックして変更を送信します。
対応するクライアント・ポリシーまたはサービス・ポリシーについて、必要に応じて手順3および8を繰り返します。
第4章「ポリシーのアタッチ」で説明するように、必要なエンドポイントにポリシーをアタッチします。
Kerberos認証プロトコルの詳細は、『Oracle Web Services Managerの理解』のKerberosプロトコルの概要に関する項を参照してください。
事前定義済Kerberosポリシーは、名前にkerberos
が含まれていて、第17章「事前定義済ポリシー」に一覧表示されています。事前定義済Kerberosアサーション・テンプレートは、名前にkerberos
が含まれていて、第18章「事前定義済アサーション・テンプレート」に一覧表示されています。
この項に記載されている手順に従って、KerberosをWebサービス・クライアントとWebサービスで使用できるように構成します。
この項では、KDCとしてMIT Kerberosを使用する場合の次のタスクについて説明します。
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 &
KDCユーザー・レジストリに2つのアカウントを作成します。最初のアカウントは、エンド・ユーザー用のもの、つまりWebサービス・クライアント・プリンシパルです。2つ目のアカウントは、Webサービス・プリンシパル用のものです。
これらのアカウントを作成する方法には、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システムにログインします。ランダム・パスワードを使用することにより、セキュリティが強化されます。
Webサービス・クライアントは、正しいKDCに対して認証するように構成する必要があります。
KDCの構成は、UNIXホストの場合は/etc/krb5.conf
に存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。
例10-1に、サンプルの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
例10-1 サンプルの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 }
Microsoft Active Directoryをキー配布センター(KDC)とともに使用することもできます。この項では、Active DirectoryをKerberosとメッセージ保護とともに使用する場合のKDCの構成方法について説明します。
この項では、Active Directoryに習熟していることを前提として説明します。詳細については、Active Directoryのドキュメントを参照してください。
注意: メッセージ保護のシナリオでKDCとして2008より前のバージョンのMicrosoft Active Directoryを使用する場合、次のポリシーを使用しないでください。
これらのポリシーはTriple DES暗号化を使用しており、これは前のバージョンのMicrosoft Active Directoryではサポートされていません。 かわりに、ポリシー名にbasic128を含むKerberosメッセージ保護ポリシーを使用してください。具体的には次のようになります。
これらの2つのポリシーは、Microsoft Active Directoryのサポートされているすべてのバージョンと互換性があります。 |
この節では、次のタスクについて説明します。
Active Directoryを使用してユーザー・アカウントを新規作成します。DES暗号化は使用しないでください。デフォルトでは、ユーザー・アカウントはRC4-HMACを使用して作成されます。
たとえば、ユーザーtestpol
をユーザー・ログオン名test/testpol
で作成できます。
ユーザー・ログオン名はgroup/name
の形式にする必要があります。
setSpn
を使用して、サービス・プリンシパル名をユーザーにマッピングします。
setSpn -A test/testpol testpol setSpn -L testpol (this should display the availabel mapping)
ユーザーにマッピングするサービス・プリンシパル名は1つのみにする必要があります。ユーザーにマッピングされたサービス・プリンシパル名が複数ある場合は、setSpn -D <spname> <username>
を使用して削除します。
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
は指定しないでください。
次の手順を実行して、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
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);
適切なKDCに対してWebサービスを認証するように構成します。KDCの構成は、UNIXホストの場合は/etc/krb5.conf
に存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。
例10-1に、Webサービス・クライアント用のサンプルのKDC構成を示します。この例は、WebサービスのKDC構成にも適用されます。
正しいkeytabファイルを使用するには、次の作業を行います。
keytabファイルの抽出とインストール
krb5ログイン・モジュールの変更
これらの作業は、後続の項で説明されています。
KDCからサービス・プリンシパル・アカウントのキー表ファイル(キー・タブとも呼ばれる)を抽出し、Webサービス実装のホストとなるマシンにインストールします。
たとえば、kadmin.local
などのツールを使用し、次のようにサービス・プリンシパル名のキー・タブを抽出できます。
>kadmin.local>ktadd -k /tmp/krb5.keytab SOAP/myhost.example.com
keytabファイルを、Webサービスのホストとなるマシンにエクスポートします。キー・タブはバイナリ・ファイルです。これをFTPで転送する場合は、バイナリ・モードを使用してください。
「Kerberosログイン・モジュールの構成」の説明に従って、WebサービスのKDCファイルの場所を識別するようにkrb5ログイン・モジュールを変更します。
たとえば、keytabファイルが/scratch/myhome/krb5.keytab
にインストールされているとします。キー・タブとプリンシパルのプロパティを次のように変更します。
principal value=SOAP/myhost.example.com@example.com
useKeyTab value=true
storeKey value=true
keyTab value=/scratch/myhome/krb5.keytab
doNotPrompt value=true
Webサービス・ランタイムでは、Kerberosトークンの妥当性を確認できる必要があります。
トークンが有効の場合、Oracle Platform Security Services (OPSS)は、サービス・プリンシパルに対応するユーザーを、構成済のWebLogic Server認証プロバイダのいずれかに対して認証できる必要があります。(認証プロバイダは、「WebLogic Serverへの認証プロバイダの構成」で説明されています。)
そのため、ユーザーは、認証プロバイダで使用されるアイデンティティ・ストアに存在し、有効になっている必要があります。
たとえば、SOAP/myhost.example.com@example.com
などのサービス・プリンシパルについて考えます。この例では、SOAP/myhost.example.com
という名前のユーザーがアイデンティティ・ストアに存在する必要があります。@domainは、ユーザー・エンティティに含めないでください。
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ユーザー名およびパスワードに対するプロンプトが表示されます。この場合、チケット・キャッシュはファイルシステムに作成されず、メモリーに保持されます。
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トークンを通知します。
SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism)は、クライアントおよびサービスが認証に使用する方法をネゴシエートすることを可能にする標準です。SPNEGOではネゴシエーションを実行するためにHTTPヘッダーを使用するので、Webなどのクロス・プラットフォームのコンテキストで特に役立ちます。
SPNEGOとKerberosの使用方法の詳細は、『Oracle Web Services Managerの理解』のKerberosとSPNEGOに関する項を参照してください。
OWSMは、SPNEGOネゴシエーションを使用して、クライアントおよびサービスで認証用にKerberosを使用できるようにするために、次のアサーション・テンプレートを提供します。
これらのアサーション・テンプレートは、SOAPまたはRESTのエンドポイントにアタッチされたポリシーによって使用できます。
これらのアサーション・テンプレートを使用して、新規ポリシーを作成したり、SPNEGOアサーションを既存のマルチトークン・ポリシーに追加できます。ポリシーの作成またはポリシーへのアサーションの追加の詳細は、次の項を参照してください。
Kerberosには、クライアント・リクエストで(クライアントにかわって)あるサービスが別のサービスを使用してリクエストを満たすように要求するシナリオをサポートする資格証明委任と呼ばれる機能が含まれています。このようなシナリオを満たすために、クライアントは、最初のサービスに転送されたTGT(チケット認可チケット)を提供します。最初のサービスはこれを使用して、KDCから2番目のサービスのためのサービス・チケットを取得します。
資格証明委任の詳細は、『Oracle Web Services Managerの理解』のKerberosの資格証明委任に関する項を参照してください。
資格証明委任を構成するには、次のタスクを実行する必要があります。
資格証明委任を許可するようにKerberosを構成します。
OWSMがクライアントにかわってサービスにKerberosチケットを転送できるように、クライアントがデプロイされるドメインを構成します。
クライアント・ポリシーおよびサービス・ポリシーで資格証明委任を有効にします。
Active Directoryのサービスとともに資格証明委任を使用する場合、委任が信頼されるようにサービスのSPNアカウントを構成する必要もあります。
次の各項では、これらのタスクについて説明します。
資格証明委任をサポートするようにKerberosを構成するには、krb5.conf
ファイルのlibdefaults
セクションにあるforwardable
オプションをtrue
に設定する必要があります。たとえば次のようになります。
[libdefaults] forwardable = true
資格証明を委任するには、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に関する項を参照してください。
資格証明委任は、クライアント・ポリシーおよびサービス・ポリシーのKerberosアサーションで、credential.delegation構成プロパティの値をtrueに設定することにより有効にします。このプロパティは、Kerberosアサーション・テンプレートのすべてで使用可能です。デフォルトで、この値はfalseであり、資格証明委任が無効であることを示しています。
Active DirectoryのサービスとともにKerberos資格証明委任を使用する場合、委任が信頼されるようにサービスのSPNドメイン・アカウントを構成する必要があります。
ドメイン・コントローラで、「Active Directoryユーザーとコンピューター」を起動します。
左側のペインで、「ユーザー」をクリックします。
右側のペインで、サービスのSPNを作成するときに使用したドメイン・アカウント名を右クリックして、「プロパティ」をクリックします。
「委任」タブで、セクションで、「アカウントは委任に対して信頼されている」オプションを選択して、「OK」をクリックします。
「Active Directoryユーザーとコンピューター」を終了します。
注意: Kerberos用の標準のJDKライブラリを使用するJavaクライアントは、JDKの制限により、Active Directoryでのこの設定は無視します。 |
次の例は、次のシナリオを使用して、資格証明委任を構成する方法を示しています。
ある銀行がその顧客に対して、口座保持者がその口座に関する情報を表示できる、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で説明するように構成します。
この項では、Security Token Services (STS)を使用してWS-Trust用のOWSMポリシーを構成および使用する方法について説明します。最初の項「WebサービスWS-Trustの概要」では、WS-Trustに関する導入情報、およびWebサービス・クライアントとWebサービス間のブローカ・トラストにSTSを使用する方法について説明します。残りの項では、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の構成」を参照してください。
この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リポジトリ内で永続化されません。リポジトリの詳細は、第15章「OWSMリポジトリの管理」を参照してください。
WebサービスSTS構成ポリシーでSTS URIを指定し、それをWebサービスにアタッチした場合、クライアントでそのSTSの使用が強制されます。オーバーライドはできません。
自動ポリシー構成を使用せず、かわりにWebサービスを起動する前に、クライアントにSTS構成ポリシーをアタッチし、STSに関連する情報(port-endpoint、port-uri、公開鍵別名、STSへの認証に使用されるOWSMクライアント・ポリシーへの参照)をすべて指定します。この場合、STS構成ポリシーからのすべての情報が実行時にすでに使用可能です。
STSは、理論的にはクライアントから任意のトークンを受信でき、それを他の任意のトークンに交換できますが、実際には一般に次のいずれかのトークンを受け入れ、SAMLアサーションを返します。
ユーザー名トークン。このトークン・タイプの場合:
Webサービス・クライアントは、ユーザー名とパスワードをSTSに送信します。
STSはパスワードを検証し、SAMLアサーションを返します。
クライアントは、WebサービスにSAMLアサーションを送信します。
このシナリオは、Webサービスにはパスワードを検証する機能がなく、したがってパスワードの検証をSTSに依存する場合に役立ちます。
Kerberosトークン。このトークン・タイプの場合:
クライアントはユーザー名とパスワードをKDCに送信し、Kerberosトークンを取得します。
クライアントはKerberosトークンをSTSに送信し、SAMLアサーションを取得します。
クライアントは、WebサービスにSAMLアサーションを送信します。
このシナリオは、Windows環境で役立ちます。Windowsマシン上で実行するクライアントはログオン済ユーザー・コンテキストを持ち、このコンテキストを使用して該当ユーザーのSTSからSAMLアサーションを取得できます。
このシナリオでは、クライアントはパスワードを持たず、したがってユーザー名トークンは使用できません。Kerberosのみを使用できます。
X.509トークン。このトークン・タイプでは、クライアントは自身をSTSに対して認証するために秘密鍵を使用します。
これを受けてSTSは、一般に次のいずれかのトークンを返します。
SAML対称鍵所有者
SAML非対称鍵所有者
SAMLベアラー
これらのトークンの詳細は、「発行済トークンとしてのSAML鍵所有者およびSAMLベアラー」を参照してください。
STSはSAML送信者保証トークンを返す場合もあります。詳細は、「発行済トークンとしてのSAML送信者保証」を参照してください。
OWSMでは、標準WS-Trustクライアントを提供しています。このクライアントは、次のセキュリティ・トークン・サービスとの相互運用が動作保証されています。
Oracle Security Token Service (OSTS)
Oracle OpenSSO STS
Microsoft ADFS 2.0 Security Token Service (STS)
STSからのRSTRレスポンス・メッセージには、返されたトークンの妥当性を示す存続期間要素(<trust:Lifetime>
)が含まれる場合があります。存続期間要素が存在する場合、OWSMはタイムスタンプを検証し、レスポンスが期限切れであればメッセージを拒否します。
また、OWSMでは返されたトークンのキャッシュをサポートします。発行済トークン・クライアント・ポリシーの2つの構成プロパティissued.token.caching
およびissued.token.lifetime
が返されたトークンのキャッシュを制御します。
issued.token.caching
がポリシー内でtrueに設定される場合、OWSMはSTSへのRSTリクエスト・メッセージでissued.token.lifetime
によって指定された期間に返されたトークンの存続期間をリクエストします。falseに設定される場合、OWSMは返されたトークンの存続期間をリクエストしません。
STSがリクエストされたissued.token.lifetime
値とは異なるトークン存続期間の値を返す場合、OWSMは返されたトークンをキャッシュするための期間として戻り値を使用します。STSが空のトークン失効値を返す場合、OWSMはissued.token.caching
がtrueに設定されているにもかかわらず、返されたトークンをキャッシュしません。
したがって、issued.token.lifetime
プロパティは、返されたトークンの特定の存続期間をリクエストするためにのみ使用されます。STSは値を受け取る義務はなく、OWSMはSTSによって返された実際の存続期間の値に基づいてトークン・キャッシュを実行します。
issued.token.caching
をtrueに設定したが、issued.token.lifetime
の値を提供しない場合、OWSMは28800000ミリ秒(8時間)のデフォルト・ドメイン値を使用します。このデフォルトのドメイン値を変更するには、「Fusion Middleware Controlを使用した発行済トークンの存続期間の構成」を参照してください。
自動ポリシー構成では、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内で永続化されません。
この節では、以下のトピックについて説明します。
自動ポリシー構成を使用して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キーストアでクライアントの公開鍵が使用可能であることが必要です。
自動ポリシー構成を使用するには、次の手順を実行します。
自動ポリシー構成のポリシーを構成するには、次の手順を実行します。
Webサービスが信頼するSTSを決定し、そのSTSの公開証明書をOWSMキーストアにインポートします。
必要に応じて、「SAML署名証明書の信頼できる発行者および信頼できる識別名リストの定義」の説明に従って、信頼できるSTSリストにSTSの識別名を追加します。
SAML HOK対称を使用する場合は、WebサービスおよびWebサービスの証明書のエントリをSTS構成に追加する必要があります。STSは、この証明書を使用して対称鍵を暗号化します。
sts_trust_config_service_policy
ポリシーのコピーを作成します。
「ポートURI」設定を編集し、STSのポートURIを追加します。
STSは通常、様々な入出力トークン・タイプの複数のURIポイントを公開しているので、必要なトークンに対応するURIを使用します。
自動ポリシー構成の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
。
ユースケースに応じて、発行済トークン・ポリシーの次のプロパティを設定またはオーバーライドします。これらのプロパティの詳細は、「アサーション・テンプレート構成プロパティ」を参照してください。
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キーストア内で使用可能であることを確認します。この方法の詳細は、「メッセージ保護に関するキーストアの構成」を参照してください。
編集した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キーストアでクライアントの公開鍵が使用可能であることを確認します。
「STSの自動ポリシー構成の設定」の説明に従って、WebサービスからSTS構成ポリシーを構成することをお薦めします。ただし、次の条件では、Webサービス・クライアントから構成する必要があります。
WebサービスからSTS構成ポリシーを構成しなかった場合
SAML送信者保証確認の方法を使用している場合
JSEクライアントを使用している場合。自動ポリシー構成は、JSEクライアントでは動作しません。
Fusion Middleware Controlを使用してWebサービス・クライアントからSTS構成ポリシーを構成するには、次の手順を実行します。
注意: OWSMで提供される事前定義済のポリシーは読取り専用であり、編集できません。事前定義済ポリシーを編集するには、そのクローンを作成し、クローン・バージョンを編集できます。 |
新しいSTS信頼構成ポリシーを作成します。次のいずれかの方法を実行します。
新規ポリシーを作成し、oracle/sts_trust_config_client_template
アサーション・テンプレートを追加します。詳細は、「新規Webサービス・ポリシーの作成」を参照してください。
oracle/sts_trust_config_client_policy
ポリシーのクローンを作成します。詳細は、「Webサービス・ポリシーのクローンの作成」を参照してください。
新規またはクローンを作成したポリシーを、次のように編集します。
「WSMポリシー」ページで、リストから新規ポリシーを選択して「開く」をクリックします。
「アサーション」タブを選択します。
「STS構成」セクションの「WSDLは存在しますか。」フィールドで「いいえ」を選択し、最低でも次の情報を入力します。
「ポートURI」フィールドに、STSポートの実際のエンドポイントURIを入力します。たとえば、http://host:port/context-root/service1
と指定します。
「ポート・エンドポイント」フィールドに、target-namespace#wsdl.endpoint(service-name/port-name)
と指定して、Webサービスのエンドポイントを入力します。
「クライアント・ポリシーURI」フィールドで、クライアントがSTSと通信する際に使用するOWSMクライアント・ポリシーを選択します。WSDLでの識別に従い、選択するポリシーはSTSの認証要件に応じて異なります。
ここで指定したポリシーによって、後ほど発行済トークン・クライアント・ポリシーで設定またはオーバーライドする必要がある対象が決まります。
「クライアント・ポリシーURI」がユーザー名ベースのポリシーを参照する場合、後にsts.auth.user.csf.key
パラメータを、STSに対して認証し、ユーザー名トークンを作成するよう構成します。また、署名鍵および暗号化鍵の別名を指定するためのsts.auth.x509.csf.key
の構成を行います。
「クライアント・ポリシーURI」がx509ベースのポリシーを参照する場合、STSに対する認証用のX509証明書を指定するためのsts.auth.x509.csf.key
パラメータの構成を行います。
「キーストア受信者の別名」フィールドで、キーストアに追加したSTS証明書の別名を指定します。デフォルトの別名はsts-csf-key
です。
変更を保存します。
まだ実行していない場合は、発行済トークン・クライアント・ポリシーを選択します。
第4章「ポリシーのアタッチ」の説明に従って、Webサービス・クライアントに両方のWebサービス・クライアント・ポリシーをアタッチします。次の順序でポリシーをアタッチする必要があります。
手順1で作成したSTS信頼構成クライアント・ポリシー。
発行済トークン・クライアント・ポリシー。
sts_trust_config_client_policy
の複数のインスタンスをアタッチした場合に、エラーは生成されません。しかし、実行されるのは1つのインスタンスのみであり、それをどのインスタンスにするかを制御できません。
Fusion Middleware Controlを使用して、選択した発行済トークン・クライアント・ポリシーの構成オーバーライドを編集します。詳細は、第5章「ポリシー構成プロパティのオーバーライド」を参照してください。
変更を保存します。
次の項では、Web Services FederationのWebサービス、Webサービス・クライアントおよびSTSの構成について説明します。
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を定義します。
Web Services FederationのWebクライアントの構成方法は、発行者情報がWebサービス用のWSDLかRP-STS用のWSDLで提供されるかどうかによって異なります。
これは最も一般的なユースケースで、WebサービスがRP-STSの自動ポリシー構成用に構成される場合のユースケースです。
このユースケースでは、次の手順を実行して、Webクライアントを構成します。
Webポリシーにアタッチする発行済トークン・サービス・ポリシーに対応する発行済トークン・クライアント・ポリシーをアタッチして、それをWebサービスを参照するように構成します。また、メッセージ保護ポリシーを使用している場合は、sts.keystore.recipient.alias
構成プロパティをRP-STSの証明書別別名に設定します。SSLポリシーを使用している場合は、このプロパティを設定しないでください。
oracle/sts_trust_config_client_policy
ポリシーをアタッチして、それをIP-STSを参照するように構成します。
これは、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を参照するように構成します。
これはまれなユースケースです。
このユースケースでは、次の手順を実行して、Webクライアントを構成します。
Webポリシーにアタッチする発行済トークン・サービス・ポリシーに対応する発行済トークン・クライアント・ポリシーをアタッチして、それをWebサービスを参照するように構成します。また、メッセージ保護ポリシーを使用している場合は、sts.keystore.recipient.alias
構成プロパティをRP-STSの証明書別別名に設定します。SSLポリシーを使用している場合は、このプロパティを設定しないでください。
oracle/sts_trust_config_client_policy
ポリシーをアタッチして、それをIP-STSを参照するように構成します。
これはまれなユースケースです。
このユースケースでは、次の手順を実行して、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を参照するように構成します。
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をリライイング・パーティとして追加します。
概して、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経由で使用する必要があります。
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
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エントロピを使用します。
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の自動ポリシー構成の設定」を参照してください)。
「On Behalf Of」は、Webサービス・クライアントが別のエンティティにかわってSTSトークンをリクエストするアイデンティティ伝播ユースケースです。
以下のシナリオについて考察します。
Webサービス・クライアントは、別のエンティティのトークンを取得するためにSTSを起動します。このエンティティは、エンド・ユーザーまたはその他の外部エンティティでもかまいません。エンティティの資格証明は、onBehalfOf
要素のRSTに含まれます。
STSは、Webサービス・クライアントによって提示された資格証明を検証し、onBehalfOf
要素内で識別済エンティティのセキュリティ・トークンを発行します。
Webサービス・クライアントはRSTRを検証し、トークンを抽出し、Webサービスに渡します。
Webサービスは、エンド・ユーザーのSAMLアサーションを受信し、トークンが信頼できるSTSによって発行されたことを確認します。
「On Behalf Of」ユースケースは、第18章「事前定義済アサーション・テンプレート」
に記載されている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鍵を使用して確立されたアイデンティティが他のエンティティに代わって送信されます。この場合は、パスワードを持つユーザー名またはパスワードを持たないユーザー名です。
表5-1に、プログラムによる構成のオーバーライドを利用して特定のポリシーに設定できるプロパティを示します。
次のリストは、STSプロパティをプログラムによってオーバーライドする方法を示す一連のサンプル・ユースケースを示しています。
(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");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");
(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");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_X509_CSF_KEY, "my-x509-csf-key");
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");
on.behalf.of
をtrueに設定する必要があります。
(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に設定する必要があります。
(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に設定する必要があります。
(BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSM_STS_AUTH_USER_CSF_KEY, "my-user-csf-key");
on.behalf.of
をtrueに設定する必要があります。
(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に設定する必要があります。
(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に設定する必要があります。