| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.1.3) E59414-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.1.3) E59414-02 |
|
前 |
次 |
この章では、メッセージ保護の構成を紹介し、説明します。この章では、セキュリティ・ポリシーを使用するために、Fusion Middleware ControlおよびWebLogic Server環境を構成する必要があります。SSLセキュリティ・ポリシーによるメッセージ保護および認証、またはメッセージ保護セキュリティ・ポリシーを使用するには、キーストアおよびトラストストアを設定する必要があります。(認証のみのセキュリティ・ポリシーでは鍵は不要です。)
この章の内容は次のとおりです。
メッセージを保護するには、メッセージの機密保持の場合はメッセージを暗号化し、メッセージ整合性の場合はメッセージに署名する必要があります。OWSM事前定義済ポリシー、およびいずれかのメッセージ保護アサーション・テンプレートを使用して作成したポリシーにより、メッセージの機密保持またはメッセージ整合性(あるいはその両方)のオプションが提供されます。
次の手順は、メッセージが保護されるよう、クライアントおよびサービスを構成するために実行が必要な操作をまとめたものです。
適切なメッセージ保護ポリシーをクライアントおよびサービスのそれぞれにアタッチします。
注意: メッセージ保護のみのポリシーは、リクエスタの認証または認可を行いません。
メッセージ整合性が必要な場合には、メッセージに署名します。
メッセージ機密保護が必要な場合には、メッセージを暗号化します。
必要な公開鍵と秘密鍵を、クライアントおよびサービスのキーストアに追加します。この手順を実行するには、「メッセージ保護に関するキーストアの構成」の説明に従って、キーストアを構成しておく必要があります。
SOAPメッセージの署名および暗号化のために、WebLogicドメインのOWSMキーストアに格納する公開/秘密の署名/暗号化鍵を使用します。キーストア構成はドメイン全体に適用されるため、ドメイン内のすべてのWebサービスおよびWebサービス・クライアントがこのキーストアを使用します。
現在のリリースで使用可能なメッセージ保護ポリシーのサマリーは、第3章「使用する事前定義済ポリシーの決定」の「メッセージ保護のみのポリシー」および「メッセージ保護および認証のポリシー」を参照してください。
|
注意: 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キーストアを構成する必要があります。詳細は、以下のトピックを参照してください。
『Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスを使用したキーと証明書の管理に関する項で説明するように、OPSSキーストア・サービスでは、メッセージ・セキュリティのためにキーと証明書を管理するためのメカニズムが提供されています。これはメッセージ・セキュリティのためにキーと証明書を管理するためのデフォルトの方法です。
メッセージ保護にOPSSキーストア・サービスを使用する手順は、次のとおりです。
|
注意: OWSMの旧リリースでは、JKSキーストアがデフォルトで使用されていました。バージョン12.1.2では、OPSSキーストア・サービスは元のインストール用にデフォルトで使用されます。前のリリースからアップグレードする場合は、既存のJKSキーストアが使用されます。Fusion Middleware ControlおよびWLSTの両方を使用して、OPSSキーストア・サービス操作を実行できます。ここでは、Fusion Middleware Controlの手順に焦点を当てますが、「キーストア・サービスを使用したキーと証明書の管理」では、両方の方法について説明しています。 |
ストライプを作成し、それに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」をクリックします。
証明書はデフォルトでは、CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=USの発行元として生成されます。この発行者は、owsmストライプ内のキーストアには存在しません。この証明書を使用するには、次のいずれかのことを行う必要があります。
systemストライプ内のcastoreキーストアからdemoca証明書をエクスポートし、信頼できる証明書としてowsmストライプ内のkeystoreキーストアにインポートします。
生成した証明書をファイルにエクスポートし、CAを使用して署名したうえで、CAとその証明書をowsmストライプ内のkeystoreキーストアにインポートします。
手順の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlを使用した証明書または信頼できる証明書のインポートに関する項を参照してください。
「KSSキーストアを使用するためのOWSMの構成」の説明に従って、このキーストアと別名を使用するようにOWSMを構成します。
必要に応じて、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlを使用した証明書または信頼できる証明書のインポートに関する項の説明に従って、オプションで信頼できる証明書を取得します。
既存のJKSキーストアがある場合は、JKSキーストアからKSSキーストアに1つ以上の別名を移行できます。これを行うには、次の手順を実行します:
インポートする別名がJKSキーストア内にあることを確認します。これを実行するには、keytool(または自分で選択したツール)を使用できます。
C:\keytool -list -keystore default-keystore.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
orakey, May 16, 2013, PrivateKeyEntry,
Certificate fingerprint (SHA1): DE:0C:37:D5:34:92:00:2E:30:D7:10:EF:93:A5:C0:04:
52:02:26:B7
「コマンド行でのキーストアのインポート」の説明に従って、WLSTを使用し、コマンド行でimportKeyStoreスクリプトを使用してキーストアから1つ以上の別名をインポートできます。
例:
connect("<wls adminuser>","<wls admin password>","t3://<host>:<port>")
svc = getOpssService(name='KeyStoreService')
:
:
svc.importKeyStore(appStripe='owsm',name='keystore',password='password', aliases='orakey', keypasswords='password', type='JKS', permission=true, filepath=<'JKS keystore location'>);
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help('domainRuntime')
Keystore imported. Check the logs if any entry was skipped.
:
:
wls:/rc6_domain/serverConfig> svc.listKeyStoreAliases(appStripe="owsm",name="key
store", password='',type="*")
Already in Domain Runtime Tree
democa
orakey
wls:/rc6_domain/serverConfig>
このコマンドを使用して複数のキーをインポートするには、別名とキー・パスワードのカンマ区切りリストを指定します。KSSキーストアは、権限を使用して保護されているため、パスワードを使用しません。
OWSMドメイン構成メッセージ・セキュリティ画面を変更して、署名の別名に使用する別名をKSSキーストアから反映させて、必要に応じてその別名を暗号化します。
たとえば、JKSキーストアから別名orakeyおよびoratestをインポートしている場合は、署名の別名としてorakeyを選択し、暗号化の別名としてoratestを選択できます。
次の手順は、「KSSキーストアを使用するためのOWSMの構成」を参照してください。
『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をオーバーライドしない場合は、ユーザーの側でアクションは必要ありません。
デフォルト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
domain_home/config/fmwconfigディレクトリに移動します。domain_homeは、キーストアが使用されるドメインの名前および位置です。
鍵ペアを生成し、キーストアを作成するために(まだ作成していない場合)、次のようなkeytoolコマンドを入力します。
keytool -genkeypair -keyalg RSA -alias orakey -keypass password -keystore default-keystore.jks -storepass password -validity 3600
|
注意: keytoolコマンドを起動するために、PATH変数の定義にjdk/binディレクトリを追加することが必要になる場合があります。 |
この例の意味は次のとおりです。
genkeypairは、aliasパラメータによって指定されたエントリに格納される新しい公開鍵/秘密鍵ペアを作成します。
keyalgは、鍵のペアを生成するために使用するアルゴリズムを指定します(この例ではRSA)。
|
注意: デフォルトの鍵ペア生成アルゴリズムはDigital Signature Algorithm (DSA)です。DSA鍵は署名でのみ使用できるのに対して、RSA鍵は署名および暗号化の両方で使用できます。したがって、暗号化および署名で同じ鍵を使用する場合(一般的なシナリオ)、-keyalg RSAを明示的に指定します。そうしない場合、keytoolではDSAがデフォルトになります。 |
aliasは、鍵ペアを参照する場合に使用する別名orakeyを指定します。
keypassは、生成された鍵ペアの秘密鍵を保護するために、パスワードpasswordを使用するように指示します。
keystoreは、default-keystore.jksという名前のキーストアを作成します。キーストアがすでに存在する場合は、鍵ペアがキーストアに追加されます。
storepassは、キーストアの整合性を保護するために使用されるパスワードとしてpasswordを指定します。
validityは、keypairが3600日間有効であることを示します。
keytoolユーティリィティは、鍵の作成のために使用される名前、組織単位および組織、局所性(市区町村、都道府県、国)を尋ねるプロンプトを表示します。
What is your first and last name? [Unknown]: orcladmin What is the name of your organizational unit? [Unknown]: Doc What is the name of your organization? [Unknown]: Oracle What is the name of your City or Locality? [Unknown]: US What is the name of your State or Province? [Unknown]: US What is the two-letter country code for this unit? [Unknown]: US Is CN=orcladmin, OU=Doc, O=Oracle, L=US, ST=US, C=US correct? [no]: y
必要に応じて、「信頼できる証明書の入手と、キーストアへのインポート」の説明に従って、信頼できる証明書をキーストアにインポートします。
必要に応じて、キーストアのコンテンツを表示するためにkeytool -listコマンドを使用します。
keytool -list -keystore default-keystore.jks
プロンプトが表示されたら、キーストアの作成時に指定したキーストアのパスワードを入力します。
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: orakey
Creation date: Mar 9, 2011
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=orcladmin, OU=Doc, O=Oracle, L=US, ST=US, C=US
Issuer: CN=orcladmin, OU=Doc, O=Oracle, L=US, ST=US, C=US
Serial number: 4d77aff6
Valid from: Wed Mar 09 11:51:02 EST 2011 until: Fri Jan 15 11:51:02 EST 2021
Certificate fingerprints:
MD5: DF:EC:3C:60:CF:8B:10:A7:73:3A:51:99:4C:A3:D0:2E
SHA1: E0:52:58:EB:34:51:E4:9B:D4:13:C2:CB:F3:CC:08:89:EF:4E:4E:05
Signature algorithm name: SHA1withRSA
Version: 3
*******************************************
*******************************************
VerisignやEntrust.netのような認証局(CA)から証明書を取得し、キーストアに含めることができます。証明書を取得するには、証明書リクエストを作成してCAに送信する必要があります。CAは、証明書リクエストを認証し、リクエストに基づいてデジタル証明書を作成します。
信頼できる証明書を取得し、その証明書をキーストアにインポートするには:
秘密鍵と自己署名証明書を生成します。自己署名証明書は、信頼できる証明書に置き換えられます。
keytool -genkeypairコマンドを使用して、指定の別名に対する鍵ペアを生成します(この例ではorakey)。存在しない場合は、キーストアが作成されます。
keytool -genkeypair -keyalg RSA -alias orakey -keypass password -keystore default-keystore.jks -storepass password -validity 3600
証明書リクエストを生成します。
リクエストの生成には、keytool -certreqコマンドを使用します。次のコマンドでは、orakey別名の証明書リクエストおよびcertreq_fileという名前の証明書署名リクエスト(CSR: Certificate Signing Request)が生成されます。
keytool -certreq -alias orakey -sigalg "SHA1withRSA" -file certreq_file -storetype jks -keystore default-keystore.jks
たとえばVeriSignなどのCAにCSRファイルを送信します。CAによりリクエストが認証され、証明書または証明書チェーンが返されます。
CAの公開鍵を認証するCAルート証明書をインポートします。
keytool -importcertコマンドにより、別名verisigncaを使用して、信頼できるCAルート証明書(この例ではVerisignCAcert.cerという名前)をdefault-keystore.jksキーストアにインポートします。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。
keytool -importcert -alias verisignca -trustcacerts -file VerisignCAcert.cer -keystore default-keystore.jks
証明書リクエストに対応してCAによって発行された自己署名証明書を信頼できるCA証明書で置き換えます。
keytool -importcertコマンドを使用します。次のコマンドは、この例ではMyCertIssuedByVerisign.cerという名前の信頼できるCA証明書で、別名orakeyの自己署名証明書を置換します。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。
keytool -importcert -trustcacerts -alias orakey -file MyCertIssuedByVerisign.cer -keystore default-keystore.jks
キーストアを作成した後で、JKSキーストアを使用するようにドメイン・レベルでOWSMを構成する必要があります。これはFusion Middleware ControlまたはWLSTコマンドを使用して行うことができます。詳細については、次のセクションを参照してください。
OWSMは、保護された形式で資格証明を管理するために資格証明ストア・フレームワーク(CSF: Credential Store Framework)を使用します。CSFは、Webサービスやその他のアプリケーションの資格証明を格納、取得および削除する手段を提供します。OWSMは、次の検索のために資格証明ストアを使用します。
Javaキーストア内の鍵の別名およびパスワード。
OWSMがJavaキーストアから別名およびパスワードを検索するために資格証明ストアを使用する方法に関する詳細は、『Oracle Web Services Managerの理解』のOWSMがキーストアおよび鍵のパスワードを特定する方法に関する項を参照してください。
認証に使用されるユーザー名およびパスワード。
たとえば、認証のためにユーザー名トークンを受け入れる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」をクリックします。
サーバーを再起動します。
WLSTコマンドを使用して、次の手順に従って、資格証明ストアに鍵およびユーザー資格証明を追加します。
Oracle Fusion Middlewareを使用したWebサービスの管理のWebサービスのカスタムWLSTコマンドへのアクセスに関する項の説明に従って、WebLogic Serverの実行中のインスタンスに接続します。
connect()コマンドを使用して、実行中のWebLogic Serverインスタンスに接続します。たとえば、次のコマンドは、ユーザー名/パスワードの資格証明weblogic/passwordを使用して、URL myAdminServer.example.com:7001でWLSTを管理サーバーに接続します。
connect("weblogic","password","t3://myAdminServer.example.com:7001")
oracle.wsm.security資格証明マップ内で、たとえばServiceAおよびServiceBの別名に対応する新しいエントリを作成するために、createCredコマンドを使用しますたとえば、次のようなコマンドを使用して、ServiceAの別名のエントリcsfServiceAを作成します。
wls:/DefaultDomain/serverConfig> createCred(map="oracle.wsm.security", key="csfServiceA", user="ServiceA", password="password", desc="Key for ServiceA")
手順3を繰り返して、追加の別名のエントリ、たとえばServiceBの別名のcsfServiceBを作成します。
createCredコマンドを使用して、oracle.wsm.security資格証明マップでcsf-keyユーザー資格証明のエントリを作成します(たとえばbasic.credentialsなど)。
wls:/DefaultDomain/serverConfig> createCred(map="oracle.wsm.security", key="basic.credentials", user="AppID", password="AppPWord%", desc="Key for ServiceA")
メッセージ保護ポリシーを実装した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で証明書が公開されている場合、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を必要とするオプションがあります(たとえばoracle/wss10_username_token_with_message_protection_client_policyを参照してください)。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。
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クラスタ・トポロジは、1つ以上のWebLogic Serverクラスタまたはサーバーによって形成されます。サーバーの一部は1つ以上の記憶域無効(WebLogic Server Coherenceクライアント層)および1つ以上の記憶域有効サーバー(WebLogic Server Coherenceサーバー層)です。このトポロジには管理対象Coherenceコンテナがありません。このトポロジは通常、データ記憶域要件が低い場合(通常100 MB未満)に使用されます。
図7-8に、WebLogic Serverクラスタ内で記憶域有効および記憶域無効サーバーから構成されるトポロジを示します。2つのサーバーが記憶域有効であり、フェイルオーバーした場合は、1つのサーバーが他方のバックアップとして使用できることに注意してください。構成ウィザードを実行する場合は、すべての管理対象サーバーまたはクラスタがデフォルトでCoherenceクラスタのサーバーの一部になっています。
図7-8 ストレージ有効およびストレージ無効WebLogic Serverでのクラスタ・トポロジ
Fusion Middleware構成ウィザードの使用
『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』に記載される手順に従って、WebLogic Serverをインストールし、標準のインストール・トポロジを構成します。その標準トポロジにより、これらの要件を満たすデフォルトのCoherenceクラスタが用意されます。
構成ウィザードのドメインの作成ページで、新規拡張ドメインの作成を選択できることに注意してください。
他の構成は必要ありません。wss_username_token_client_policyおよびwss_username_token_service_policyポリシーを使用する場合は、NonceがCoherenceキャッシュに格納されます。
このCoherenceクラスタ・トポロジは1つ以上の記憶域無効WebLogic Serverクラスタまたはサーバー、および2つ以上の管理対象記憶域有効Coherenceサーバー(フェイルオーバー保護用)によって形成されます。このトポロジは通常、キャッシュ要件が高い場合(100 MBを超える)、およびWebLogic Serverがデータ・キャッシュに使用されていない場合に使用されます。このトポロジでは、キャッシュへのすべてのアクセスにはキャッシュ・サーバーへのネットワーク・ラウンドトリップが必要であることに注意してください。
|
注意: データ記憶域要件は、キャッシュの観点からみたOracle Coherenceからの一般的な推奨事項です。OWSMの場合、この要件は、キャッシュの観点からみると、非常に低いです。少なくとも2つのアプリケーション・サーバーでキャッシュを有効にしている場合(フェイルオーバー保護用)、サーバー・グループWSM-CACHE-SVRへより多くのCoherenceコンテナを追加するのはオプションです。
たとえば、アプリケーション・サーバーのすべてがダウンしたら、Nonceが失われると考える場合は、バックアップとしてCoherenceコンテナを追加する可能性があります。 |
図7-9 Coherenceクラスタ内のストレージ有効管理対象Coherenceサーバーでのクラスタ・トポロジ
Fusion Middleware構成ウィザードの使用
Fusion Middleware構成ウィザードを使用して、Nonceをキャッシュするために管理対象Coherenceサーバーをサーバー・グループに追加できます。WebLogic Server管理コンソールを使用して、ローカル記憶域が管理対象Coherenceサーバーに対して有効になっていて、記憶域がWebLogic Serverに対して無効になっていることを確認します。
|
注意: アプリケーション・サーバーでCoherence記憶域を有効にしている場合、次の手順はオプションです。管理対象CoherenceコンテナでNonceをバックアップする場合にのみ必要です。 |
Oracle Fusion Middleware for Oracle ADFのインストールおよび構成に記載される手順に従って、WebLogic Serverをインストールし、標準のインストール・トポロジを構成します。次の項を参照してください。
Oracle Fusion Middlewareインフラストラクチャ・インストールの計画に関する項
Oracle Fusion Middlewareインフラストラクチャ・ソフトウェアのインストールに関する項
Oracle Fusion Middlewareインフラストラクチャ・ドメインの構成に関する項
構成ウィザードのドメインの作成ページで、新規拡張ドメインの作成を選択できることに注意してください。
構成ウィザードの「管理対象サーバー」ページで、Coherence管理対象サーバーを特定します。Coherence管理対象サーバーの「サーバー・グループ」ドロップダウン・リストを開いて、「WSM-CACHE_SVR」を選択します。
ドメインを作成したら、WebLogic Server管理コンソールを使用して、ローカル記憶域が管理対象Coherenceサーバーに対して有効になっていて、記憶域がWebLogic Serverに対して無効になっていることを確認します。
WebLogic Server管理コンソールで、サーバー(またはクラスタ)の「構成」タブの「Coherence」サブタブの「ローカル記憶域有効」オプションを選択して、サーバー(またはクラスタ)の記憶域を有効または無効にします。
CoherenceクラスタのメンバーであるWebLogicクラスタが記憶域無効として構成されている場合、記憶域有効としてサーバーをマークする必要はないことに注意してください。(記憶域有効設定は、WebLogicクラスタおよびWebLogic Serverの「Coherence」サブタブにあります)。
wss_username_token_client_policyおよびwss_username_token_service_policyポリシーを使用する場合は、NonceがCoherenceキャッシュに格納されます。
アサーション・テンプレートでは、メッセージ本文の完全な署名および暗号化だけでなく、部分的な署名および暗号化もサポートされています。SOAPメッセージ保護が可能なアサーション・テンプレートまたは事前定義済ポリシーの場合、デフォルトの動作はSOAPメッセージ本文全体を署名および暗号化して保護することです。必要な場合には、選択した要素を保護するように、アサーションおよびポリシーを構成できます。
事前定義済メッセージ保護ポリシー用のFusion Middleware Controlユーザー・インタフェースでは、署名、暗号化またはその両方を行うメッセージ部分を簡単に指定できます。本文全体、アイデンティティ固有のヘッダー要素や本文要素に対して署名、暗号化またはその両方を行うことができます。次に、部分的な暗号化の例を示します。
この例では、Fusion Middleware Controlを使用して、SOAPメッセージの一部が暗号化されます。
クレジット・カード番号(cardNr)を承認する簡単なWebサービスを作成します。サンプルのペイロードを例7-1に示します。
例7-1 ペイロードの例
<soapenv:Body wsu:Id="Body-2grW1pYwjwsoskbLuMJZzg22"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-ws
security-utility-1.0.xsd">
<aaav:validateTheCard xmlns:aaav="http://aaavalidatecred/">
<aaav:cardNr>string</aaav:cardNr>
<aaav:firstName>string</aaav:firstName>
<aaav:lastName>string</aaav:lastName>
<aaav:validUntilDate>string</aaav:validUntilDate>
</aaav:validateTheCard>
</soapenv:Body>
Fusion Middleware Controlで、メッセージ保護ポリシーを選択し、「編集」をクリックします。
「設定」タブで、「リクエスト」タブを選択します。
「メッセージの暗号化設定」セクションで、「本体全体を含める」の選択を解除します(図7-10)。
「本体要素」を開き、「追加」をクリックします。
ネームスペースと要素名を入力します。この例では、カード番号のみが次のように暗号化されます。
Namespace = http://aaavalidatecred/
要素名 = cardNr
「ポリシーの編集」ページの他のフィールドの詳細は、「リクエスト、レスポンスおよびフォルト・メッセージへの署名と暗号化の設定」を参照してください。
「はい」をクリックして本体要素を追加し、「保存」をクリックして変更後のポリシーを保存します。
SOAPエンベロープ内に配置できないデータをアタッチメント(SwA)とともにSOAPメッセージをパッケージングすることは、標準的なことになってきています。プライマリSOAPメッセージでは、アタッチメントまたはMIMEヘッダー付きのアタッチメントとして追加のエンティティを参照できます。
各SwAアタッチメントはMIME部分であり、MIMEヘッダーを含みます。SwAアタッチメントを含めるでは、アタッチメントは署名されますが、そのアタッチメントに対応するMIMEヘッダーは署名されません。MIMEヘッダーを含めるでは、アタッチメントに加えて対応するMIMEヘッダーも署名されます。
