| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.2.1.3.0) E90181-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.2.1.3.0) E90181-03 |
|
|
前 |
次 |
トピック:
メッセージを保護するには、メッセージの機密保持の場合はメッセージを暗号化し、メッセージ整合性の場合はメッセージに署名する必要があります。OWSM事前定義済ポリシー、およびいずれかのメッセージ保護アサーション・テンプレートを使用して作成したポリシーにより、メッセージの機密保持またはメッセージ整合性(あるいはその両方)のオプションが提供されます。
次の手順は、メッセージが保護されるよう、クライアントおよびサービスを構成するために実行が必要な操作をまとめたものです。
適切なメッセージ保護ポリシーをクライアントおよびサービスのそれぞれにアタッチします。
注意: メッセージ保護のみのポリシーは、リクエスタの認証または認可を行いません。
メッセージ整合性が必要な場合には、メッセージに署名します。
メッセージ機密保護が必要な場合には、メッセージを暗号化します。
必要な公開鍵と秘密鍵を、クライアントおよびサービスのキーストアに追加します。この手順を実行するには、「メッセージ保護に関するキーストアの構成の概要」の説明に従って、キーストアを構成しておく必要があります。
SOAPメッセージの署名および暗号化のために、WebLogicドメインのOWSMキーストアに格納する公開/秘密の署名/暗号化鍵を使用します。キーストア構成はドメイン全体に適用されるため、ドメイン内のすべてのWebサービスおよびWebサービス・クライアントがこのキーストアを使用します。
現在のリリースで使用可能なメッセージ保護ポリシーのサマリーは、「Webサービスに使用する事前定義済ポリシーの決定」の「メッセージ保護のみのポリシー」および「メッセージ保護および認証のポリシー」を参照してください。
注意:
OWSMランタイムでは、WebLogic Server管理コンソールにより構成され、「SSLに関するキーストアの構成について」の記載に従ってSSL用に使用されるWebLogic Serverキーストアは使用しません。
鍵とキーストアにより、メッセージ保護を構成するための基本が提供されます。SSLセキュリティ・ポリシーによるメッセージ保護および認証、またはメッセージ保護セキュリティ・ポリシーを使用するには、キーストアおよびトラストストアを設定する必要があります。(認証のみセキュリティ・ポリシーには鍵は必要ありません)。キーストアには、エンティティ秘密鍵およびその秘密鍵に関連付けられた証明書が含まれます。トラストストアには、認証局(CA)からの証明書、またはこのエンティティが信頼する他のエンティティからの証明書が含まれます。キーストアおよびトラストストアは共通ストアに保持できます。
OWSMは、次のキーストアのサポートを提供します。
キーストア・サービス(KSS)。詳細は、「メッセージ保護に関するOPSSキーストア・サービスの理解」を参照してください。
Javaキーストア(JKS)。詳細は、「メッセージ保護に関するJavaキーストアの理解」を参照してください。
ハードウェア・セキュリティ・モジュール(HSM)。キーストアとしてのHSMの使用方法の詳細は、「OWSMでのハードウェア・セキュリティ・モジュールの使用」を参照してください。
PKCS11.PKCS11キーストアの使用方法の詳細は、「Oracle SPARC T5およびSPARC T4暗号化アクセラレーションのためのOWSMの構成について」を参照してください。
この項では、JKSおよびKSSキーストアの作成方法、およびこれらのキーストアに鍵および証明書を移入する方法について説明します。
これらのキーストアを作成した後で、ドメイン・レベルでOWSMキーストアを構成する必要があります。詳細は、以下のトピックを参照してください。
この項では、次の項目について説明します。
OPSSキーストア・サービスでは、メッセージ・セキュリティを確保するためにキーおよび証明書を管理する方式が提供されています。これはメッセージ・セキュリティのためにキーと証明書を管理するためのデフォルトの方法です。
詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスによる鍵および証明書の管理に関する項を参照してください。
この項では、次の項目について説明します。
このトピックでは、メッセージ保護に関するOPSSキーストア・サービスの使用方法について説明します。
注意:
OWSMの旧リリースでは、JKSキーストアがデフォルトで使用されていました。バージョン12.1.2では、OPSSキーストア・サービスは元のインストール用にデフォルトで使用されます。前のリリースからアップグレードする場合は、既存のJKSキーストアが使用されます。Fusion Middleware ControlおよびWLSTの両方を使用して、OPSSキーストア・サービス操作を実行できます。ここでは、Fusion Middleware Controlの手順に焦点を当てますが、「キーストア・サービスを使用したキーと証明書の管理」では、両方の方法について説明しています。
メッセージ保護にOPSSキーストア・サービスを使用する手順は、次のとおりです。
ストライプを作成し、それにowsmという名前を付けます
コンテンツ・ペインで、「WebLogicドメイン」→「セキュリティ」→「キーストア」を選択します。
「ストライプの作成」をクリックします。図7-1に、「ストライプの作成」画面を示します。
「owsm」と入力し、「OK」をクリックします。
owsmストライプ内で、 keystoreという名前のキーストアを作成します(詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlでのキーストアの作成に関する項を参照してください。)
作成したowsmストライプを選択し、「キーストアの作成」をクリックします。
図7-2に、「キーストアの作成」ページを示します。
このキーストアにkeystoreという名前を付けます。
保護タイプを「ポリシー」に設定します。(このリリースでは、パスワードで保護されたKSSはサポートされていません。)
「権限の付与」チェック・ボックスの選択を解除します。
コード・ベースURLは指定しないでください。
「OK」をクリックします。
作成したキーストアを選択し、「管理」をクリックします。
図7-3に、「証明書の管理」画面を示します。
「鍵ペアの生成」をクリックし、公開鍵と秘密鍵のペアを生成します。
一般的に、署名および暗号化の両方のリクエストに対してこの鍵ペアを使用します。ただし、必要に応じて、署名および暗号化で別個の鍵ペアを作成できます。
図7-4に、「鍵ペアの生成」画面を示します。
鍵ペアにorakeyなどの別名を指定します。
必要に応じて、他のサイト固有の情報を指定します。
環境に適合する場合、デフォルトのRSAキー・サイズを受け入れます。キーの長さは1024ビット以上にする必要があります。
「OK」をクリックします。
「KSSキーストアを使用するためのOWSMの構成」の説明に従って、このキーストアと別名を使用するようにOWSMを構成します。
必要に応じて、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlを使用した証明書または信頼できる証明書のインポートに関する項の説明に従って、オプションで信頼できる証明書を取得します。
既存のJKSキーストアがある場合は、JKSキーストアからKSSキーストアに1つ以上の別名を移行できます。これを行うには、次の手順を実行します:
『Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスを使用したキーと証明書の管理に関する項で説明するように、キーストアをエクスポートおよびインポートできます。KSSはJKSおよびJCEKSの証明書形式の移行をサポートしています。
OWSMの旧リリースでは、JKSキーストアがデフォルトで使用されていました。バージョン12.1.2では、KSSキーストア・サービスは元のインストール用にデフォルトで使用されます。前のリリースからアップグレードする場合は、既存のJKSキーストアが使用されます。
既存のJKSキーストア証明書をKSSキーストアにインポートする場合は、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlを使用した証明書または信頼できる証明書のインポートに関する項を参照してください。
keystore.sig.csf.keyおよびkeystore.enc.csf.key属性のオーバーライド「ポリシー構成のオーバーライドの概要」の説明に従ってkeystore.sig.csf.keyおよびkeystore.enc.csf.keyをオーバーライドする場合は、csf-keyのかわりに、選択したキーストア別名を直接ポイントするように属性値を変更する必要があります。
KSSキーストア・サービスは、パスワードを使用しません。また、資格証明ストアを構成する必要はありません。署名鍵と暗号化鍵の別名は、鍵の格納と取得に使用されます。
keystore.sig.csf.keyおよびkeystore.enc.csf.keyをオーバーライドしない場合は、ユーザーの側でアクションは必要ありません。
WLSTコマンドlistExpiringCertificatesを使用します。
構文:
svc.listExpiringCertificates(days='days', autorenew=true|false)ここで:
svc: getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。
days: 期限までの日数がこの日数以下の証明書のみをリストします。すべての証明書が更新されるまでに多くの日数が必要となります。
autorenew: 期限が切れる証明書を自動的に更新する場合はtrue、表示するだけの場合はfalse。
例:
svc.listExpiringCertificates(days='9999', autorenew=true)デフォルトのKSSのかわりにJavaキーストアを使用するオプションがあります。Javaキーストアには、エンティティ秘密鍵およびその秘密鍵に関連付けられた証明書が含まれます。
ドメインごとに単一のOWSMキーストアが存在し、ドメイン内で実行するすべてのWebサービスおよびクライアントによってそのキーストアが共有されます。したがって、この項の説明に従ってJKSキーストアを構成した場合、OWSMではそのJKSキーストアのみが使用され、すでに定義されているKSSキーストアは無視されます。
この項では、次の項目について説明します。
次の項では、keytoolユーティリィティを使用して秘密鍵ペアおよびJavaキーストア(JKS)を作成する方法について概要を示します。keytoolユーティリティのコマンドと引数のより詳細な情報は、このWebアドレスで見つけられます。
http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html
VerisignやEntrust.netのような認証局(CA)から証明書を取得し、キーストアに含めることができます。証明書を取得するには、証明書リクエストを作成してCAに送信する必要があります。CAは、証明書リクエストを認証し、リクエストに基づいてデジタル証明書を作成します。
信頼できる証明書を取得し、その証明書をキーストアにインポートするには、次の手順を実行します。
OWSMは、保護された形式で資格証明を管理するために資格証明ストア・フレームワーク(CSF: Credential Store Framework)を使用します。CSFは、Webサービスやその他のアプリケーションの資格証明を格納、取得および削除する手段を提供します
OWSMは、次の検索のために資格証明ストアを使用します。
Javaキーストア内の鍵の別名およびパスワード。
OWSMがJavaキーストアから別名およびパスワードを検索するために資格証明ストアを使用する方法の詳細は、Webサービス・セキュリティの概念の理解を参照してください。
認証に使用されるユーザー名およびパスワード。
たとえば、認証のためにユーザー名トークンを受け入れるWebサービスがあるとします。このWebサービスと対話するWebサービス・クライアントを作成した場合、Webサービスに送信できるユーザー名およびパスワードでWebサービス・クライアントを構成する必要があります。(Fusion Middleware ControlまたはWLSTのいずれかを使用して)資格証明ストアにこのユーザー名とパスワードを格納し、それにCSFキーを割り当てます。
たとえば、oracle/wss_username_token_client_policyポリシーにはcsf-keyプロパティが含まれており、そのデフォルト値はbasic.credentialsです。wss_username_token_client_policyを使用するには、資格証明名basic.credentialsと、クライアントが接続時に使用する必要があるユーザー名およびパスワードを使用して、CSF内に新しいパスワード資格証明を作成します。この同じクライアント・ポリシーを使用する2つのWebサービス・クライアントが存在する場合、これらのクライアントで同じパスワード資格証明(デフォルト値はbasic.credentials)を共有することもできますし、それぞれが独自の資格証明を持つこともできます。後者の場合は、クライアント1およびクライアント2についてそれぞれ、CSF内に2つのパスワード資格証明(たとえばApp1.credentials、App2.credentials)を作成する必要があります。クライアント1ではcsf-key構成オーバーライドにApp1.credentialsを設定し、クライアント2ではcsf-keyプロパティにApp2.credentialsを設定します。詳細は、「ポリシー構成のオーバーライドの概要」を参照してください。いずれの場合も、ユーザー名およびパスワードがOPSSアイデンティティ・ストア内の有効なユーザーを表す必要があることに注意してください。
パスワード資格証明はユーザー名とパスワードを保存できます。汎用的な資格証明はどのような資格証明オブジェクトも保存できます。
CSF構成は、 domain-home/config/fmwconfigディレクトリのjps-config.xmllファイル内で維持されます。
注意:
「OWSMキーストアの構成」の説明に従ってKSSキーストアを構成した場合、資格証明ストアoracle.wsm.securityマップは作成されません。資格証明ストアを使用してユーザー資格証明を格納するには、その前に資格証明ストアを作成する必要があります。
資格証明ストアは、KSSキーストアが使用されるときに、キーストア別名を格納するために使用されません。
「OWSMキーストアの構成」の説明に従ってJKSキーストアを構成した場合、指定した別名およびパスワードは資格証明ストアに安全に格納されています。ただし、キーストアに他の別名を追加するか、クライアントの認証資格証明を追加する必要がある場合、次の項の説明に従って、資格証明ストアでもそれらが構成および格納されていることを確認する必要があります。
Fusion Middleware ControlまたはWLSTコマンドを使用して、資格証明ストアに鍵およびユーザー資格証明を追加できます。次の手順では、両方の方法について説明します。
注意:
この項で例としてと取りあげている手順では、前述のbasic.credentialsキーにユーザー資格証明を追加する方法、および『Oracle Web Services Managerの理解』のメッセージ保護ポリシーに関する秘密鍵と証明書の設定に関する項で説明されるServiceAおよびServiceB別名の例を示しています。
それぞれの環境では、構成に対して適切な別名およびパスワードを使用する必要があります。
資格証明ストアに鍵の資格証明を追加する前に、秘密鍵と別名がJavaキーストアに存在することを確認します。これは、次のようなコマンドを使用して作成できます。
keytool -genkeypair -keyalg RSA -alias ServiceA -keypass password -keystore default-keystore.jks -storepass password -validity 3600 keytool -genkeypair -keyalg RSA -alias ServiceB -keypass welcome3 -keystore default-keystore.jks -storepass password -validity 3600
キーストアの詳細は、「秘密鍵の生成およびJavaキーストアの作成」を参照してください。
この項では、次の項目について説明します。
Fusion Middleware Controlで次の手順に従って資格証明ストアに鍵と証明書を追加します。
「WebLogicドメイン」メニューで、「セキュリティ」→「資格証明」を選択します。
図7-5に示すように、「資格証明」ページが表示されます。
この構成では、資格証明ストアにoracle.wsm.security資格証明マップがすでに存在することに注意してください。この資格証明マップは、「OWSMキーストアの構成」の説明に従ってOWSMキーストアを構成したときに作成されたものです。
この資格証明マップが構成に表示されない場合は、「マップの作成」ボタンをクリックし、「マップ名」フィールドに「oracle.wsm.security」と入力することにより作成できます。
必要に応じて、マップで構成された鍵を表示するために、「資格証明」表でoracle.wsm.securityマップを開きます。図7-6に、サンプルのOWSM資格証明ストアの構成を示します。
鍵を選択し、「編集」をクリックすることにより、資格証明マップで鍵を編集できます。資格証明ストアで加えるすべての変更がOWSM Javaキーストア内の鍵の定義に準拠することに注意してください。
oracle.wsm.security資格証明マップ内で、たとえばServiceA およびServiceBの別名に対応する新しいエントリを作成するために、「キーの作成」をクリックします。図7-7に示すように、「キーの作成」ダイアログ・ボックスが表示されます。
「マップの選択」メニューから、まだ選択されていない場合は、マップ名「oracle.wsm.security」を選択します。
キーストアにアクセスするための鍵と値のペアを作成するために、「キー」フィールドに「csfServiceA」と入力します。
「タイプ」メニューから、「パスワード」を選択します。
「ユーザー名」フィールドで、キーストアで秘密鍵に指定した別名(たとえばServiceA)を入力します。
「パスワード」フィールドおよび「パスワードの確認」フィールドで、キーストアで別名のために指定したパスワード(たとえばpassword)を入力します。
「説明」フィールドで、エントリの説明を入力します(たとえば、「Key for ServiceA」など)。
「OK」をクリックします。
もう一度「キーの作成」をクリックし、ServiceBの別名に対するcsfServiceBなど、追加キーストアの別名の値を入力します。
必要に応じて、「キーの作成」をクリックして、次のようにしてoracle.wsm.security資格証明マップでcsf-keyユーザー資格証明のエントリを作成します(たとえばbasic.credentialsなど)。
「マップの選択」メニューから、まだ選択されていない場合は、マップ名「oracle.wsm.security」を選択します。
「キー」フィールドで、「basic.credentials」と入力します。この例では、basic.credentialsを使用しますが、鍵に選択した任意の名前を指定できます。
「タイプ」メニューから、「パスワード」を選択します。
「ユーザー名」フィールドで、OPSSアイデンティティ・ストアに存在する有効なユーザー名を入力します(たとえばAppIDなど)。
「パスワード」フィールドおよび「パスワードの確認」フィールドで、ユーザーの有効なパスワードを入力します(たとえばAppPWord%など)。
「説明」フィールドで、エントリの説明を入力します(たとえば、Username and Password for basic.credential keyなど)。
「OK」をクリックします。
サーバーを再起動します。
csf.map構成プロパティにより、特定の事前定義されたポリシーにアプリケーション・レベルの資格証明マップ名を設定できます(このプロパティを使用してドメイン・レベルの資格証明マップをアタッチメントごとにオーバーライドできます)。csf.map構成オーバーライドは、csf-keyまたはキーストア関連のcsfキーのいずれかを持つすべてのポリシーおよびアサーション・テンプレートで使用できます。
次のトピックは、アプリケーション・レベルの資格証明マップの作成について詳細に説明しています。
オーバーライドの構成の詳細は、「ポリシー構成プロパティのオーバーライド」を参照してください。
ドメインレベルのoracle.wsm.security資格証明マップは、Oracle WSMキーストアを構成するときに、資格証明ストアに作成されます。
Oracle WSMキーストアの構成の詳細は、OWSMキーストアの構成で説明されています。
アプリケーション・レベルの資格証明マップを構成すると、クライアントのcsfキー(csf-keyおよびユーザー・キーsts.auth.user.csf.key)は、次に示すように、ドメイン・レベルのマップではなく、そのマップからのみ取得されます。
アプリケーション・レベルのcsfマップを構成すると、そこからcsfキーが取得されます。csfキーが見つからない場合は、例外がスローされます。
アプリケーション・レベルのcsfマップが構成されていない場合は、ドメイン・レベルのcsfマップからcsfキーが取得されます。csfキーが見つからない場合は、例外がスローされます。
共有cfsキーの場合は、次のように動作が異なります。
keystore-csf-key: このcsfキーは、常にドメイン・レベルの資格証明マップ(oracle.wsm.security)から取得されます。
enc-csf-key: アプリケーション・レベルのマップが構成されている場合、このcsfキーは、最初にそこから取得されます。見つからなかった場合は、ドメイン・レベルのcsfマップから取得されます。
sign-csf-key: アプリケーション・レベルのマップが構成されている場合、このcsfキーは、最初にそこから取得されます。見つからなかった場合は、ドメイン・レベルのcsfマップから取得されます。
アプリケーションレベルの資格証明マップにアクセスするには、次の設定を行う必要があります。
次の項では、アプリケーションレベルの資格証明マップにアクセスする手順について説明しています。
アプリケーションが独自の資格証明マップにアクセスするには、アプリケーションに割り当てるポリシーのcsf.map構成のオーバーライドを設定する必要があります。
csf.mapプロパティのオーバーライドを構成するには、次の手順を実行します。
アプリケーションが独自の資格証明マップにアクセスするには、アプリケーションに割り当てるポリシーのcsf.map構成のオーバーライドを設定する必要があります。
wsm-agent-core.jarへのCredentialAccessPermissionを付与します。この権限は、Oracle Platform Security Services (OPSS)でCSFストア内の資格証明マップへのアクセスを許可するために必要です。
資格証明アクセス権限の付与は、次のいずれかの方法で行うことができます。
ドメインの「システム・ポリシー」ページから、アプリケーション・レベルの資格証明マップへのCredentialAccessPermissionを付与します。
システム・ポリシーの構成の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のシステム・ポリシーの管理に関する項を参照してください。
grantPermission WLSTコマンドを使用して、アプリケーション・レベルの資格証明マップへのCredentialAccessPermissionを付与できます。
grantPermission WLSTコマンドを使用して、アプリケーション・レベルの資格証明マップへのCredentialAccessPermissionを付与できます。
このWLSTコマンドの詳細は、WebLogic Server WLSTコマンド・リファレンスのインフラストラクチャ・セキュリティ・カスタムWLSTコマンドに関する項を参照してください。
mapName用語およびgetKeyアクションを使用して、wsm-agent-core.jarへのWSIdentityPermissionを付与します。特定のアプリケーションにこの権限を付与しない場合、アプリケーション・レベルの資格証明マップにアクセスできません。これは次のいずれかの方法で行うことができます。
ドメインの「システム・ポリシー」ページから、アプリケーション・レベルの資格証明マップへのCredentialAccessPermissionを付与します。
システム・ポリシーの構成の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のシステム・ポリシーの管理に関する項を参照してください。
ここでは、アプリケーション・レベルの資格証明マップへのアクセスおよび特定のアプリケーションにアクセスを制限するためのsystem-jazn-data.xmlでの権限付与の例を示します。resourceは、アプリケーションの資格証明マップの構成が必要なアプリケーション名、 mapNameは、構成する必要があるアプリケーション・レベルの資格証明マップ名です。
<grant>
<grantee>
<codesource>
<url>
file:${common.components.home}/modules/oracle.wsm.agent.common_${jrf.version}/wsm-agent-core.jar
</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.wsm.security.WSIdentityPermission</class>
<name>resource=usermessagingserver,mapName=application.specific.map</name>
<actions>getKey</actions>
</permission>
</permissions>
</grant>
resource用語およびmapName用語では、アスタリスク(*)のワイルドカードもサポートされます。アクションがgetKeyである場合の適正な権限名の例を次に示します。
resource=usermessagingserver,mapName=application.specific.map
usermessagingserverアプリケーションのみが資格証明マップapplication.specific.mapにアクセスできます。
resource=*,mapName=application.specific.map
すべてのアプリケーションが資格証明マップapplication.specific.mapにアクセスできます。
resource=usermessagingserver,mapName=*
アプリケーションusermessagingserverは、すべての資格証明マップにアクセスできます。
resource=usermessagingserver,mapName=intel-*
アプリケーションusermessagingserverは、intel-で始まるすべての資格証明マップにアクセスできます。
resource=intel-*,mapName=application.specific.map
名前がintel-*で始まるすべてのアプリケーションが資格証明マップapplication.specific.mapにアクセスできます。
注意:
WSMIdentityPermissionを使用してアプリケーション・レベルの資格証明マップにアクセスする場合:
権限は、管理対象アプリケーションでのみチェックされます。Java SEアプリケーションの場合、権限はチェックされません。
Oracle WSM JARへのjava.security.AllPermissionが付与されているOracle Java Cloud Service環境では、権限は機能しません。
ドメイン・レベルの資格証明マップにアクセスする場合、権限は必要ではありません。資格証明ストアを構成するための鍵およびユーザー資格証明の追加を参照してください。
csf.map構成オーバーライド・プロパティにより、次の事前定義されたポリシーにアプリケーション・レベルの資格証明マップ名を設定できます(このプロパティを使用してドメイン・レベルの資格証明マップをアタッチメントごとにオーバーライドできます)。
csf.map構成プロパティを含む事前定義済セキュリティ・アサーション・テンプレートの詳細は、Oracle Web Servicesの事前定義済アサーション・テンプレートを参照してください。
http_basic_auth_over_ssl_client_policy
http_jwt_token_client_policy
http_jwt_token_identity_switch_client_policy
http_jwt_token_over_ssl_client_policy
http_jwt_token_over_ssl_service_policy
http_jwt_token_service_policy
http_oauth2_token_client_policy
http_oauth2_token_identity_switch_opc_oauth2_over_ssl_client_policy
http_oauth2_token_identity_switch_over_ssl_client_policy
http_oauth2_token_opc_oauth2_client_policy
http_oauth2_token_opc_oauth2_over_ssl_client_policy
http_oauth2_token_over_ssl_client_policy
oauth2_config_client_policy
http_saml20_token_bearer_client_policy
http_saml20_token_bearer_over_ssl_client_policy
multi_token_over_ssl_rest_service_policy
multi_token_rest_service_policy
wss10_message_protection_client_policy
wss10_message_protection_service_policy
wss10_saml20_token_client_policy
wss10_saml20_token_with_message_protection_client_policy
wss10_saml20_token_with_message_protection_service_policy
wss10_saml_hok_token_with_message_protection_client_policy
wss10_saml_hok_token_with_message_protection_service_policy
wss10_saml_token_client_policy
wss10_saml_token_with_message_integrity_client_policy
wss10_saml_token_with_message_integrity_service_policy
wss10_saml_token_with_message_protection_client_policy
wss10_saml_token_with_message_protection_service_policy
wss10_saml_token_with_message_protection_ski_basic256_client_policy
wss10_saml_token_with_message_protection_ski_basic256_service_policy
wss10_username_id_propagation_with_msg_protection_client_policy
wss10_username_id_propagation_with_msg_protection_service_policy
wss10_username_token_with_message_protection_client_policy
wss10_username_token_with_message_protection_service_policy
wss10_username_token_with_message_protection_ski_basic256_client_policy
wss10_username_token_with_message_protection_ski_basic256_service_policy
wss10_x509_token_with_message_protection_client_policy
wss10_x509_token_with_message_protection_service_policy
wss11_message_protection_client_policy
wss11_message_protection_service_policy
wss11_saml20_token_with_message_protection_client_policy
wss11_saml20_token_with_message_protection_service_policy
wss11_saml_or_username_token_with_message_protection_service_policy
wss11_saml_token_identity_switch_with_message_protection_client_policy
wss11_saml_token_with_message_protection_client_policy
wss11_saml_token_with_message_protection_service_policy
wss11_sts_issued_saml_hok_with_message_protection_client_policy
wss11_sts_issued_saml_hok_with_message_protection_service_policy
wss11_sts_issued_saml_with_message_protection_client_policy
wss11_username_token_with_message_protection_client_policy
wss11_username_token_with_message_protection_service_policy
wss11_x509_token_with_message_protection_client_policy
wss11_x509_token_with_message_protection_service_policy
wss_http_token_client_policy
wss_http_token_over_ssl_client_policy
wss_saml20_token_bearer_over_ssl_client_policy
wss_saml20_token_over_ssl_client_policy
wss_saml_token_bearer_client_policy
wss_saml_token_bearer_over_ssl_client_policy
wss_saml_token_bearer_identity_switch_client_policy
wss_saml_token_over_ssl_client_policy
wss_sts_issued_saml_bearer_token_over_ssl_client_policy
wss_username_token_client_policy
wss_username_token_over_ssl_client_policy
メッセージ保護ポリシーを実装したWebサービスの場合、Webサービスのbase64エンコードされた公開証明書はWSDLで公開されます。証明書は、ポリシーによってデータが暗号化されるか復号化されるかに関係なく、メッセージ保護ポリシーに対して内包されます。
WSDLでパブリッシュされた証明書は、デフォルトではサービスの公開鍵です。これは、「メッセージ保護に関するキーストアの構成の概要」の説明に従ってキーストアで構成した暗号化鍵によって指定されたものです。
注意:
前のリリースのOWSMでは、メッセージ保護ポリシーを実装したWebサービスの場合、Webサービス・クライアントはWebサービスの公開証明書をそのドメイン・レベルのキーストアに格納する必要がありました。その後、クライアントはkeystore.recipient.aliasプロパティを使用して、キーストア内の証明書を識別します。このためには、「構成」ページでkeystore.recipient.aliasプロパティを特定するか、ポリシーをアタッチするときにクライアントごとに(またはプログラムにより)プロパティの構成オーバーライドを指定していました。
WSDLで公開鍵証明書が見つからない場合は、かわりにkeystore.recipient.aliasプロパティが使用され、以前と同様に証明書をクライアントのドメイン・レベルのキーストアに格納する必要があります。
注意:
自己署名証明書を信頼できるものにするには、クライアント側のキーストアで使用可能にする必要があります。
ホスト名検証機能によって、WSDLから取得した証明書が置換攻撃や中間者攻撃の対象になることなく、本当に予期したとおりの証明書であることが保証されます。
ホスト名を検証するため、OWSMは、証明書の共通名(CN)またはサブジェクト・グループ・ベース識別名(DN)がサービスのホスト名と一致することを確認します。この機能は、証明書のサブジェクトDNに依存します。デフォルトでは、ホスト名検証は無効です。
OWMはWSDLでX509証明書を公開してWebサービス・ポリシーを強制するかどうか、およびホスト名検証機能を使用するかどうかを指定できるドメイン構成プロパティを提供します。これらのプロパティの設定の詳細は、「Fusion Middleware Controlを使用したアイデンティティ拡張プロパティの構成」を参照してください。
この項では、次の項目について説明します。
「アイデンティティWSDLの無視」プロパティの値を設定する方法について説明します。
注意:
デフォルトでは、WSDLで証明書が公開されている場合、keystore.recipient.aliasのクライアント・オーバーライド・プロパティ値は無視されます。
Java EEクライアントの場合は、「アイデンティティWSDLの無視」プロパティの値が自動的に読み取られ、その他の構成は必要ありません。アイデンティティ検証をオンまたはオフにするには、「Fusion Middleware Controlを使用したアイデンティティ拡張プロパティの構成」の説明に従ってこのプロパティを設定します。
JSEクライアントの場合は、Webサービス・クライアントはWSDLの証明書を無視するための明示的なアクションを行う必要があり、無視するかどうかは設定されたkeystore.recipient.aliasプロパティのみに依存します。
これを行うには、wsm.ignore.identity.wsdlの値をtrueに設定します。
BindingProvider.getRequestContext().put(SecurityConstants.ClientConstants.WSM_IGNORE_IDENTITY_WSDL, "true");
Java EEクライアントの場合は、「ホスト名検証の無視」プロパティの値が自動的に読み取られ、その他の構成は必要ありません。
ホスト名検証をオンまたはオフにするには、「Fusion Middleware Controlを使用したアイデンティティ拡張プロパティの構成」の説明に従ってこのプロパティを設定します。
JSEクライアントの場合は、Webサービス・クライアントはホスト名検証を無視するための明示的なアクションを行う必要があります。
これを行うには、wsm.ignore.hostname.verificationの値をtrueに設定します。
BindingProvider.getRequestContext().put(SecurityConstants.ClientConstants.WSM_IGNORE_HOSTNAME_VERIFICATION,"false");
リプレイ攻撃から保護するため、いくつかのポリシーには、ユーザー名トークンにNonceを必要とするオプションが用意されています。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。
たとえば、oracle/wss10_username_token_with_message_protection_client_policyを参照してください。
Nonceは再使用を防ぐためにキャッシュされます。ただし、クラスタ環境では、このキャッシュを管理対象サーバー間で同期化する手順が必要になります。そうしないと、Webサービスに送信されて1つのサーバーで実行中のリクエストが、リプレイされて別の管理対象サーバーに送信され、そこで処理される可能性があります。OWSMは、Oracle Coherenceキャッシュを使用してNonceをキャッシュします。
アプリケーション・サーバー(OWSMを使用)はCoherenceクラスタの一部である必要があります。デフォルトで、構成ウィザードを実行する場合は、すべての管理対象サーバーまたはクラスタはCoherenceクラスタの一部になっています。クラスタ内で、2つの記憶域有効サーバーがNonceのキャッシュには十分であり、フェイルオーバー保護を提供します。2つのサーバーにはアプリケーション・サーバーを使用できますが、アプリケーション・サーバーで記憶域が無効の場合は、2つの記憶域有効キャッシュ・サーバーも使用できます。
注意:
これらの競合を回避するために、Coherenceクラスタ設定を構成する必要がある場合があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のCoherenceクラスタの構成と管理に関する項を参照してください。
環境のトポロジによって、次のいずれかの手順に従ってOracle CoherenceでNonceのキャッシュを有効にします。
Nonceのキャッシュにおける存続期間の設定方法は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』の「Fusion Middleware Controlを使用したセキュリティ・ポリシー強制の構成」を参照してください。
Coherenceクラスタ・トポロジをキャッシュする方法について説明します。
トピック:
Coherenceクラスタ・トポロジは、1つ以上のWebLogic Serverクラスタまたはサーバーによって形成されます。サーバーの一部は1つ以上の記憶域無効(WebLogic Server Coherenceクライアント層)および1つ以上の記憶域有効サーバー(WebLogic Server Coherenceサーバー層)です。このトポロジには管理対象Coherenceコンテナがありません。このトポロジは通常、データ記憶域要件が低い場合(通常100 MB未満)に使用されます。
図7-9に、WebLogic Serverクラスタ内で記憶域有効および記憶域無効サーバーから構成されるトポロジを示します。2つのサーバーが記憶域有効であり、フェイルオーバーした場合は、1つのサーバーが他方のバックアップとして使用できることに注意してください。構成ウィザードを実行する場合は、すべての管理対象サーバーまたはクラスタがデフォルトでCoherenceクラスタのサーバーの一部になっています。
図7-9 ストレージ有効およびストレージ無効WebLogic Serverでのクラスタ・トポロジ
インフラストラクチャ・ソフトウェアのインストールに関する項の手順に従って、WebLogic Serverをインストールし、標準のインストール・トポロジを構成します。その標準トポロジにより、これらの要件を満たすデフォルトのCoherenceクラスタが用意されます。
構成ウィザードのドメインの作成ページで、新規拡張ドメインの作成を選択できることに注意してください。
他の構成は必要ありません。wss_username_token_client_policyおよびwss_username_token_service_policyポリシーを使用する場合は、NonceがCoherenceキャッシュに格納されます。
Coherenceクラスタ・トポロジをキャッシュする方法について説明します。
トピック:
このCoherenceクラスタ・トポロジは、1つ以上の記憶域無効WebLogic Serverクラスタまたはサーバー、および2つ以上の管理対象記憶域有効Coherenceサーバー(フェイルオーバー保護用)によって形成されます。図7-10は、通常、キャッシュ要件が高い場合(100 MBを超える)、およびWebLogic Serverがデータ・キャッシュに使用されていない場合に、このトポロジが使用されることを示しています。このトポロジでは、キャッシュへのすべてのアクセスにはキャッシュ・サーバーへのネットワーク・ラウンドトリップが必要であることに注意してください。
注意:
データ記憶域要件は、キャッシュの観点からみたOracle Coherenceからの一般的な推奨事項です。OWSMの場合、この要件は、キャッシュの観点からみると、非常に低いです。少なくとも2つのアプリケーション・サーバーでキャッシュを有効にしている場合(フェイルオーバー保護用)、サーバー・グループWSM-CACHE-SVRへより多くのCoherenceコンテナを追加するのはオプションです。
たとえば、アプリケーション・サーバーのすべてがダウンしたら、Nonceが失われると考える場合は、バックアップとしてCoherenceコンテナを追加する可能性があります。
図7-10 Coherenceクラスタ内のストレージ有効管理対象Coherenceサーバーでのクラスタ・トポロジ
Fusion Middleware構成ウィザードを使用して、Nonceをキャッシュするために管理対象Coherenceサーバーをサーバー・グループに追加できます。WebLogic Server管理コンソールを使用して、ローカル記憶域が管理対象Coherenceサーバーに対して有効になっていて、記憶域がWebLogic Serverに対して無効になっていることを確認します。
注意:
アプリケーション・サーバーでCoherence記憶域を有効にしている場合、次の手順はオプションです。管理対象CoherenceコンテナでNonceをバックアップする場合にのみ必要です。
wss_username_token_client_policyおよびwss_username_token_service_policyポリシーを使用する場合は、NonceがCoherenceキャッシュに格納されます。
アサーション・テンプレートでは、メッセージ本文の完全な署名および暗号化だけでなく、部分的な署名および暗号化もサポートされています。SOAPメッセージ保護が可能なアサーション・テンプレートまたは事前定義済ポリシーの場合、デフォルトの動作はSOAPメッセージ本文全体を署名および暗号化して保護することです。必要な場合には、選択した要素を保護するように、アサーションおよびポリシーを構成できます。
トピック:
事前定義済メッセージ保護ポリシー用のFusion Middleware Controlユーザー・インタフェースでは、署名、暗号化またはその両方を行うメッセージ部分を簡単に指定できます。本文全体、アイデンティティ固有のヘッダー要素や本文要素に対して署名、暗号化またはその両方を行うことができます。次に、部分的な暗号化の例を示します。
この例では、Fusion Middleware Controlを使用して、SOAPメッセージの一部が暗号化されます。
SOAPエンベロープ内に配置できないデータをアタッチメント(SwA)とともにSOAPメッセージをパッケージングすることは、標準的なことになってきています。プライマリSOAPメッセージでは、アタッチメントまたはMIMEヘッダー付きのアタッチメントとして追加のエンティティを参照できます。
各SwAアタッチメントはMIME部分であり、MIMEヘッダーを含みます。SwAアタッチメントを含めるでは、アタッチメントは署名されますが、そのアタッチメントに対応するMIMEヘッダーは署名されません。MIMEヘッダーを含めるでは、アタッチメントに加えて対応するMIMEヘッダーも署名されます。
