Oracle® Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理 12c (12.1.2) E47994-03 |
|
![]() 前 |
![]() 次 |
この章では、セキュリティ・ポリシーを使用するために、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キー・サイズを受け入れます。Oracleでは、鍵の長さは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/7/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
注意:
|
この例の意味は次のとおりです。
genkeypair
は、alias
パラメータによって指定されたエントリに格納される新しい公開鍵/秘密鍵ペアを作成します。
keyalg
は、鍵のペアを生成するために使用するアルゴリズムを指定します(この例ではRSA
)。
注意: デフォルトの鍵ペア生成アルゴリズムはDigital Signature Algorithm (DSA)です。DSA鍵は署名でのみ使用できるのに対して、RSA鍵は署名および暗号化の両方で使用できます。したがって、暗号化および署名で同じ鍵を使用する場合(一般的なシナリオ)、 |
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.xml
lファイル内で維持されます。
注意: 「OWSMキーストアの構成」の説明に従ってKSSキーストアを構成した場合、資格証明ストア 資格証明ストアは、KSSキーストアが使用されるときに、キーストア別名を格納するために使用されません。 「OWSMキーストアの構成」の説明に従ってJKSキーストアを構成した場合、指定した別名およびパスワードは資格証明ストアに安全に格納されています。ただし、キーストアに他の別名を追加するか、クライアントの認証資格証明を追加する必要がある場合、次の項の説明に従って、資格証明ストアでもそれらが構成および格納されていることを確認する必要があります。 |
Fusion Middleware ControlまたはWLSTコマンドを使用して、資格証明ストアに鍵およびユーザー資格証明を追加できます。次の手順では、両方の方法について説明します。
注意: この項で例としてと取りあげている手順では、前述の それぞれの環境では、構成に対して適切な別名およびパスワードを使用する必要があります。 資格証明ストアに鍵の資格証明を追加する前に、秘密鍵と別名が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サービスの公開証明書をそのドメイン・レベルのキーストアに格納する必要がありました。それからクライアントは |
WSDLで公開鍵証明書が見つからない場合は、かわりにkeystore.recipient.alias
プロパティが使用され、以前と同様に証明書をクライアントのドメイン・レベルのキーストアに格納する必要があります。
注意: 自己署名証明書を信頼できるものにするには、クライアント側のキーストアで使用可能にする必要があります。 |
WSDLから取り出した証明書が改ざん攻撃や中間者攻撃を受けておらず、期待通りの証明書であることを確認するホスト名検証機能が含まれています。
ホスト名を検証するために、OWSMは、証明書内の共通名(CN)またはサブジェクトのグループ・ベース識別名(DN)がサービスのホスト名と一致していることを検証します。この機能は、証明書のサブジェクトDNに依存します。デフォルトでは、ホスト名検証は無効です。
OWMではWSDLでX509証明書を公開してWebサービス・ポリシーを強制するかどうか、およびホスト名検証機能を使用するかどうかを指定できます。これらのプロパティの設定の詳細は、「Fusion Middleware Controlを使用したアイデンティティ拡張プロパティの構成」を参照してください。
注意: デフォルトでは、WSDLで証明書が公開されている場合、 |
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");
リプレイ攻撃から保護するために、ポリシーwss_username_token_client_policy
およびwss_username_token_service_policy
には、ユーザー名トークンにNonceを必要とするオプションがあります。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。
Nonceは再使用を防ぐためにキャッシュされます。ただし、クラスタ環境では、このキャッシュを管理対象サーバー間で同期化する手順が必要になります。そうしないと、Webサービスに送信されて1つのサーバーで実行中のリクエストが、リプレイされて別の管理対象サーバーに送信され、そこで処理される可能性があります。OWSMは、Oracle Coherenceキャッシュを使用してNonceをキャッシュします。
Nonceキャッシュをまとめるには、アプリケーション・サーバー(OWSMを使用)がCoherenceクラスタの一部である必要があります。デフォルトで、構成ウィザードを実行する場合は、すべての管理対象サーバーまたはクラスタはCoherenceクラスタの一部になっています。クラスタ内で、2つの記憶域有効サーバーがNonceのキャッシュには十分であり、フェイルオーバー保護を提供します。これらの2つのサーバーはアプリケーション・サーバーとすることが可能です。アプリケーション・サーバーで記憶域が無効な場合は、2つの記憶域有効キャッシュ・サーバーを提供します。
注意: これらの競合を回避するために、Coherenceクラスタ設定を構成する必要がある場合があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のCoherenceクラスタの構成と管理に関する項を参照してください。 |
環境のトポロジによって、Oracle Coherenceを有効化してNonceをキャッシュする手順は2つあります。
この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 for Oracle ADFのインストールおよび構成の次の項の手順に従って、WebLogic Serverをインストールし、標準のインストール・トポロジを構成します。次の各項を参照してください。
Oracle Fusion Middlewareインフラストラクチャ・インストールの計画に関する項
Oracle Fusion Middlewareインフラストラクチャ・ソフトウェアのインストールに関する項
Oracle Fusion Middlewareインフラストラクチャ・ドメインの構成に関する項
構成ウィザードのドメインの作成ページで、新規拡張ドメインの作成を選択できることに注意してください。
他の構成は必要ありません。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つのアプリケーション・サーバーでキャッシュを有効にしている場合(フェイルオーバー保護用)、サーバー・グループ たとえば、アプリケーション・サーバーのすべてがダウンしたら、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-12)。
「本体要素」を開き、「追加」をクリックします。
ネームスペースと要素名を入力します。この例では、カード番号のみが次のように暗号化されます。
ネームスペース = http://aaavalidatecred/
要素名 = cardNr
「ポリシーの編集」ページの他のフィールドの詳細は、「リクエスト、レスポンスおよびフォルト・メッセージへの署名と暗号化の設定」を参照してください。
「はい」をクリックして本体要素を追加し、「保存」をクリックして変更後のポリシーを保存します。
SOAPエンベロープ内に配置できないデータをアタッチメント(SwA)とともにSOAPメッセージをパッケージングすることは、標準的なことになってきています。プライマリSOAPメッセージでは、アタッチメントまたはMIMEヘッダー付きのアタッチメントとして追加のエンティティを参照できます。
各SwAアタッチメントはMIME部分であり、MIMEヘッダーを含みます。SwAアタッチメントを含めるでは、アタッチメントは署名されますが、そのアタッチメントに対応するMIMEヘッダーは署名されません。MIMEヘッダーを含めるでは、アタッチメントに加えて対応するMIMEヘッダーも署名されます。