| Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド 11g リリース1(11.1.1.7) B56247-06 |
|
 戻る |
 次へ |
この章では、セキュリティ・ポリシーのためのFusion Middleware ControlおよびWebLogic Server環境の設定方法について説明します。
この章では次の項について説明します。
SSLセキュリティ・ポリシーによるメッセージ保護および認証、またはメッセージ保護セキュリティ・ポリシーを使用するには、キーストアおよびトラストストアを設定する必要があります。(認証のみのセキュリティ・ポリシーでは鍵は不要です)。
キーストアには、エンティティ秘密鍵およびその秘密鍵に関連付けられた証明書が含まれます。トラストストアには、認証局(CA)からの証明書、またはこのエンティティが信頼する他のエンティティからの証明書が含まれます。キーストアおよびトラストストアは、Oracle Web Services Manager (WSM)などにより、共通のストア内で同時にメンテナンスできます。
Webサービスを構成する前に、必要な秘密鍵および証明書のタイプ、鍵およびキーストアの名前を決定し、それに応じて環境を設定する必要があります。
秘密鍵、デジタル証明書および信頼できる認証局(CA)によって、サーバーのアイデンティティと信頼が確立され、検証されます。
SSLでは、認証のために公開鍵暗号化テクノロジを使用します。公開鍵暗号化では、サーバーの公開鍵と秘密鍵が生成されます。公開鍵で暗号化されたデータは対応する秘密鍵でのみ復号化でき、公開鍵で検証されたデータは対応する秘密鍵でのみ署名できます。秘密鍵は、その所有者のみが公開鍵で暗号化されたメッセージを復号化できるように厳重に保護されます。
公開鍵は、公開鍵の所有者を示す他の情報(名前、住所および電子メール・アドレスなど)とともにデジタル証明書に埋め込まれています。秘密鍵およびデジタル証明書は、サーバーのアイデンティティを提供します。
デジタル証明書に埋め込まれたデータは、認証局(CA)によって検証され、その認証局のデジタル証明書を使用して署名されています。十分に認知された認証局には、VerisignやEntrust.netなどがあります。信頼できる認証局(CA)の証明書により、証明書の信頼性が確立されます。
SSL接続に参加しているアプリケーションは、そのデジタル証明書を相手が評価して受け入れた場合に認証されます。Webブラウザ、サーバーおよび他のSSL対応アプリケーションは一般に、信頼できる認証局によって署名されるか、または他の方法で有効とされているデジタル証明書を本物として受け入れます。たとえば、デジタル証明書が期限切れになったか、その署名のために使用された認証局のデジタル証明書が期限切れになったために、デジタル証明書が無効になることが考えられます。サーバーのデジタル証明書のホスト名がクライアントによって指定されたURLに一致しない場合、サーバー証明書は無効になります。
それぞれの環境で使用可能な様々なタイプの信頼できる証明書と、その利点および欠点は次のとおりです。
自己署名証明書 — 自己署名証明書は、作成元のエンティティによって署名される証明書です。
利点:
生成が容易です。たとえば、「秘密鍵の生成およびJavaキーストアの作成」の説明に従ってkeytoolコマンドを使用して自身で生成できます。
自身で生成した新しい証明書のみを使用するかぎり、本番で使用できます。
欠点
相互に通信する必要がある多数のクライアントおよびサービスが存在する場合に、自己署名証明書は短期間で管理が難くなることがあります。たとえば、2つのサービスと通信する3つのクライアントが存在する場合に、両サービスについて秘密鍵および自己署名証明書を生成し、3つのクライアントすべてのトラストストアにその2つの証明書をインポートする必要があります。
デモ用認証局(CA)署名証明書— WebLogic Serverには、開発専用のデモ用秘密鍵、デジタル証明書および信頼できる認証局のセットが含まれています。
利点:
開発環境内のデフォルトのWebLogic Serverインストールで使用可能であり、そのために構成されているので、簡単に使用できます。
欠点
本番環境では決して使用できません。デモ用証明書CAの秘密鍵は、WebLogic Serverのすべてのインストールで使用可能です。したがって、各インストールで同じ鍵を使用してデモ用CA署名証明書を生成できます。したがって、こうした証明書は信頼できません。
内部CA署名証明書 — 内部CA署名証明書は、イントラネット用に設定可能な内部CAを使用して自身で発行する証明書です。このタイプの証明書は、サービスがほとんど内部専用である場合に使用できます。
利点:
証明書を自身で作成するので、証明書の発行プロセスを完全に制御できます。証明書の発行先、証明書の有効期間などを制御できます。たとえば、パートナに証明書を発行する場合に、優良なパートナに発行先を限定できます。
欠点
すべてのクライアントでトラストストアに内部CAルート証明書がインポートされていることを確認する必要があります。
外部CA署名証明書 — 外部CA署名証明書は、VerisignやEntrust.netなどの信頼できるCAによって発行された証明書です。このタイプの証明書は、サービスが外部向けである場合に使用すべきです。
利点:
ほとんどの場合、クライアントはこうした外部CAを信頼するようにすでに設定されています。したがって、このようなクライアントでトラストストアを変更する必要はありません。
欠点
証明書発行プロセスを制御することはできません。
秘密鍵の使用を必要とするOracle WSMセキュリティ・ポリシーは、メッセージ保護および認証の2つの側面に対応します。
メッセージ保護には、メッセージ機密保護とメッセージ整合性の2つの概念があります。メッセージの機密保持では、データの機密性を維持します。そのために、メッセージのコンテンツは暗号化されます。メッセージ整合性では、送信ユーザーがメッセージにデジタル署名することによって、転送中にメッセージが変更されないことを確認します。
認証では、ユーザーが表明しているとおりのユーザーであることを検証します。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。
インストールに含まれている事前定義済のOracle WSMポリシーでは、メッセージ保護および認証に対する様々なオプションがサポートされます。これらのオプションについては、次に示す項で説明します。
|
注意: Oracle WSMポリシーで使用されるネーミング規則により、使用オプションのタイプが識別されます。たとえば、ポリシーoracle/wss10_username_token_with_message_protection_service_policyは、wss10 Webサービス標準を使用し、認証のためにusername_tokenを必要とするメッセージ保護サービス・ポリシーです。ポリシーのネーミング規則の詳細は、「ポリシーの推奨ネーミング規則」を参照してください。 |
次の項では、メッセージ保護ポリシーのタイプとその動作方法について説明します。
oracle/wss_saml_or_username_token_over_ssl_service_policyなど、SSLオプションを含むポリシーでは、メッセージ保護のために一方向SSLを使用します。このタイプのポリシーを使用する場合、次のことを実行する必要があります。
サービス側では、「SSLポリシー用の秘密鍵および証明書の設定」の説明に従って、SSL終端ポイントで秘密鍵を設定します。
クライアント側では、サービスの鍵を信頼するようにトラストストアを設定します。
秘密鍵は、クライアントとサービスが共有セッション・キーについて同意したときに、SSLハンドシェイクのためのメッセージ保護に使用されます。SSLハンドシェイクの後は、秘密鍵は使用されず、クライアント間のトラフィックおよびサービスはすべて共有セッション・キーを使用して署名および暗号化されます。
このタイプのポリシーでは、メッセージ保護にWS-Security 1.1を使用します。wss11ポリシーを使用する場合、次のことを実行する必要があります。
サービス側では、Oracle WSMの「キー・ストアの構成」画面で、秘密鍵を設定し、暗号化鍵の別名として定義します。詳細は、「Oracle WSMキーストアの構成」を参照してください。
クライアント側では、次のいずれかの方法でサーバー証明書を取得することにより、クライアント側の信頼を構成する必要があります。
「サービス・アイデンティティ証明拡張の使用」の説明に従って、サービス・アイデンティティ証明拡張を使用して、WSDL内で公開されたサービスのパブリック証明書を使用します。また、サーバー証明書を発行したCAから、サーバー証明書自体またはルート証明書のいずれかをクライアントのトラストストアにインポートする必要があります。サーバー証明書について、任意の別名を選択できます。
選択した任意の別名を使用してクライアントのキーストアにサーバー証明書をインポートします。別名は、ポリシーのアタッチ時に構成オーバーライドを使用して、keystore.recipient.aliasプロパティにより指定します。この方法では、実際のサーバー証明書をインポートする必要があります。CAルート証明書をインポートすることはできません。
各リクエストに関して、次のことが実行されます。
クライアントは対称鍵を作成し、暗号化鍵の別名により構成されたサービスの公開鍵でこの対称鍵を暗号化した後、対称鍵によりメッセージ全体の暗号化および署名を行います。
サービスがこのメッセージを受信すると、まず暗号化された鍵を復号化し、次にメッセージ全体を復号化して検証します。
次にWebサービスは、クライアントに返信するレスポンスの暗号化および署名のために、同じ対称鍵を使用します。
このタイプのポリシーでは、メッセージ保護にWS-Security 1.0を使用します。wss10ポリシーを使用する場合、次のことを実行する必要があります。
クライアント側およびサービス側の両方で秘密鍵を設定します。クライアント側で署名鍵の別名を設定し、サービス側で暗号化鍵の別名および署名鍵の別名の両方を設定する必要があります。通常は、両方で同じ鍵を使用できます。
クライアント側では、次のいずれかの方法でサーバー証明書を取得することにより、クライアント側の信頼を構成する必要があります。
「サービス・アイデンティティ証明拡張の使用」の説明に従って、サービス・アイデンティティ証明拡張を使用して、WSDL内で公開されたサービスのパブリック証明書を使用します。また、サーバー証明書を発行したCAから、サーバー証明書自体またはルート証明書のいずれかをクライアントのトラストストアにインポートする必要があります。サーバー証明書について、任意の別名を選択できます。
選択した任意の別名を使用してクライアントのキーストアにサーバー証明書をインポートします。別名は、ポリシーのアタッチ時に構成オーバーライドを使用して、keystore.recipient.aliasプロパティにより指定します。この方法では、実際のサーバー証明書をインポートする必要があります。CAルート証明書をインポートすることはできません。
サービス側では、こうした証明書を直接インポートするか、こうした証明書を発行したCAをインポートすることにより、クライアントを信頼するようにサービスを構成する必要があります。
wss11オプションの場合と同様に、クライアントは対称鍵を作成した後、サービスの公開鍵により対称鍵を暗号化します。ただし、メッセージの暗号化のためにのみこの対称鍵を使用する点が異なり、メッセージの署名のためにはこの対称鍵は使用しません。そのかわりに、クライアントは、署名鍵の別名によって定義された独自の秘密署名鍵によりリクエスト・メッセージに署名し、サービスはその秘密署名鍵によりレスポンスに署名します。
認証のためにサポートされるトークン、およびこうしたポリシー・タイプに使用される秘密鍵および証明書については、次の項で説明します。
次の項では、様々なコンテキストの様々な対象を示すために「署名鍵別名」が使用されていることに注意してください。
SAML送信者保証ポリシーでは、これはSAMLアサーションの署名に使用される鍵です。これにより、SAMLアサーションの認証性が証明されます。またSAMLログイン・モジュールは、SAMLアサーションで指定されたユーザーをアサートします。
wss10ポリシーでは、リクエストおよびレスポンス・メッセージに署名し、伝送中の改ざんを防止するために使用されます。
X.509認証ポリシーでは、特定のエンド・ユーザーを認証するために使用されます。
ユーザー名トークンは、ユーザー名やパスワードなどのBasic認証情報を伝達します。ユーザー名トークンが認証のみのポリシーとともに使用される場合、秘密鍵は使用されません。認証およびメッセージ保護を含むポリシーで使用された場合、メッセージ保護に必要な鍵が要求されます。
Kerberosトークンは、バイナリ認証およびセッション・トークンから構成されます。Kerberosトークンが認証のみのポリシーとともに使用される場合、秘密鍵は使用されません。認証およびメッセージ保護を含むポリシーで使用された場合、メッセージ保護に必要な鍵が要求されます。
送信者保証では、クライアントは自身の秘密署名鍵によりSAMLトークンに署名します。
SAML送信者保証トークンは、各メッセージ保護オプションとともに次のように使用します。
SSLを使用: SAML送信者保証では双方向SSLが必要です。したがって、クライアント側でSSL秘密鍵およびサービス側で対応する信頼証明書を設定する必要があります。SSLがOracle HTTP Serverやロード・バランサなど、WebLogic Serverの前で終端する場合、WebLogic Serverに至るまでクライアント証明書が伝播するようにこうしたレイヤーを構成する必要があります。
wss11を使用: 通常、wss11ではクライアント側の署名鍵は不要です。しかし、SAMLとともにwss11を使用する場合、クライアント側で署名鍵を設定し、署名鍵の別名を使用して構成する必要があります。また、このクライアント証明書またはその発行者をサービスのトラストストアに追加する必要があります。
wss10を使用: SAMLを使用するための追加設定は必要ありません。リクエストの署名のために使用される通常のクライアント署名鍵がSAMLトークンの署名にも使用されます。
|
注意: SAML署名鍵を使用する場合には細心の注意が必要です。これは非常に強力な鍵であり、クライアント側で任意のユーザーを偽装できます。信頼できるDNリストを設定することにより、許容されるSAML署名者の数を制限するサーバー側の構成を検討してください。信頼できるDNの設定の詳細は、「署名証明書の信頼できる発行者および信頼できるDNリストの定義」を参照してください。 |
次のリストは、SSLポリシーを使用するためにクライアント側およびサービス側で構成する必要のある鍵および信頼をまとめたものです。
サービス側の構成: SSLセキュリティ・ポリシーのために、SSL終端ポイントで秘密鍵を設定する必要があります。こうした終端ポイントは一般的に、次のいずれかから構成されます。
WebLogic ServerなどのJava EEコンテナ。構成の詳細は、「SSLに関するキーストアの構成」を参照してください。
Oracle HTTP Server(クライアントとWebLogic Server間のWebプロキシとして構成している場合)。構成の詳細は、「Oracle HTTP ServerでのSSLの構成」を参照してください。
ロード・バランサ(WebLogic ServerまたはOracle HTTP Serverの前にロード・バランサを配置している場合)。
|
注意: SSLでは、1サーバーごとに1つの秘密鍵のみを持つことができます。したがって、同じサーバー上で実行する複数のWebサービスが存在する場合は、そのすべてで同じ秘密鍵を使用します。このSSL秘密鍵は、ホスト名と同じDNで生成する必要があります。ただし、テスト目的のために、このホスト名の検証機能はクライアント側でオフにできます。 |
基本構成例: WebLogic Serverに含まれるデモ用のデジタル証明書、秘密鍵および信頼できるCA証明書を使用します。これらの鍵および証明書は、開発用にのみ提供されています。本番環境では使用しないでください。
詳細構成: 本番環境では、内部CAまたは外部CAを使用します。
クライアント側の構成: クライアント側では、クライアントのトラストストアにサーバー証明書をインポートする必要があります。サーバー側で自己署名証明書を使用している場合は、その自己署名証明書を直接含める必要があります。サーバー側でCAを使用して署名された証明書を使用している場合は、クライアント・トラストストアにそのCAルート証明書をインポートします。各タイプのWebサービス・クライアントでそのクライアント・トラストストアは異なることに注意してください。
WebLogic Server Webサービスでは、WebLogic Serverトラスト・ストアに鍵をインポートする必要があります。デモ用CA証明書は、WebLogic Serverトラストストアにすでに含まれています。
Oracle Infrastructure Webサービスでは、javax.net.ssl*システム・プロパティを使用してトラストストアを指定するか、または接続でトラストストアを指定する必要があります。詳細は、「Webサービス・クライアントに関するSSLの構成」を参照してください。
SOAコンポジット・アプリケーションでは、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の双方向SSL通信用のSOAコンポジット・アプリケーションの構成に関する項の説明に従って、javax.net.ssl*プロパティを使用してトラストストアを指定する必要があります。
非同期Webサービスでは、『Oracle Infrastructure Webサービス開発者ガイド』の非同期Webサービス用のSSLの構成に関する項の説明に従ってトラストストアを構成する必要があります。
Oracle WSMメッセージ保護セキュリティ・ポリシーでは、Oracle WSMキーストアに秘密鍵を設定する必要があります。
ドメインごとに単一のOracle WSMキーストアが存在し、ドメイン内で実行するすべてのWebサービスおよびクライアントによってそのキーストアが共有されます。このキーストアには、秘密鍵および信頼証明書の両方が含まれます。JDK cacertsファイルは、Oracle WSMによって使用されません。
基本構成例
Oracle WSMキーストアを設定する最も簡単な方法は、単一の自己署名秘密鍵を作成し、それをドメイン全体で使用することです。秘密鍵およびキーストアを作成する場合、キーストアの名前とパスワードを指定します(たとえば、キーストア名としてdefault-keystore.jks、キーストアのパスワードとしてwelcome1など)。また、秘密鍵を参照する場合に使用する別名とパスワードも指定します(たとえば、別名としてorakey、鍵のパスワードとしてwelcome1など)。署名鍵の別名と暗号化鍵の別名の両方で同じ鍵および別名を使用し、キーストアと別名の両方で同じパスワードを使用できます。秘密鍵に関連付けた証明書は、自動的に信頼できるものと見なされるので、信頼できる証明書を追加する必要はありません。
鍵およびキーストアを作成したら、キーストアのパスワードと、別名およびパスワードをOracle Web Services Managerに指定する必要があります。このために、Fusion Middleware ControlまたはWLSTのいずれかを使用できます。
「秘密鍵の生成およびJavaキーストアの作成」および「Oracle WSMキーストアの構成」の手順では、この例で指定した名前およびパスワードを使用してこの基本的な構成を設定する方法について説明しています。それぞれの環境では、構成に対して適切な名前およびパスワードを使用する必要があります。
クライアントとサーバーが同じドメインにあるかぎり、この設定はほとんどのポリシーで問題なく使用できます。つまり、SAMLの有無を問わず、任意のwss10またはwss11のポリシーを使用できます。
共通のJPSルートを共有する複数の関連ドメインが存在する場合は、すべてのドメインにこのキーストア・ファイルをコピーできます。これによって、関連するすべてのドメインがすべての暗号化および署名についてこの単一の鍵を共有します。
詳細な設定に関する考慮事項
「基本構成例」で説明したように、メッセージ保護セキュリティを設定する最も簡単な方法は、ドメイン内のすべてのWebサービスについて単一の秘密鍵を用意することです。
より機密性の高いWebサービスを得るには、独自の秘密暗号化鍵を使用するように各Webサービスを構成する必要があります。これらの秘密鍵はOracle WSMキーストアに存在する必要があります。それぞれが異なる別名(たとえばServiceAおよびServiceB)を使用し、その別名を資格証明ストアに追加していることを確認します。サービスにポリシーをアタッチした場合、Webサービスが必要とする特定の別名を示すために構成オーバーライドを使用する必要があります。そうしない場合、ドメインに対して構成したデフォルトの別名(たとえばorakey)が使用されます。
「資格証明ストアへの鍵およびユーザー資格証明の追加」の手順では、資格証明ストアにサンプルの別名を追加する方法について説明しています。
また、信頼できるCA証明書を管理する方が格段に容易であるために、自己署名証明書ではなく内部CAまたは外部CAによって発行された信頼できる証明書を使用すべきです。ただし、「署名証明書の信頼できる発行者および信頼できるDNリストの定義」の説明に従って、SAML署名者の信頼できるDNリストを設定するようにしてください。これは、Oracle WSMキーストアに外部CA証明書をインポートした場合に特に重要です。そうしない場合、証明書を持つ任意のユーザーがSAMLトークンに署名し、任意のユーザーを偽装できることになります。
メッセージ保護では、メッセージ機密保護のためのメッセージの暗号化と、メッセージ整合性のためのメッセージへの署名が行われます。SOAPメッセージの署名および暗号化のために、WebLogicドメインのOracle Web Services Manager (WSM)キーストアに格納する公開/秘密の署名/暗号化鍵を使用します。キーストアの構成はドメイン単位で行います。ドメイン内のすべてのWebサービスおよびWebサービス・クライアントはこのキーストアを使用します。
|
注意: Oracle WSMランタイムでは、WebLogic Server管理コンソールにより構成され、「SSLに関するキーストアの構成」の記載に従ってSSL用に使用されるWebLogic Serverキーストアは使用しません。 |
メッセージ保護のためにJavaキーストアを作成および構成するには、次の項の手順に従います。
次の項では、keytoolユーティリィティを使用して秘密鍵ペアおよびJavaキーストア(JKS)を作成する方法について概要を示します。keytoolユーティリティのコマンドや引数の詳細は、次のWebサイト・アドレスにアクセスして参照してください。
http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html
domain_home/config/fmwconfigディレクトリに移動します。domain_homeは、キーストアが使用されるドメインの名前および位置です。
鍵ペアを生成し、キーストアを作成するために(まだ作成していない場合)、次のようなkeytoolコマンドを入力します。
keytool -genkeypair -keyalg RSA -alias orakey -keypass welcome1 -keystore default-keystore.jks -storepass welcome1 -validity 3600
|
注意:
|
各項目の意味は次のとおりです。
genkeypairは、aliasパラメータによって指定されたエントリに格納される新しい公開鍵/秘密鍵ペアを作成します。
keyalgは、鍵のペアを生成するために使用するアルゴリズムを指定します(この例ではRSA)。
|
注意: デフォルトの鍵ペア生成アルゴリズムはDigital Signature Algorithm(DSA)です。DSA鍵は署名でのみ使用できるのに対して、RSA鍵は署名および暗号化の両方で使用できます。したがって、暗号化および署名で同じ鍵を使用する場合(一般的なシナリオ)、 |
aliasは、鍵ペアを参照する場合に使用する別名orakeyを指定します。
keypassは、生成された鍵ペアの秘密鍵を保護するために、パスワードwelcome1を使用するように指示します。
keystoreは、default-keystore.jksという名前のキーストアを作成します。キーストアがすでに存在する場合は、鍵ペアがキーストアに追加されます。
storepassは、キーストアの整合性を保護するために使用されるパスワードとしてwelcome1を指定します。
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
*******************************************
*******************************************
次の項では、Oracle WSMキーストアを構成するために、Oracle Enterprise Manager Fusion Middleware Controlを使用する方法について説明します。キーストアの構成には、この方法を使用することをお薦めします。環境にFusion Middleware Controlが含まれていない場合は、「WLSTの使用」に従って、WebLogic Scripting Tool (WLST) コマンドを使用することもできます。
Oracle WSMキーストアを構成するためにFusion Middleware Controlを使用する場合、資格証明マップoracle.wsm.securityおよび定義したすべての鍵について、資格証明ストア内にエントリが作成されます。キーストアを構成するには、次の手順を実行します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
図10-1に示すように、W「WebLogicドメイン」メニューから、「セキュリティ」、「セキュリティ・プロバイダ構成」の順に選択します。
図10-2に示すように、「セキュリティ・プロバイダ構成」ページが表示されます。
ページの「キー・ストア」セクションで「構成」をクリックします。
図10-3に示すように、「キー・ストアの構成」ページが表示されます。
「KeyStoreタイプ」ドロップ・ダウンで、まだ選択していない場合は、「Javaキー・ストア(JKS)」を選択します。
|
注意: また、ハードウェア・セキュリティ・モジュール(HSM)も、Oracle Advanced Securityで動作することが証明されています。詳細は、「Oracle WSMでのハードウェア・セキュリティ・モジュールの使用」を参照してください。 また、「暗号化アクセラレーションのためのメッセージ・レベル・セキュリティの構成」の手順6に記載されているように、暗号化アクセラレーションを使用する場合に、公開鍵暗号化標準(PKCS-11)を選択できます。ハードウェア・トークン・サポートが必要な場合、PKCS-11キーストア・タイプを使用します。 |
ページの「アクセス属性」セクションで、キーストアの名前とパス、およびパスワードを次のように入力します。
「キーストア・パス」フィールドで、「秘密鍵の生成およびJavaキーストアの作成」の説明に従って作成したキーストアのパスと名前を入力します。このフィールドはデフォルトでは./default-keystore.jksになります。これは、domain_name/config/fmwconfigディレクトリに位置するデフォルトのJavaキーストアの名前default-keystore.jksを表します。キーストアで異なる名前または位置を使用した場合は、かわりにその値を入力します。
「パスワード」フィールドおよび「パスワードの確認」フィールドで、キーストアのパスワードを入力します。このパスワードは、「秘密鍵の生成およびJavaキーストアの作成」の説明に従って、keytoolユーティリィティを使用してキーストアを作成したときに使用したパスワードに一致する必要があります(例: welcome1など)。
ページの「アイデンティティ証明書」セクションで、署名鍵と暗号化鍵の別名とパスワードを次のように入力します。
署名鍵について、「キーの別名」フィールドに別名、「署名のパスワード」フィールドおよび「パスワードの確認」フィールドに別名のパスワードを入力します。ここで指定する値は、キーストアの値に一致する必要があります。たとえばorakeyおよびwelcome1を指定します。
暗号化鍵について、「暗号化の別名」フィールドに別名、「暗号化のパスワード」フィールドおよび「パスワードの確認」フィールドに別名のパスワードを入力します。ここで指定する値は、キーストアの値に一致する必要があります。たとえばorakeyおよびwelcome1を指定します。
署名と暗号化キーの別名とパスワードによって、鍵の格納と取得に使用される文字列の別名とパスワードが定義されます。これらの値は、資格証明ストア内でsign-csf-keyおよびenc-csf-keyとして作成されます。
「OK」をクリックして変更内容を送信します。
ファイルベースのキーストア・プロバイダを使用した場合は、変更を有効にするためにサーバーを再起動する必要があります。データベースまたはLDAPベースのキーストア・サービス・プロバイダでは、再起動は必要ありません。
次の手順に従って、WLSTコマンドを使用して、Oracle WSMキーストアにアクセスするために資格証明ストアを構成します。
インストールのために、Oracleの共通ホーム・ディレクトリ、たとえば/home/Oracle/Middleware/oracle_commonに移動します。
Oracleの共通ホーム・ディレクトリとOracle Fusion Middlewareのインストールの詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』を参照してください。
oracle_common/common/binディレクトリにあるWLST.sh/cmdコマンドを使用して、WLSTを起動します。たとえば、次のようにします。
/home/Oracle/Middleware/oracle_common/common/bin/wlst.sh(UNIX)
C:\Oracle\Middleware\oracle_common\common\bin\wlst.cmd(Windows)
これらのコマンドを実行すると、WLSTがオフライン・モードで起動されます。資格証明ストアのWLSTコマンドを使用するには、WLSTをオンライン・モードで使用する必要があります。
Oracle WebLogic Serverを起動します。
詳細は、Oracle WebLogic Server管理コンソールのヘルプのサーバーの起動と停止に関する項を参照してください。
connect()コマンドを使用して、実行中のWebLogic Serverインスタンスに接続します。たとえば、次のコマンドは、ユーザー名/パスワードの資格証明weblogic/welcome1を使用して、URL myAdminServer.example.com:7001でWLSTを管理サーバーに接続します。
connect("weblogic","welcome1","t3://myAdminServer.example.com:7001")
次のようにして、キーストアの名前およびパスワードとして、資格証明ストア内でエントリを作成するためにcreateCredコマンドを入力します。
createCred(map="oracle.wsm.security", key="keystore-csf-key", user="owsm", password="welcome1", desc="Keystore key")
userに対して、任意の値を入力できることに注意してください。このフィールドは、keystore-csf-keyエントリでは無視されます。passwordの値は、「秘密鍵の生成およびJavaキーストアの作成」の説明に従ってキーストアを作成したときに指定したパスワード(この例ではwelcome1)に一致する必要があります。
次のようにして、署名鍵の別名およびパスワードとして、資格証明ストア内でエントリを作成するためにcreateCredコマンドを入力します。
createCred(map="oracle.wsm.security", key="sign-csf-key", user="orakey", password="welcome1", desc="Signing key")
userおよびpasswordの値は、「秘密鍵の生成およびJavaキーストアの作成」の説明に従ってキーストアを作成したときに指定したキーストア内の署名鍵の別名およびパスワードに一致する必要があります。この例では、値はorakeyおよびwelcome1です。
次のようにして、暗号化鍵の別名およびパスワードとして、資格証明ストア内でエントリを作成するためにcreateCredコマンドを入力します。
createCred(map="oracle.wsm.security", key="enc-csf-key", user="orakey", password="welcome1", desc="Encryption key")
userおよびpasswordの値は、「秘密鍵の生成およびJavaキーストアの作成」の説明に従ってキーストアを作成したときに指定したキーストア内の暗号化鍵の別名およびパスワードに一致する必要があります。この例では、値はorakeyおよびwelcome1です。
VerisignやEntrust.netのような認証局(CA)から証明書を取得し、キーストアに含めることができます。証明書を取得するには、証明書リクエストを作成してCAに送信する必要があります。CAは、証明書リクエストを認証し、リクエストに基づいてデジタル証明書を作成します。
信頼できる証明書を取得し、その証明書をキーストアにインポートするには:
秘密鍵と自己署名証明書を生成します。自己署名証明書は、信頼できる証明書に置き換えられます。
keytool -genkeypairコマンドを使用して、指定の別名に対する鍵ペアを生成します(この例ではorakey)。存在しない場合は、キーストアが作成されます。
keytool -genkeypair -keyalg RSA -alias orakey -keypass welcome1 -keystore default-keystore.jks -storepass welcome1 -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
クライアントのX.509トークンで必要な署名と暗号化キーを格納するには、Javaキーストア(JKS)のキーストアを作成する必要があります。鍵は、認証やデータ整合性など、様々な用途に使用されます。たとえば、次のようにします。
データに署名するには、署名者の秘密鍵が必要です。
署名を検証するには、信頼できるCA証明書と、秘密鍵に一致する公開鍵が必要です。
データを暗号化するには、受信者の公開鍵が必要です。「サービス・アイデンティティ証明拡張の使用」で説明されているように、Webサービスのbase64エンコードされた公開証明書は、Webサービス・クライアントが使用するためにWSDLでパブリッシュされます。
データを復号化するには、公開鍵に対応する秘密鍵が必要です。
これらの信頼できる証明書、公開鍵および秘密鍵はキーストアに格納されます。次の項では、様々なタイプのメッセージ保護ポリシーの要件、こうしたキーストアを作成および使用する方法、および信頼できる証明書を入手する方法について説明しています。
Oracle WSMは、保護された形式で資格証明を管理するために資格証明ストア・フレームワーク(CSF: Credential Store Framework)を使用します。CSFは、Webサービスやその他のアプリケーションの資格証明を格納、取得および削除する手段を提供します。Oracle WSMは、次の検索のために資格証明ストアを使用します。
Javaキーストア内の鍵の別名およびパスワード
Oracle WSMがJavaキーストアから別名およびパスワードを検索するために資格証明ストアを使用する方法に関する詳細は、「Oracle WSMがキーストアおよび鍵のパスワードを特定する方法」を参照してください。
認証に使用されるユーザー名およびパスワード
たとえば、認証のためにユーザー名トークンを受け入れる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ファイル内で維持されます。
「Oracle WSMキーストアの構成」の説明に従って、Fusion Middleware Controlを使用してOracle WSMキーストアを構成した場合、指定した別名およびパスワードが資格証明ストアに安全に格納されます。ただし、キーストアに他の別名を追加するか、クライアントの認証資格証明を追加する必要がある場合、次の項の説明に従って、資格証明ストアでもそれらが構成および格納されていることを確認する必要があります。
Fusion Middleware ControlまたはWLSTコマンドを使用して、資格証明ストアに鍵およびユーザー資格証明を追加できます。次の手順では、両方の方法について説明します。
|
注意: この項の例の手順では、前述したように、 資格証明ストアに鍵の資格証明を追加する前に、秘密鍵と別名がキーストアに存在することを確認します。これは、次のようなコマンドを使用して作成できます。 keytool -genkeypair -keyalg RSA -alias ServiceA -keypass welcome1 -keystore default-keystore.jks -storepass welcome1 -validity 3600 keytool -genkeypair -keyalg RSA -alias ServiceB -keypass welcome3 -keystore default-keystore.jks -storepass welcome1 -validity 3600 キーストアの詳細は、「秘密鍵の生成およびJavaキーストアの作成」を参照してください。 |
Fusion Middleware Controlで次の手順に従って資格証明ストアに鍵と証明書を追加します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
「WebLogicドメイン」メニューで、「セキュリティ」→「資格証明」を選択します。
図10-5に示すように、「資格証明」ページが表示されます。
この構成では、資格証明ストアにoracle.wsm.security資格証明マップがすでに存在することに注意してください。この資格証明マップは、「Oracle WSMキーストアの構成」の説明に従ってOracle WSMキーストアを構成したときに作成されたものです。この資格証明マップが構成に表示されない場合は、「マップの作成」ボタンをクリックし、「マップ名」フィールドに「oracle.wsm.security」と入力することにより作成できます。
必要に応じて、マップで構成された鍵を表示するために、「資格証明」表でoracle.wsm.securityマップを開きます。図10-6に、サンプルのOracle WSM資格証明ストアの構成を示します。
鍵を選択し、「編集」をクリックすることにより、資格証明マップで鍵を編集できます。資格証明ストアで加えるすべての変更がOracle WSM Javaキーストア内の鍵の定義に準拠することに注意してください。
oracle.wsm.security資格証明マップ内で、たとえばServiceA およびServiceBの別名に対応する新しいエントリを作成するために、「キーの作成」をクリックします。図10-7に示すように、「キーの作成」ダイアログ・ボックスが表示されます。
「マップの選択」メニューから、まだ選択されていない場合は、マップ名「oracle.wsm.security」を選択します。
キーストアにアクセスするための鍵と値のペアを作成するために、「キー」フィールドに「csfServiceA」と入力します。
「タイプ」メニューから、「パスワード」を選択します。
「ユーザー名」フィールドで、キーストアで秘密鍵に指定した別名(たとえばServiceA)を入力します。
「パスワード」フィールドおよび「パスワードの確認」フィールドで、キーストアで別名のために指定したパスワード(たとえばwelcome1)を入力します。
「説明」フィールドで、エントリの説明を入力します(たとえば、「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の共通ホーム・ディレクトリ、たとえば/home/Oracle/Middleware/oracle_commonに移動します。
Oracleの共通ホーム・ディレクトリとOracle Fusion Middlewareのインストールの詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』を参照してください。
oracle_common/common/binディレクトリにあるWLST.sh/cmdコマンドを使用して、WLSTを起動します。たとえば、次のようにします。
/home/Oracle/Middleware/oracle_common/common/bin/wlst.sh(UNIX)
C:\Oracle\Middleware\oracle_common\common\bin\wlst.cmd(Windows)
これらのコマンドを実行すると、WLSTがオフライン・モードで起動されます。資格証明ストアのWLSTコマンドを使用するには、WLSTをオンライン・モードで使用する必要があります。
Oracle WebLogic Serverを起動します。
詳細は、Oracle WebLogic Server管理コンソールのヘルプのサーバーの起動と停止に関する項を参照してください。
connect()コマンドを使用して、実行中のWebLogic Serverインスタンスに接続します。たとえば、次のコマンドは、ユーザー名/パスワードの資格証明weblogic/welcome1を使用して、URL myAdminServer.example.com:7001でWLSTを管理サーバーに接続します。
connect("weblogic","welcome1","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="welcome1", desc="Key for ServiceA")
手順5を繰り返して、追加の別名のエントリ、たとえば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")
Oracle WSMでは、キーストアおよび鍵のパスワードが資格証明ストア・フレームワーク(CSF)に格納されていることが求められます。次に、このしくみを示します。
JKSキーストア・ファイルは、キーストアのパスワードによって保護されています。
キーストア・ファイルは、0個以上の秘密鍵および0個以上の信頼できる証明書から構成されます。各秘密鍵は、独自のパスワードを持ちます(ただし、鍵のパスワードとキーストアのパスワードが同じであることが一般的です)。Oracle WSMでは、キーストアのパスワードと鍵のパスワードの両方を認識している必要があります。
CSFは、それぞれが個別の名前を持つ多数のマップから構成されます。Oracle WSMは、マップoracle.wsm.securityのみを使用します。
各マップ内部で、複数のcsf-keyエントリから対応する資格証明にマッピングされています。csf-keyは、簡単な名前ではあっても、様々なタイプの資格証明が考えられます。最も一般的なタイプの資格証明は、主にユーザー名とパスワードで構成されるパスワード資格証明です。
Oracle WSMでは、oracle.wsm.securityマップ内で次のcsf-keyを参照します。
keystore-csf-key - この鍵には、キーストアのパスワードを含める必要があります。ユーザー名は無視されます。
enc-csf-key - この鍵には、ユーザー名として暗号化鍵の別名、および対応する鍵のパスワードを含める必要があります。
sign-csf-key - この鍵には、ユーザー名として署名鍵の別名、および対応する鍵のパスワードを含める必要があります。
こうしたcsf-keyに加えて、たとえば構成オーバーライドで署名鍵および暗号化鍵を指定する場合に、Oracle WSMで使用する新しい各秘密鍵についてcsf-keyエントリを追加する必要があります。
図10-8に、OPSS内のキーストア構成、資格証明ストア内のoracle.wsm.securityマップおよびOracle WSM Javaキーストアの関係を示します。
図を見ると次のことがわかります。
keystore.csf.mapプロパティは、CSFの別名を含む資格証明ストア内のOracle WSMマップを参照します。この場合、keystore.csf.mapはお薦めの名前であるoracle.wsm.securityとして定義されていますが、任意の値でかまいません。
keystore.pass.csf.keyプロパティは、キーストアのユーザー名およびパスワードにマッピングされたCSFの別名keystore-csf-keyを参照します。パスワードのみが使用されます。キーストアの場合、ユーザー名は冗長です。
keystore.sig.csf.keyプロパティは、署名に使用される秘密鍵のユーザー名およびパスワードにマッピングされたCSFの別名sign-csf-keyを参照します。
keystore.enc.csf.keyプロパティは、復号化に使用される秘密鍵のユーザー名およびパスワードにマッピングされたCSFの別名enc-csf-keyを参照します。
『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「キーストア・サービスを使用したキーと証明書の管理」の説明のとおり、OPSSキーストア・サービスは、メッセージ・セキュリティのための鍵および証明書を管理するための代替メカニズムです。OPSSキーストア・サービスを使用して、KSSタイプのキーストアを作成して管理します。
|
注意: キーストアはエクスポートおよびインポートできます。JKSおよびJCEKSの証明書形式に対して移行がサポートされます。 |
ドメインごとに単一のOracle WSMキーストアが存在し、ドメイン内で実行するすべてのWebサービスおよびクライアントによってそのキーストアが共有されます。したがって、この項の説明に従ってKSSキーストアを構成した場合、Oracle WSMではそのKSSキーストアのみが使用され、それとともに定義されているJKSキーストアは無視されます。
Fusion Middleware ControlおよびWLSTの両方を使用して、OPSSキーストア・サービス操作を実行できます。ここでは、Fusion Middleware Controlの手順に焦点を当てますが、「キーストア・サービスを使用したキーと証明書の管理」では、両方の方法について説明しています。
次の手順に従って、メッセージの保護のためにOPSSキーストア・サービスを構成します。
ストライプを作成し、それにowsmという名前を付けます(詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したキーストアの作成に関する項を参照してください)。
「WebLogicドメイン」メニューから、「セキュリティ」、「キー・ストア」の順に選択します。
「ストライプの作成」をクリックします。図10-9に、「ストライプの作成」画面を示します。
「owsm」と入力し、「OK」をクリックします。この名前を使用する必要があります。
owsmストライプ内で、 keystoreという名前のキーストアを作成します(詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用したキーストアの作成に関する項を参照してください)。
作成したowsmストライプを選択し、「キーストアの作成」をクリックします。
図10-10に、「キーストアの作成」画面を示します。
このキーストアにkeystoreという名前を付けます。この名前を使用する必要があります。
保護タイプを「ポリシー」に設定します。
「権限の付与」チェック・ボックスの選択を解除します。
「コード・ベースURL」フィールドには値を指定しないでください。
「OK」をクリックします。
先に作成したキーストアを選択し、「管理」をクリックします。
図10-11に、「証明書の管理」画面を示します。
「鍵ペアの生成」をクリックして、秘密鍵/公開鍵のペアを生成します。
一般的に、署名および暗号化の両方のリクエストに対してこの鍵ペアを使用します。ただし、必要に応じて、署名および暗号化で別個の鍵ペアを作成できます。
図10-12に、「鍵ペアの生成」画面を示します。
鍵ペアに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 WSMを構成します。
図10-13に示すように、W「WebLogicドメイン」メニューから、「セキュリティ」、「セキュリティ・プロバイダ構成」の順に選択します。
図10-14に示すように、「セキュリティ・プロバイダ構成」ページが表示されます。
ページの「キー・ストア」セクションで「構成」をクリックします。
図10-15に示すように、「キー・ストアの構成」ページが表示されます。
「キーストア・タイプ」フィールドで、タイプとして「キーストア・サービス(KSS)」を選択します。
図10-16に示すように、KSSの構成ページが表示されます。
ページの「アイデンティティ証明書」セクションで、署名鍵と暗号化鍵の別名を次のように入力します。
署名鍵について、「キーの別名」フィールドに別名を入力します。ここで指定する値は、キーストアの値に一致する必要があります。たとえば、「orakey」と入力します。
暗号化鍵について、「暗号化の別名」フィールドに別名を入力します。ここで指定する値は、キーストアの値に一致する必要があります。たとえば、「orakey」と入力します。
署名鍵と暗号化鍵の別名は、鍵の格納と取得に使用されます。
|
注意: 「Oracle WSMキーストアの構成」の説明に従って、Oracle WSMキーストアの構成のためにFusion Middleware Controlを使用した場合、Oracle WSMにより資格証明ストア内に資格証明マップ これは、KSSキーストアの場合も同様ですが、1つ大きな違いがあります。KSSキーストアでは、資格証明ストア内に作成された |
「OK」をクリックして変更内容を送信します。
ファイルベースのキーストア・プロバイダを使用した場合は、変更を有効にするためにサーバーを再起動する必要があります。データベースまたはLDAPベースのキーストア・サービス・プロバイダでは、再起動は必要ありません。
必要に応じて、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のFusion Middleware Controlを使用した証明書または信頼できる証明書のインポートに関する項の説明に従って、信頼できる証明書を取得します。
「Webサービス・クライアント・キーストアの設定」の説明に従って、Webサービス・クライアント・キーストアを設定します。
「SSLの構成が必要なポリシー」または「双方向SSLの構成が必要なポリシー」にあげたポリシーを使用する場合、SSL用のキーストアを構成する必要があります。
SSLでは、ネットワークを介して接続される2つのアプリケーションが互いのアイデンティティを認証できるようにし、アプリケーション間で交換されるデータを暗号化することで、安全な接続を提供します。
認証によって、サーバーと、必要に応じてクライアントが、ネットワーク接続の反対側にあるアプリケーションのアイデンティティを検証できます。暗号化によって、ネットワーク上で伝送されるデータを意図した受信者のみが認識できるようになります。クライアント証明書(双方向SSL)は、ユーザーの認証に使用できます。
この項では、SSL経由でリクエストを送信するようにWebサービス・クライアントとWebLogic Server Webサービス・コンテナを設定する方法を説明します。
Webサービス・アプリケーションでSSLを使用するには、次の作業を実行する必要があります。
WebLogic ServerのキーストアとSSL設定を構成します。
Webサービス・クライアントのキーストアとSSL設定を構成します。
これらの手順については、次の項で説明します。
SSLの構成が必要な事前定義済ポリシーは次のとおりです。
oracle/wss_http_token_over_ssl_service_policy
oracle/wss_http_token_over_ssl_client_policy
oracle/wss_saml_token_bearer_over_ssl_server_policy
oracle/wss_saml_token_bearer_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policy
oracle/wss_saml_token_over_ssl_client_policy
oracle/wss_sts_issued_saml_bearer_token_over_ssl_client_template
oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_template
oracle/wss_username_token_over_ssl_service_policy
oracle/wss_username_token_over_ssl_client_policy
さらに、次のテンプレートを使用して、SSLを必要とする新しいポリシーを作成できます。
oracle/wss_http_token_over_ssl_service_template
oracle/wss_http_token_over_ssl_client_template
oracle/wss_saml_token_bearer_over_ssl_service_template
oracle/wss_saml_token_bearer_over_ssl_client_template
oracle/wss_saml_token_over_ssl_service_template
oracle/wss_saml_token_over_ssl_client_template
oracle/wss_sts_issued_saml_bearer_token_over_ssl_client_template
oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_template
oracle/wss_username_token_over_ssl_service_template
oracle/wss_username_token_over_ssl_client_template
これらのアサーションおよびポリシーの詳細は、付録C「事前定義済アサーション・テンプレート」および付録B「事前定義済ポリシー」を参照してください。
双方向SSLの構成が必要な事前定義済ポリシーは次のとおりです。
oracle/wss_saml_token_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policy
oracle/wss_username_token_over_ssl_client_policy(相互認証を選択した場合)
oracle/wss_username_token_over_ssl_service_policy(相互認証を選択した場合は、)
oracle/wss_http_token_over_ssl_client_policy(相互認証を選択した場合)
oracle/wss_http_token_over_ssl_service_policy(相互認証を選択した場合)
さらに、次のテンプレートを使用して、双方向SSLを必要とする新しいポリシーを作成できます。
oracle/wss_saml_token_over_ssl_client_template
oracle/wss_saml_token_over_ssl_service_template
秘密鍵、デジタル証明書および信頼できる認証局(CA)証明書によって、WebLogic Server環境でアイデンティティと信頼が確立され、検証されます。
この項では、WebLogic Serverにキーストアを構成するために必要な手順の概要を説明します。詳細は、次の2つの資料を参照してください。
詳細は、Oracle WebLogic Server管理コンソールのヘルプ。特に「サーバー: 構成: キーストア」に関するトピック。
Securing Oracle WebLogic Server。特にアイデンティティと信頼の構成に関する項。
WebLogic Serverには、デフォルトのアイデンティティ・キーストアDemoIdentity.jksとデフォルトの信頼キーストアDemoTrust.jksが構成されています。さらに、WebLogic Serverでは、JDKのcacertsファイル内の認証局を信頼しています。このデフォルトのキーストア構成は、テストや開発を目的とする場合に適しています。ただし、これらのキーストアは本番環境では使用しないでください。
サーバーのアイデンティティと信頼を構成する手順は次のとおりです。
keytoolユーティリティまたはEntrust社やVerisign社のような信頼できるベンダーから、デジタル証明書、秘密鍵および信頼できるCA証明書を取得し、キーストアに含めます。
証明書を取得するには、証明書リクエストを作成してCAに送信する必要があります。CAは、証明書リクエストを認証し、リクエストに基づいてデジタル証明書を作成します。
秘密鍵、デジタル証明書および信頼できる認証局(CA)には、Privacy Enhanced Mail(PEM)形式を使用することをお薦めします。
keytoolユーティリティを使用する場合、デフォルトの鍵のペア生成アルゴリズムはDigital Signature Algorithm(DSA)です。WebLogic ServerではDSAはサポートされていません。WebLogic Serverを使用する場合は、RSAなど、別の鍵のペア生成および署名アルゴリズムを指定してください。keytoolユーティリティの詳細は、「keytool - Key and Certificate Management Tool」(http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html)の説明を参照してください。
WebLogic Serverキットで提供されるデジタル証明書、秘密鍵および信頼できるCA証明書も使用できます。デモ用のデジタル証明書、秘密鍵および信頼できるCA証明書は、開発環境でのみ使用してください。
アイデンティティ用に1つと信頼用に1つ、キーストアを作成します。キーストア形式にはJavaキーストア(JKS)を使用することをお薦めします。
秘密鍵と信頼できるCAをキーストアにロードします。
コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。
アイデンティティと信頼キーストアを構成するサーバーの名前をクリックします。
「構成」→「キーストア」を選択します。
「キーストア」フィールドで、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書を格納および管理する方法を選択します。選択できるオプションは次のとおりです。
カスタムIDとカスタム信頼: ユーザーが作成するアイデンティティと信頼キーストア。
デモIDとデモ信頼: デモ用のアイデンティティと信頼キーストア。..\server\libディレクトリおよびJDK cacertsキーストアにあり、デフォルトで構成されています。開発目的にのみ使用してください。
カスタムIDとJava標準信頼: ユーザーが作成するキーストアと、JAVA_HOME\jre\lib\securityディレクトリのcacertsファイルに定義されている信頼できるCA。
カスタムIDとコマンドライン信頼: ユーザーが作成するアイデンティティ・キーストアと、信頼キーストアの場所を指定するコマンドライン引数。
「ID」セクションで、アイデンティティ・キーストアの属性を定義します。
カスタムIDキーストア: アイデンティティ・キーストアへの完全修飾パス。
カスタムIDキーストアのタイプ: キーストアのタイプ。一般に、この属性にはJavaキーストア(JKS)を指定します。空白のままにすると、デフォルトでJKSに設定されます。
カスタムIDキーストアのパスフレーズ: キーストアの読取りまたは書込み時に入力するパスワード。この属性は、キーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。
|
注意: デモ・アイデンティティ・キーストアのパスフレーズは、DemoIdentityKeyStorePassPhraseです。 |
「信頼」セクションで、信頼キーストアのプロパティを定義します。
キーストアとして「Java標準信頼キーストア」を選択する場合、キーストアの作成時に定義したパスワードを指定します。パスワードを確認します。
カスタム信頼を選択した場合、次の属性を定義します。
カスタム信頼キーストア: 信頼キーストアへの完全修飾パス。
カスタム信頼キーストアのタイプ: キーストアのタイプ。一般に、この属性にはJKSを指定します。空白のままにすると、デフォルトでJKSに設定されます。
カスタム信頼キーストアのパスフレーズ: キーストアの読取りまたは書込み時に入力するパスワード。この属性は、キーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。
変更内容は自動的にアクティブ化されます。
一方向SSLでは、サーバーはクライアントに証明書を提示する必要がありますが、クライアントがサーバーに証明書を提示する必要はありません。
「SSLに関するキーストアの構成」の説明に従ってWebLogic Serverインスタンスのアイデンティティと信頼キーストアを構成したら、そのSSL属性を構成します。これらの属性では、「構成: キーストア」ページで指定したキーストア内のアイデンティティ鍵と証明書の場所を示します。この情報を指定するには、「構成: SSL」ページを使用します。
この項では、WebLogic ServerにSSLを構成するために必要な手順の概要を説明します。詳細は、『Securing Oracle WebLogic Server』を参照してください。
SSLを構成する手順
WebLogic Server管理コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。
SSLを構成するサーバーの名前をクリックします。
「構成」→「SSL」ページを選択し、WebLogic Serverのアイデンティティ(証明書と秘密鍵)と信頼(信頼できるCA)の場所を選択します。
秘密鍵の別名とパスワードのSSL属性を設定します。
ページの下部で、「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
WebLogic Serverが内部サーバーとエクスポート可能クライアントとの間で何回エクスポート可能鍵を使用したら新しい鍵を生成する必要があるか、使用できる回数を指定します。新しい鍵を生成するまでに鍵を使用する回数が少ないほど、WebLogic Serverのセキュリティが強化されます。
「相互クライアント証明書の動作」コントロールを「クライアント証明書を要求しない」に設定します。
インバウンドとアウトバウンドのSSL証明書検証方法を指定します。選択できるオプションは次のとおりです。
組込みSSLの検証のみ: 組込みの信頼できるCAベースの検証を使用します。これがデフォルトです。
組込みSSLの検証および証明書パス検証プロバイダ: 組込みの信頼できるCAベースの検証を使用し、追加の検証を実行するために構成済のCertPathValidatorプロバイダを使用します。
双方向SSLでは、サーバーはクライアントに、またクライアントはサーバーに証明書を提示します。SSLハンドシェイクを完了する前に、クライアントに有効で信頼できる証明の送信を要求するようにWebLogic Serverを構成できます。
「SSLに関するキーストアの構成」の説明に従って、WebLogic Serverインスタンスのアイデンティティと信頼キーストアを構成した後、使用するポリシーまたはテンプレートで必要な場合は、「双方向SSLの構成が必要なポリシー」の説明に従って双方向SSL属性を構成できます。
この項では、WebLogic ServerにSSLを構成するために必要な手順の概要を説明します。詳細は、『Securing Oracle WebLogic Server』を参照してください。
双方向SSLの構成手順は次のとおりです。
WebLogic Server管理コンソールの左側のペインで、「環境」を開き、「サーバー」を選択します。
SSLを構成するサーバーの名前をクリックします。
「構成」→「SSL」ページを選択し、WebLogic Serverのアイデンティティ(証明書と秘密鍵)と信頼(信頼できるCA)の場所を選択します。
秘密鍵の別名とパスワードのSSL属性を設定します。
ページの下部で、「詳細」をクリックします。
「ホスト名の検証」を「なし」に設定します。
WebLogic Serverが内部サーバーとエクスポート可能クライアントとの間で何回エクスポート可能鍵を使用したら新しい鍵を生成する必要があるか、使用できる回数を指定します。新しい鍵を生成するまでに鍵を使用する回数が少ないほど、WebLogic Serverのセキュリティが強化されます。
必要に応じて、「サーバーの証明書を使用」コントロールを設定します。このコントロールを設定すると、WebLogic ServerでホストされているWebサービス・クライアントが、HTTPSを介して接続を開始するときにサーバー証明書/鍵をクライアント・アイデンティティとして使用する必要があるかどうかが決まります。
「相互クライアント証明書の動作」コントロールを「クライアント証明書を要求(強制する)」に設定します。
インバウンドとアウトバウンドのSSL証明書検証方法を指定します。選択できるオプションは次のとおりです。
組込みSSLの検証のみ: 組込みの信頼できるCAベースの検証を使用します。これがデフォルトです。
組込みSSLの検証および証明書パス検証プロバイダ: 組込みの信頼できるCAベースの検証を使用し、追加の検証を実行するために構成済のCertPathValidatorプロバイダを使用します。
中核となるWebLogic Serverのセキュリティ・サブシステムでは、デフォルトのキーストアに格納されている秘密鍵とX.509証明書のペアをSSLに使用します。
WebLogic Serverでリクエストのデジタル署名に使用されるX.509証明書を、Webサービス・クライアントが信頼できるようにする必要があります。次のいずれかを実行します。
WebLogic Serverが、信頼できる認証局から発行された、クライアントが自動的に信頼するデジタル証明書を取得するようにします。
WebLogic Serverが信頼する個々の証明書をすべてリストした証明書レジストリを作成し、クライアントが登録されたこれらの証明書を信頼するようにします。
Webサービス・クライアントに関するSSLの構成手順は次のとおりです。
クライアント・アプリケーションで使用するキーストアを作成します。アプリケーション・ユーザーごとに1つのクライアント・キーストアを作成することをお薦めします。
この手順の実行には、keytoolユーティリティを使用できます。開発目的の場合、最初はkeytoolユーティリティを使用するのが最も簡単な方法です。
秘密鍵とデジタル証明書のペアを作成し、クライアント・キーストアにロードします。
証明書の鍵が暗号化とデジタル署名の両方に使用できることを確認します。Oracleでは、鍵の長さは1024ビット以上である必要があります。
クライアントのJVMに次のプロパティが設定されていることを確認します。
javax.net.ssl.trustStore -- 信頼ストアが含まれるファイルの名前。
javax.net.ssl.trustStoreType -- デフォルトのTrustManagerで使用するキーストア・オブジェクトのタイプ。
javax.net.ssl.trustStorePassword -- デフォルトのTrustManagerで使用するキーストア・オブジェクトのパスワード。
|
注意: SOAアプリケーションが双方向SSLでのWebサービス・クライアントである場合の特定の構成手順については、Oracle Fusion Middleware管理者ガイド for Oracle SOA SuiteおよびOracle Business Process Management Suiteの双方向SSL通信のSOAコンポジット・アプリケーションの構成に関する項を参照してください。 |
クライアントでリクエストのデジタル署名に使用されるX.509証明書をWebLogic Serverが検証でき、WebLogic Serverがその証明書をクライアントへの応答の暗号化に使用できるようにする必要があります。次のいずれかを実行します。
クライアント・アプリケーションが、信頼できる認証局から発行された、WebLogic Serverが自動的に信頼するデジタル証明書を取得するようにします。
WebLogic Serverが信頼する個々の証明書をすべてリストした証明書レジストリを作成し、クライアントが登録されたこれらの証明書のいずれかを使用するようにします。
Webサービス・クライアントに関するSSLの構成手順は次のとおりです。
クライアント・アプリケーションで使用するキーストアを作成します。アプリケーション・ユーザーごとに1つのクライアント・キーストアを作成することをお薦めします。
この手順の実行には、keytoolユーティリティを使用できます。開発目的の場合、最初はkeytoolユーティリティを使用するのが最も簡単な方法です。
秘密鍵とデジタル証明書のペアを作成し、クライアント・キーストアにロードします。
証明書の鍵が暗号化とデジタル署名の両方に使用できることを確認します。Oracleでは、鍵の長さは1024ビット以上である必要があります。
クライアントのJVMに次のプロパティが設定されていることを確認します。
javax.net.ssl.trustStore -- 信頼ストアが含まれるファイルの名前。
javax.net.ssl.trustStoreType -- デフォルトのTrustManagerで使用するキーストア・オブジェクトのタイプ。
javax.net.ssl.trustStorePassword -- デフォルトのTrustManagerで使用するキーストア・オブジェクトのパスワード。
javax.net.ssl.keyStore -- キーストア・オブジェクトが含まれるファイルの名前。
javax.net.ssl.keyStoreType -- キーストア・オブジェクトのタイプ。
javax.net.ssl.keyStorePassword -- キーストア・オブジェクトのパスワード。
HTTPSプロトコルは、クライアントとサーバー間で保護された接続を確立するためにSecure Sockets Layer (SSL)と呼ばれる業界標準のプロトコルを使用します。クライアントとWebサービス間で通信するための通信プロトコルの1つとして、Oracle HTTP Serverによって提供されるHTTPS/SSLサポートを使用することもできます。この項では、Oracle WSMポリシーを使用して、SSL経由でリクエストを送信するようにWebサービス・クライアントおよびWebサービスを設定する方法を説明します。Oracle HTTP Serverは、クライアントとOracle WebLogic Server間を仲介するWebプロキシとして構成されます。Oracle HTTP ServerでSSLが有効であり、またクライアントとOracle HTTP Server間でSSLトランスポートが有効です。Oracle HTTP ServerとWebLogic Server間の通信は非SSLのままです。ここでは、一方向SSLおよび双方向SSLを必要とするポリシーを構成する方法について説明します。
詳細は、次の項目を参照してください。
『Oracle Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareでのSSL構成に関する項
Oracle WebLogic Serverの保護のSSLの構成
Oracle WebLogic Server管理コンソール・ヘルプのSSLの設定に関する項
『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のSecure Sockets Layerの構成に関する項
一方向SSL構成を必要とするOracle WSMポリシーの詳細は、「SSLの構成が必要なポリシー」を参照してください。
一方向SSLを使用するには、次の作業を実行する必要があります。
次の手順に従って、Oracle HTTP Serverを構成します。
例10-1に示すように、ファイルORACLE_INSTANCE/config/OHS/<ohs_name>/ssl.conf,で、Oracle HTTP ServerをWebプロキシとして構成し、アクセスするURLのリストを指定します。
例10-1 ssl.confでのURLの指定
# added properties for configuring OHS as webproxy
<IfModule weblogic_module>
WebLogicHost <host>
WebLogicPort <port>
SecureProxy Off
WlProxySSL On
Debug ALL
WlLogFile /tmp/weblogic.log
#the location attributes list the urls you want to access via OHS
<Location
/myWlsService>
SetHandler weblogic-handler
WebLogicHost <host>
WeblogicPort <port>
</Location>
同じファイルで、クライアント証明書情報がWebLogic Serverに送信されるように、仮想ホスト構成で次のプロパティを設定します。
SSLVerifyClient optional
デフォルトでは、Oracle HTTP ServerでSSLは有効です。デフォルトのhttpsポートは4443です。このポートの構成の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareでのSSL構成に関する項を参照してください。
Oracle HTTP Serverを再起動します。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareでのSSL構成に関する項を参照してください。
『Oracle Fusion Middleware管理者ガイド』のキーストア、ウォレットおよび証明書の管理に関する項の説明に従ってウォレットを作成し、デフォルトのウォレットを置換します。デフォルトのウォレットは、ORACLE_INSTANCE/config/OHS/<ohs_name/keystores/defaultディレクトリ内にあります。例10-2に、ウォレットを作成するためのサンプル・コマンドを示します。
例10-2 一方向SSLのためのサンプル・コマンド
./orapki wallet create -wallet <wallet_location> -pwd welcome1 -auto_login ./orapki wallet display -wallet <wallet_location> -pwd welcome1 ./orapki cert display -cert <wallet_location>/ohs.crt ./orapki wallet add -wallet <wallet_location> -keysize 512 -dn "CN=<host_name>,OU=st,O=owsm,L=N,ST=delhi,C=IN" -self_signed -validity 700 -serial_num 20 -cert <wallet_location>/ohs.crt -user_cert -pwd welcome1 ./orapki wallet display -wallet <wallet_location> -pwd welcome1 JAVA_HOME/bin/keytool -import -trustcacerts -file ohs.crt -alias sslcert -keystore client_keystore.jks -storepass welcome1
Oracle WebLogic管理コンソールで、次の手順を実行します。
「環境」タブの「サーバー」ページに移動します。
「AdminServer」をクリックし、「構成」で「一般」を選択します。
「詳細」セクションで、「WebLogicプラグインの有効化」および「クライアント証明書プロキシの有効化」を選択していることを確認します。
変更を保存します。
SOAサーバーに同じパラメータを設定します。
詳細は、Oracle WebLogic Server管理コンソール・ヘルプのサーバー: 構成: 要約に関する項を参照してください。
一方向モード(サーバー認証モード)を使用するようにクライアントを変更するために、JDeveloperを使用してWebサービスからJSEクライアントを作成します。例10-3に従って、パラメータおよびプロパティを変更します。
例10-3 SSLを使用するJSEクライアント
public static void main(String [] args)
{
class1Service = new Class1Service();
SecurityPolicyFeature[] securityFeatures =
new SecurityPolicyFeature[] { new SecurityPolicyFeature("oracle/wss_
saml_token_over_ssl_client_policy") };
Class1 class1 = class1Service.getClass1Port(securityFeatures);
((BindingProvider) class1).getRequestContext().put(BindingProvider.ENDPOINT_
ADDRESS_PROPERTY,
"https://<host>:4443/myWlsService/Class1Port");
((BindingProvider) class1).getRequestContext().put(BindingProvider.USERNAME_
PROPERTY, "weblogic");
System.setProperty("javax.net.ssl.trustStore","D:\\OWSM_
QA\\11g\\PS2\\OHS\\wallet\\client_keystore.jks");
System.setProperty("javax.net.ssl.trustStorePassword","welcome1");
System.setProperty("javax.net.ssl.trustStoreType","JKS");
System.setProperty("weblogic.security.SSL.ignoreHostnameVerification" ,
"true");
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");
System.setProperty("javax.net.debug","all");
System.out.println("Call to the SSL service...");
String response1 = class1.sayHello("test");
System.out.println("Response = " + response1);
}
双方向SSL構成を必要とするOracle WSMポリシーの詳細は、「双方向SSLの構成が必要なポリシー」を参照してください。
双方向SSLを使用するには、次の作業を実行する必要があります。
次の手順に従って、Oracle HTTP Serverを構成します。
例10-4に示すように、ファイルORACLE_INSTANCE/config/OHS/<ohs_name>/ssl.conf,で、Oracle HTTP ServerをWebプロキシとして構成し、アクセスするURLのリストを指定します。
例10-4 ssl.confでのURLの指定
# added properties for configuring OHS as webproxy
<IfModule weblogic_module>
WebLogicHost <host>
WebLogicPort <port>
SecureProxy Off
WlProxySSL On
Debug ALL
WlLogFile /tmp/weblogic.log
#the location attributes list the urls you want to access via OHS
<Location /myWlsService>
SetHandler weblogic-handler
WebLogicHost <host>
WeblogicPort <port>
</Location>
同じファイルで、クライアント証明書情報がWebLogic Serverに送信されるように、仮想ホスト構成で次のプロパティを設定します。
SSLVerifyClient optional
SSLOptions +StdEnvVars +ExportCertData
SSLOptions +ExportCertDataは、証明書に関連する情報をWebLogic Serverに送信するようにするmod_sslディレクティブです。SSLOptions +StdEnvVars +ExportCertDataは、SSLに関連する情報を送信するようにします。
デフォルトでは、Oracle HTTP ServerでSSLは有効です。デフォルトのhttpsポートは4443です。このポートの構成の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareでのSSL構成に関する項を参照してください。
Oracle HTTP Serverを再起動します。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion MiddlewareでのSSL構成に関する項を参照してください。
『Oracle Fusion Middleware管理者ガイド』のキーストア、ウォレットおよび証明書の管理に関する項の説明に従ってウォレットを作成し、デフォルトのウォレットを置換します。デフォルトのウォレットは、ORACLE_INSTANCE/config/OHS/<ohs_name/keystores/defaultディレクトリ内にあります。例10-5に、サンプル・コマンドを示します。
Oracle WebLogic管理コンソールで、次の手順を実行します。
「環境」タブの「サーバー」ページに移動します。
「AdminServer」をクリックし、「構成」で「一般」を選択します。
「詳細」セクションで、「WebLogicプラグインの有効化」および「クライアント証明書プロキシの有効化」を選択していることを確認します。
変更を保存します。
SOAサーバーに同じパラメータを設定します。
詳細は、Oracle WebLogic Server管理コンソール・ヘルプのサーバー: 構成: 要約に関する項を参照してください。
双方向(相互認証モード)SSLを使用するようにクライアントを変更するために、JDeveloperを使用してWebサービスからJSEクライアントを作成します。例10-6に従って、パラメータおよびプロパティを変更します。
例10-6 SSLを使用するJSEクライアント
public static void main(String [] args)
{
class1Service = new Class1Service();
SecurityPolicyFeature[] securityFeatures =
new SecurityPolicyFeature[] { new SecurityPolicyFeature("oracle/wss_
username_token_over_ssl_client_policy") };
Class1 class1 = class1Service.getClass1Port(securityFeatures);
((BindingProvider) class1).getRequestContext().put(BindingProvider.ENDPOINT_
ADDRESS_PROPERTY,
"https://<host>:4443/myWlsService/Class1Port");
((BindingProvider) class1).getRequestContext().put(BindingProvider.USERNAME_
PROPERTY, "weblogic");
((BindingProvider) class1).getRequestContext().put(BindingProvider.PASSWORD_
PROPERTY, "welcome1");
System.setProperty("javax.net.ssl.trustStore","D:\\OWSM_
QA\\11g\\PS2\\OHS\\wallet\\twowaykeystore.jks");
System.setProperty("javax.net.ssl.trustStorePassword","welcome1");
System.setProperty("javax.net.ssl.trustStoreType","JKS");
System.setProperty("javax.net.ssl.keyStore","D:\\OWSM_QA\\11g\\PS2\\OHS\\wallet\\twowaykeystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword","welcome1");
System.setProperty("javax.net.ssl.keyStoreType","JKS");
System.setProperty("weblogic.security.SSL.ignoreHostnameVerification" ,
"true");
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");
System.setProperty("javax.net.debug","all");
System.out.println("Call to the SSL service...");
String response1 = class1.sayHello("test");
System.out.println("Response = " + response1);
}
この項では、次のハードウェア関連項目について設定情報を示します。
ハードウェア・セキュリティ・モジュール(HSM)は、Oracle Advanced Securityで動作することが認定されています。これらのモジュールでは、鍵を安全に格納し、暗号処理の負荷を軽減できます。
SafeNet Luna SAは、ネットワーク接続されたアプリケーションのための暗号化処理およびハードウェア鍵管理機能を備えるHSMです。Luna SAは、様々なセキュリティ・アプリケーションで、非常に重要な暗号化鍵を保護するように設計されています。
Oracle WSMとともにLuna SAを使用する場合、鍵について次のような利点があります。
ネットワークの共有性
ハードウェアにより、鍵の最も高い安全性が常に維持されます
FIPSの検証
|
注意: Oracle Advanced Securityで使用する認定済のハードウェアおよびソフトウェアを入手するには、SafeNetの代理店にお問い合せください。 |
Oracle Web Services Manager (Oracle WSM)では、デフォルトで鍵の保存にJavaキーストア(JKS)が使用されます。暗号化操作のためにOracle WSMによって必要とされる鍵および証明書は、キーストア・ファイルからフェッチされます。ネットワーク内でLuna SAが使用可能である場合、鍵の保存目的および暗号化操作のためにOracle WSMによりLuna SAを活用できます。
この項の項目は次のとおりです。
Oracle WSMの実行中のインスタンスが存在するホストにLuna SA HSMクライアントをインストールする必要があります。これによって、Luna SA HSMクライアントは、使用可能なLuna SA HSMネットワークと通信します。ただし、Luna SAクライアントのインストール、Luna SAネットワークのインストールおよび設定については、このドキュメントの範囲外であり、ここでは取り上げません。こうした手順は、Luna SAドキュメント(http://www.safenet-inc.com/Products/Detail.aspx?id=2147483853&terms=search)を参照してください。
Luna SA HSMクライアントをインストールする前に、次のチェックリストを確認してください。
ネットワークにはすでにLuna SAがインストールされており、使用可能です。
そして、ルートまたはインストール権限を持つユーザーとしてログインしています。
Luna SAクライアント・インストールCDまたはソフトウェア・イメージが利用可能です。
管理者パスワードおよびパーティション・パスワードを含めて、Luna SAに必要なすべてのパスワードが手元にあります。
|
注意: ハードウェア・セキュリティ・モジュールおよび必要なライブラリを入手するには、SafeNetの代理店にお問い合せください。 これらの作業は、Oracle WSMでLuna SAハードウェア・セキュリティ・モジュールを使用する前に実施する必要があります。 |
Luna SAクライアントをインストールした後、Oracle WSM設定によって使用されるJREを構成する必要があります。
/usr/lunasa/jsp/libディレクトリから$JAVA_HOME/jre/lib/extディレクトリに次のJARファイルをコピーします。
LunaJCASP.jar
LunaJCESP.jar
libLunaAPI.soファイルをjava.library.pathにコピーします。
$JAVA_HOME/jre/lib/security/java.securityファイルを編集して、2つのLunaプロバイダを含めます。
security.providersリストの最後に、次の2つのLunaプロバイダを追加します。
security.provider.n=com.chrysalisits.crypto.LunaJCAProvider security.provider.n+1=com.chrysalisits.cryptox.LunaJCEProvider
各項目は次のとおりです。
nは、特定のプロバイダをリクエストしない場合に、リクエストしたアルゴリズムについてプロバイダを検索する順序を決定するプリファレンス順序を指定します。この順序は1が基準になります。1が最も優先され、次に2が優先されます。以降も同様です。
Oracle WSMでLuna SAを使用するには、Luna SAサーバーにログオンする必要があります。これは、クライアント・マシン上でLunaログイン・セッションを作成する1回かぎりのプロセスです。クライアント・マシンまたはサーバー・マシンが再起動されるか、またはユーザーがLunaセッションを明示的にログアウトするまで、このセッションはアクティブなままです。
ログインするにはsaloginユーティリィティを使用する必要があります。saloginユーティリィティは、特定のアプリケーションのためにクライアントとHSMパーティション間の接続を確立します。引数としてアプリケーションIDを取得します。このアプリケーションIDは、上位IDおよび下位IDの2つの部分から構成されます:。
saloginユーティリィティを起動する前に、アプリケーションIDを登録するエントリをChrystoki.confファイルに追加する必要があります。Chrystoki.confファイルは通常、/etc/ディレクトリにあります。これも1回かぎりのプロセスです。
/etc/Chrystoki.confファイルを編集し、ファイルの末尾にアプリケーションIDを追加します。たとえば、次のようにします。
Misc = { AppIdMajor=<major id>; AppIdMinor=<minor id>; }
次のように入力してLuna SAサーバーにログインします。
/salogin -o -s <partition number> -i <AppIdMajor>:<AppIdMinor> -v -p <partition_password>
これによって、指定したアプリケーションIDのセッションが開きます。saloginは、/usr/lunasa/binディレクトリにあります。
Luna SAサーバーからログアウトするには、次のように入力します。
salogin -c -s <slot number> -i <AppIdMajor>:<AppIdMinor>
鍵および証明書が現在はJKSにある場合、すべての鍵および証明書をLunaSAに移動する必要があります。LunaSAで提供されているcmuスクリプトを使用して鍵および証明書をインポートできます。
cmu importKeyコマンドは、ファイルからRSA|DSA秘密鍵をHSMにインポートします(PKCS12(RSA)、PKCS8(RSA/DSA)またはPKCS1(RSA)をサポートします)。
cmu importコマンドは、ファイルからX.509証明書をHSMにインポートします。
Luna SAを使用するようにOracle WSMを構成する一環として、キーストア・タイプをデフォルトのJavaキーストア(JKS)値からLunaに変更する必要があります。
キーストアのタイプを構成するには、次の手順に従います。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ページの下部近くにある「キーストア」コントロールのプラス記号(+)をクリックして開き、「構成」をクリックします。
図10-17に示すように、Web Services Managerの「キーストアの構成」ページが表示されます。
「キーストア・タイプ」ドロップダウンで、「ハードウェア・セキュリティ・モジュール(HSM)」を選択します。
図10-18に示すように、「キーストアの構成」ページがリフレッシュした後、「HSMプロバイダ・タイプ」フィールドに「Luna」と入力します。
図10-18 Web Services Managerの「キーストアの構成」ページ(リフレッシュ後)
「キーの別名」フィールドおよび「暗号化の別名」フィールドに、署名鍵および暗号化鍵の別名を入力します(Luna SAではキーストアおよび秘密鍵にアクセスするためにパスワードを必要としないことに注意してください)。
HSMでは、鍵の別名のみが必要であるため、すべての*csf.key(keystore.sig.csf.keyおよびkeystore.enc.csf.key)プロパティには資格証明ストアの鍵ではなく別名を直接指定する必要があります。これは、*csf.keyプロパティの構成オーバーライドにも該当します。
「OK」をクリックして変更内容を送信します。
Fusion Middleware Controlを再起動します。
Oracle WSMでは、Oracle SPARC T4プロセッサ・ベースのサーバーを使用できます。これによって、計算、セキュリティおよびI/Oが単一チップ上に統合され、サード・パーティ製のセキュリティ・ハードウェアが不要になります。Oracle SPARC T4ベースのサーバーにOracle WSMをデプロイすることで、T4プロセッサ・ベースの暗号化機能が透過に活用されます。これは、トランスポート・レイヤーおよびメッセージ・レイヤーの保護ポリシーによって強制された場合など、計算集中型の暗号化操作に依存するシナリオで高パフォーマンスのセキュリティを提供します。
ここでは、Oracle SPARC T4プロセッサ・ベースのサーバーの暗号化アクセラレーション機能を活用するためにOracle WSMを構成する方法について説明します。
この項は、Oracle Solaris 10 8/11以降を実行するOracle SPARC T4プロセッサ・ベースのサーバーにのみ該当します。
次の項目について説明します。
ここでは、まず次の用語について理解しておく必要があります。これらの用語の詳細は、「追加資料」に記載されているホワイトペーパーを参照してください。
PKCS#11トークン — PKCS#11 APIを実装するすべてのハードウェアおよびソフトウェアのトークンを一般的に示すトークン。PKCS#11 APIは、ハードウェア暗号化アクセラレータ、暗号化トークン(たとえばSCA-6000など)およびスマートカードを統合するためのRSA標準です。
ソフトウェア・ベースのPKCS#11トークンは、完全にソフトウェアで実装されたPKCS#11トークンです(たとえばSolaris PKCS11 Softtokenなど)。
Solaris暗号化フレームワーク — Solaris暗号化フレームワーク(SCF)ライブラリは、 Oracle Sun Crypto Accelerator 6000 PCIeカード(SCA-6000)およびサード・パーティ製HSMを含めて、Oracle T-seriesプロセッサおよびハードウェア・セキュリティ・モジュール(HSM)によって提供されるハードウェア支援暗号化アクセラレーションに対するアプリケーション・アクセスを提供するうえで重要な役割を果たします。SCFは、PKCS#11標準インタフェースに基づいており、暗号化操作を実行するためにカーネル・レベルおよびユーザー・レベルのコンシューマに一連の暗号化サービスを提供します。
Oracle SPARC T4プロセッサは、Oracle SPARC T-seriesプロセッサ・ファミリに属し、Chip Level Multi-Threading (CMT)を可能にするために、プロセッサ・コア・レベルのマルチプロセッシングと、効率的な命令パイプラインを備える各コア内部でのハードウェア・マルチスレッディングを組み合せています。これらのプロセッサは、オンチップ/オンコア暗号化アクセラレーション、10ギガビット・イーサネット・ネットワーク、ハードウェア対応仮想化機能などの専用機能を組み込むユニークな「システム・オン・チップ」設計原理を示すものです。Oracle SPARC T4プロセッサの各コアには、コアと同クロック速度で暗号化操作処理を実行するStream Processing Unit (SPU)が搭載されています。このSPUは、プロセッサの10 GbEポート上でワイヤ速度の暗号化および復号化を実現するように設計されています。
Oracle SPARC T4ベースのサーバーでOracle WSMを構成およびデプロイすることにより、SSLおよびWS-Securityメカニズムを使用して、Webサービスのセキュリティ・トランザクションの一環として、T4オンコア暗号化命令を活用して計算集中型の暗号化操作を実行することにより、高いパフォーマンスが得られます。たとえば、すべてのメッセージ保護ポリシーは計算集中型です。
Oracle WSMは、次のシナリオでSPARC T4プロセッサ・ベースの暗号化アクセラレーションを使用します。
トランスポート・レベルのセキュリティ(「暗号化アクセラレーションのためのトランスポート・レベル・セキュリティの構成」を参照してください)
Oracle WSMおよびWebLogic Serverは、SSLv3/TLSv1ベースのセキュアな通信をサポートするための基盤としてJava Cryptographic Extensions (JCE)プロバイダに依存します。Oracle Solaris/SPARCベースのデプロイメントでは、Javaランタイム環境にSun JCEプロバイダがバンドルされています。
Java PKCS#11インタフェースは、SPARC T4プロセッサのオンコア暗号化命令を使用することにより、SSL/TLSプロトコルの計算集中型の暗号化ワークロード(たとえばRSA、AES、ECCなど)を軽減し、高速化します。
メッセージ・レベルのセキュリティ(「暗号化アクセラレーションのためのメッセージ・レベル・セキュリティの構成」を参照してください)
メッセージ・レベル・セキュリティは、WS-Security、WS-SecurityPolicy、WS-TrustなどのWebサービス・セキュリティ標準をサポートする暗号化操作を基盤として構築されます。
特に、Webサービス・セキュリティは、XML暗号化、XMLデジタル署名および関連する暗号化操作をサポートするために、公開鍵暗号化、デジタル署名(RSA、DSA、ECCなど)、バルク暗号化(AES、3DES、DESなど)およびメッセージ・ダイジェスト(SHA-1、SHA-2、MD5など)の機能を利用します。
Oracle WSMでは、SPARC T4プロセッサのオンコア暗号化命令に(SCFを通じて)暗号化操作を委任するための専用PKCS#11インタフェースを実装しています。
トランスポート・レベルのセキュリティのために暗号化アクセラレーションを構成するには、次のタスクを実行します。
Oracle WebLogic Server管理コンソールのヘルプのキーストアの構成に関する項の説明に従って、WebLogic Serverキーストアを構成します。
「カスタム・アイデンティティとJava標準信頼」および「Javaキーストア(JKS)」を選択します。
WebLogic Serverに対してJSSE SSLを有効にします。
JSSEベースのSSLを使用することによって、Solaris SPARC上でJavaランタイム環境により事前構成済のSunPKCS11プロバイダ実装が自動的に活用されます。
手順の詳細は、「Oracle WebLogic Serverの保護」の「JSSEベースのSSL実装の有効化および無効化」を参照してください。
SunPKCS11プロバイダの使用を確認します。
SunPKCS11プロバイダは、SCFおよびその公開暗号化プロバイダによって提供される基盤PKCS#11実装と統合するJavaベースのPKCS#11実装です。
Solaris上の一般的なWebLogic Serverインストールでは、SunPKCS11プロバイダを利用するためのJavaランタイム環境が構成済です。
したがって、$JAVA_HOME/jre/lib/security/java.security propertiesプロパティ・ファイルで最初のプロバイダとしてSunPKCS11プロバイダがリストに含まれることを確認してください。
security.provider.1=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/sunpkcs11-solaris.cfg
例10-7に、デフォルトの$JAVA_HOME/jre/lib/security/java.securityファイルの関連部分を示します。
例10-7 java.securityファイルの抜粋
#
# List of providers and their preference orders (see above):
#
security.provider.1=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/sunpkcs11-solaris.cfg
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
WebLogic Serverを再起動します。
SSL構成が動作していることを確認します。
メッセージ・レベルのセキュリティのために暗号化アクセラレーションを構成するには、次のタスクを実行します。
Solarisコマンドラインから、PKCS11キーストアを作成します。
PKCS11キーストアを作成および初期化するには、pktool setpinコマンドを使用します。
keystore=pkcs11を指定した場合、キーストアはデフォルトの「Sun Software PKCS#11 softtoken」になります。
softokenキーストアが初期化されていない場合は、元のパスフレーズとして「changeme」を使用します。
# pktool setpin keystore=pkcs11 Enter token passphrase: Create new passphrase: Re-enter new passphrase: Passphrase changed.
キーストアの秘密鍵を生成します。
# pktool genkeypair keystore=pkcs11 keytype=rsa keylen=1024 hash=sha1
また、次のコマンドを使用することにより、JavaキーストアからSolaris Softtokenキーストアに鍵をインポートできます。
# keytool –importkeystore
-srckeystore /opt/Oracle/Middleware/default-keystore.jks
-destkeystore NONE -srcstoretype JKS
-deststoretype PKCS11
-srcstorepass changeme -deststorepass your-scfpassword
Solarisコマンドラインから、Solaris Softtokenキーストア内に鍵があることを確認します。
keytool -list -storetype pkcs11 -keystore NONE
使用するポリシーのアルゴリズム・スイートが$JAVA_HOME/jre/lib/security/sunpkcs11-solaris.cfgsunpkcs11-solaris.cfg構成ファイル内のdisabledMechanismsリストに含まれていないことを確認します。
たとえば、図10-19に示すように、ポリシーに対して指定されたアルゴリズム・スイートがBasic256Rsa15である場合、鍵のラップのためにAes256暗号化およびKwAes256/kwRsA15が使用されます。この場合、構成ファイル内のdisabledMechanismsリストにCKM_AESが含まれないことを確認します。
サポートされるアルゴリズムのリストは、Java PKCS#11リファレンス・ガイドの付録A、Sun PKCS#11プロバイダのサポートされるアルゴリズムに関する項を参照してください。
Oracle WSMキーストアの構成
PKCS11キーストアのタイプを構成するには、次の手順に従います。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ページの下部近くにある「キーストア」コントロールのプラス記号(+)をクリックして開き、「構成」をクリックします。
図10-17に示すように、Web Services Managerの「キーストアの構成」ページが表示されます。
図10-18に示すように、「キーストア・タイプ」ドロップダウンで、「公開鍵暗号化標準(PKCS-11)」を選択します。
キーストアのパスワードを入力して確認します。このパスワードは、手順1で入力したPKCS11キーストアのパスワードに一致する必要があります。
「キーの別名」フィールドおよび「暗号化の別名」フィールドに、署名鍵および暗号化鍵の別名と、対応する鍵のパスワードを入力します。署名と暗号化キーの別名とパスワードによって、鍵の格納と取得に使用される文字列の別名とパスワードが定義されます。これらの鍵がPKCS11キーストア内に存在する必要があります。
「OK」をクリックして変更内容を送信します。
Fusion Middleware Controlを再起動します。
構成を確認します。
ハードウェア支援暗号化アクセラレーションが正しく構成され、動作していることを確認するために、次のSolaris DTraceスクリプトを使用します。
#!/usr/sbin/dtrace -s
pid$1:libsoftcrypto:yf*:entry,
pid$1:libmd:yf*:entry
{
@[probefunc] = count();
}
tick-10sec
{
printa(@);
clear(@);
trunc(@,0);
}
tick-100sec
{exit(0);}
このスクリプトをcryptoverify.dという名前のファイルとして保存します。次のようにして、コマンドライン引数としてWebLogic ServerのJavaプロセスIDを指定してこのスクリプトを実行します。
# dtrace -s cryptoverify.d <WeblogicServer Process ID>
たとえば、AESアルゴリズムを使用する暗号化のシナリオでは、aesジョブの値が正で増大する場合、暗号化アクセラレーションがターゲットAESバルク暗号化ペイロードに対して動作していることを示します。
Oracle SPARC T2+/T3プロセッサ上でのOracle WSMのデプロイに関する詳細は、ホワイトペーパー「Oracle Web Services ManagerおよびOracle SPARC Enterprise T-series Serversを使用したSOAおよびXML Web Servicesの高パフォーマンス・セキュリティ」(http://www.oracle.com/technetwork/articles/systems-hardware-architecture/hi-perf-soa-xml-svcs-172821.pdf)を参照してください。
このホワイトペーパーは、Oracle SPARC T2+およびT3プロセッサ・ベースのサーバーを使用するための暗号化アクセラレーションに関する最も信頼性の高い資料です。
このホワイトペーパーでは、Solaris Kernel SSL (KSSL)を使用したSolaris暗号化フレームワーク・コンポーネント、パフォーマンス特性など、多くの追加関連トピックについて取り上げています。
メッセージ保護ポリシーを実装したWebサービスの場合、Webサービスのbase64エンコードされた公開証明書はWSDLで公開されます。証明書は、ポリシーがデータを暗号化または復号化するかどうかに関係なく、メッセージ保護ポリシーに含められます。
|
注意: 前のリリースのOracle WSMでは、メッセージ保護ポリシーを実装したWebサービスの場合、Webサービス・クライアントはWebサービスの公開証明書をそのドメイン・レベルのキーストアに格納する必要がありました。それからクライアントは |
WSDLの証明書は、デフォルトではサービスの公開鍵です。これは、「メッセージ保護に関するキーストアの構成」の説明に従ってキーストアを構成したときに指定した「暗号化鍵」によって決まります。
WSDLで証明書が見つからない場合は、かわりにkeystore.recipient.aliasプロパティが使用され、以前と同様に証明書をクライアントのドメイン・レベルのキーストアに格納する必要があります。
|
注意: 自己署名証明書を信頼できるものにするには、クライアント側のキーストアで使用可能にする必要があります。 |
WSDLから取り出した証明書が改ざん攻撃や中間者攻撃を受けておらず、期待通りの証明書であることを確認するホスト名検証機能が含まれています。
これを行うために、Oracle WSMは、証明書内の共通名(CN)またはサブジェクトのグループ・ベース識別名(DN)がサービスのホスト名と一致していることを検証します。
この機能は、証明書のサブジェクトDNに依存します。
デフォルトでは、ホスト名検証は無効です。
サービス・アイデンティティ証明拡張およびホスト名検証を有効化または無効化するには、Fusion Middleware Controlを使用します。
アイデンティティ拡張タブのプロパティにより、WSDLのX509資格証明をパブリッシュしてWebサービス・ポリシーを強制するかどうかを指定できます。また、X509をパブリッシュする場合は、ホスト名検証を無視するかどうかも指定できます。
サービス・アイデンティティ証明拡張はデフォルトで有効、ホスト名検証はデフォルトで無効です。
サービス・アイデンティティ証明拡張およびホスト名検証を有効化または無効化する手順
「メッセージ保護に関するキーストアの構成」で説明されているように、公開鍵の元となる暗号化キーを設定します。
サービス側のオーバーライドを使用して暗号化キーやWebサービスのキーストアをオーバーライドする場合は、オーバーライドされるキーに対応する証明書が使用されます。
ナビゲーション・ペインから、「WebLogicドメイン」を開きます。
サービス・アイデンティティ証明拡張およびホスト名検証を有効化または無効化するドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」をクリックします。
「Webサービス」→「プラットフォーム・ポリシー構成」を選択します。
アイデンティティ拡張タブを選択します。
アイデンティティ拡張プロパティを変更するには、それを選択してから「編集」をクリックします。「プロパティの編集」ウィンドウで、「値」フィールドを編集して各プロパティのデフォルト値を変更できます。
wsm.ignore.identity.wsdl - クライアント側のWSDLから取得したX509証明書の使用を有効にするかどうかをドメインごとに指定します。デフォルトではこのプロパティは有効(false)で、クライアントのランタイムはWSDLからの証明書を暗号化に使用します。デフォルト設定をtrueに変更すると、X509証明書の使用を無効化できます。
wsm.ignore.hostname.verification - ホスト名検証機能を無効にするかどうかをドメインごとに指定します。デフォルトでは、このプロパティは無効(true)です。ただし、プロパティをfalseに設定すると、ホスト名検証を有効化できます。
既存のプロパティを削除するには、それを選択してから「削除」をクリックします。
「適用」をクリックしてプロパティの更新を適用します。
|
注意: デフォルトでは、WSDLで証明書が公開されている場合、 |
Java EEクライアントの場合は、wsm.ignore.identity.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クライアントの場合は、wsm.ignore.hostname.verificationプロパティの値が自動的に読み取られ、その他の構成は必要ありません。「サービス・アイデンティティ証明拡張およびホスト名検証の有効化または無効化」で説明されているように、Fusion Middleware Controlでこのプロパティを設定して、ホスト名検証を有効または無効にします。
JSEクライアントの場合は、Webサービス・クライアントはホスト名検証を無視するための明示的なアクションを行う必要があります。
これを行うには、次のようにwsm.ignore.hostname.verificationの値をtrueに設定します。
BindingProvider.getRequestContext().put(SecurityConstants.ClientConstants.WSM_IGNORE_HOSTNAME_VERIFICATION,"false");
この項では、WebLogic Serverのセキュリティ機能について説明します。この機能の詳細は、Securing Oracle WebLogic ServerおよびOracle WebLogic Server管理コンソールのヘルプで説明されています。この項では、セキュリティ機能と構成ポリシーとの関係を中心に、セキュリティ機能の概要のみを解説します。
ユーザー名、X.509、Kerberos、SAML、HTTP BASICなどを含めて、サポートされるトークン・タイプを使用するポリシーでは、WebLogicデフォルト認証プロバイダなどの認証プロバイダが必要になります。
次のポリシーはこのカテゴリに分類されます。
oracle/wss_http_token_service_policy
oracle/wss_username_token_service_policy
oracle/wss_username_token_over_ssl_service_policy
oracle/wss11_username_token_with_message_protection_service_policy
oracle/wss10_username_token_with_message_protection_service_policy
oracle/wss10_username_token_with_message_protection_ski_basic256_service_policy
oracle/wss10_x509_token_with_message_protection_service_policy
oracle/wss10_saml_token_service_policy
oracle/wss10_saml_token_with_message_protection_service_policy
oracle/wss_saml_token_over_ssl
oracle/wss_saml_token_bearer_over_ssl_service_policy
oracle/wss10_saml_hok_token_with_message_protection_service_policy
oracle/wss11_saml_token_with_message_protection_service_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy
oracle/wss11_x509_token_with_message_protection_service_policy
WebLogic Server認証プロバイダでは、Oracle WSMとともに使用するための構成が可能です。つまり、トークン・タイプにかかわらず、次のいずれかのWebLogic Server認証プロバイダを使用できます。
WebLogic認証プロバイダ(DefaultAuthenticatorとも呼ばれています)。
Oracle Internet Directory AuthenticatorまたはOracle Virtual Directory Authenticator。
LDAP AuthenticatorまたはOpen LDAP Authenticator。
RDBMS認証プロバイダ
|
注意: RDBMS認証プロバイダ、または他の非LDAPベースのプロバイダを使用する場合、Oracle WSMにより生成されるSAMLアサーションに追加されるカスタム属性を指定できないという制限があります。この制限は、LDAPベースのプロバイダには存在しません。 |
つまり、SAML、KerberosおよびX.509トークンを使用するポリシーでは、こうした特定のトークン・タイプを処理するためにWebLogic Serverプロバイダを構成する必要はありません。
特に、Oracle WSMランタイムでは、次のような他のWebLogic Serverプロバイダを使用しません(下記を含みますが、下記に限定されるわけではありません)。
任意のアイデンティティ・アサーション・プロバイダ
X509プロバイダ
X509トークン・ベースのOracle WSMポリシーは、WebLogic Server X509アイデンティティ・アサーション・プロバイダを使用しません。
SAMLプロバイダ
SAMLトークン・ベースのOracle WSMポリシーは、WebLogic Server SAMLプロバイダを使用しません。
資格証明マッパー・プロバイダ
認可プロバイダ
ロール・マッパー・プロバイダ
証明書パス・プロバイダ
監査プロバイダ
SAMLおよびKerberosポリシーには、ログイン・モジュールが関連付けられています。このモジュールは、ポリシーを構成するアサーションによって決まります。SAMLポリシーをWebサービスに添付する場合、ログイン・ポリシーを編集して必要な変更を加えることができます。
次のSAMLログイン・モジュールおよびKerberosログイン・モジュールを構成できます。
saml.loginmodule—このSAMLログイン・モジュールは、Java Authentication and Authorization Service(JAAS)ログイン・モジュールであり、ログインのためにSAMLアサーションを受け入れます。また、SAMLアサーションから作成されたプリンシパルのログイン・コンテキストを使用して、Webサービスを実行できるようにします。
saml2.loginmodule—このSAML2ログイン・モジュールは、JAASログイン・モジュールであり、ログインのためにSAML2アサーションを受け入れます。また、SAML2アサーションから作成されたプリンシパルのログイン・コンテキストを使用して、Webサービスを実行できるようにします。
krb5.loginmodule—このKerberosログイン・モジュールは、JAASログイン・モジュールであり、Kerberosプロトコルを使用してユーザーを認証します。このログイン・モジュールには、構成可能なオプション・プロパティがあります。
(他のポリシー・タイプに関連付けられているログイン・モジュールには、Webサービス・ポリシーに固有の設定はありません。)
ログイン・モジュールを構成するには:
ナビゲータ・ペインで「WebLogicドメイン」を開き、ログイン・モジュールの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ログイン・モジュールのリストから、ログイン・モジュールを選択し、「編集」をクリックします。
たとえば、図10-22に示すように、ログイン・モジュールのリストから「saml.loginmodule」を選択し、「編集」をクリックすると、「ログイン・モジュールの編集」ページが表示されます。
|
注意: 「一般プロパティ」セクションのデフォルト値は編集しないでください。このデフォルト値を編集した場合、予期しない結果が生じることがあります。これらのプロパティのデフォルト値は、次のとおりです。
|
それぞれの構成で必要に応じて、「SAML固有の属性」セクションで、代替の「発行者」の属性を構成できます。SAMLポリシーでは、「発行者」の属性が必要です。この属性では、SAMLトークンまたはSAML2トークンの発行者の名前を指定します。事前定義済Oracle SAMLポリシーおよびアサーションでは、デフォルト値はwww.oracle.com.です。Webサービス・クライアントおよびWebサービス側の両方で事前定義済SAMLポリシー(またはアサーション)を使用している場合、一般にデフォルトを使用できます。この場合は、発行者を構成できません。詳細は、「別のSAMLアサーション発行者名の追加」を参照してください。
ページの「カスタム・プロパティ」セクションで、ログイン・モジュールのカスタム・プロパティを構成します。
プロパティを追加するには、「追加」をクリックし、「新規プロパティの追加」ウィンドウにプロパティの名前および値を入力します。「OK」をクリックして、「カスタム・プロパティ」リストにプロパティを追加します。
既存のプロパティの値を変更するには、「カスタム・プロパティ」リストからプロパティを削除し、値を変更した新しいプロパティを追加する必要があります。
表10-1に、SAMLログイン・モジュール、Kerberosログイン・モジュールおよび構成可能なプロパティを示します。
表10-1 SAMLログイン・モジュールおよびKerberosログイン・モジュールの属性とプロパティ
| ログイン・モジュール・サービス名 | プロパティ | 説明 |
|---|---|---|
|
saml.loginmodule saml2.loginmodule |
oracle.security.jps.assert.saml.identity |
SAMLサブジェクトとユーザー間のマッピングを決定するために使用されるドメイン全体のプロパティ。有効な値は次のとおりです。
|
|
oracle.security.jps.add.assertion.to.subject |
認証されたサブジェクトに秘密資格証明としてSAMLアサーションを追加すべきかどうかを示すブール・フラグ。デフォルトは |
|
|
krb5.loginmodule |
principal |
使用すべきプリンシパルの名前。「testuser」のような簡単なユーザー名または「host/testhost.eng.sun.com」のようなサービス名を指定できます。keyTabに複数のプリンシパルの資格証明がある場合、または特定のチケット・キャッシュのみが必要な場合に、プリンシパルを設定するためにprincipalオプションを使用できます。 |
|
useKeyTab |
TrueまたはFalse。モジュールがkeyTabからプリンシパルの鍵を取得できるようにするには、trueに設定します(デフォルト値はfalse)。keyTabが設定されていない場合は、モジュールはKerberos構成ファイルでkeyTabを検索します。Kerberos構成ファイルに指定されていない場合は、ファイル{user.home}{file.separator}krb5.keytabを検索します。 |
|
|
storeKey |
プリンシパルの鍵をサブジェクトの秘密資格証明に格納するには、trueに設定します。 |
|
|
keyTab |
プリンシパルの秘密鍵を取得するには、keyTabのファイル名を設定します。 |
|
|
doNotPrompt |
資格証明をキャッシュまたはkeyTabから取得できないときに、パスワードを要求するプロンプトを表示しない場合は、trueに設定します(デフォルト値はFalse)。trueに設定すると、資格証明をキャッシュまたはkeyTabから取得できない場合、認証は失敗します。 |
SAML標準では、Web上のソフトウェア・エンティティ間のセキュリティ・アサーションを作成、要求および交換するための共通のXMLフレームワークが定義されています。SAMLトークン・プロファイルは、WS-Security標準のコア・セットの一部であり、WebサービスのセキュリティのためにSAMLアサーションを使用する方法が指定されています。SAMLでは、ビジネス・プロセスまたはトランザクションの複数のステップ間で、ブラウザからポータル、Webサービスのネットワークへと渡すことのできるセキュリティ・トークンを表す標準的な方法も提供されます。
次の事前定義済ポリシーを使用する場合は、SAMLを構成する必要があります。
oracle/wss_saml_token_bearer_over_ssl_server_policy
oracle/wss_saml_token_bearer_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policy
oracle/wss_saml_token_over_ssl_client_policy
oracle/wss10_saml_token_service_policy
oracle/wss10_saml_token_client_policy
oracle/wss10_saml20_token_service_policy
oracle/wss10_saml20_token_client_policy
oracle/wss10_saml_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_protection_service_policy
oracle/wss10_saml20_token_with_message_protection_client_policy
oracle/wss10_saml20_token_with_message_protection_service_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policy
oracle/wss10_saml_hok_token_with_message_protection_service_policy
oracle/wss10_saml_hok_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_integrity_service_policy
oracle/wss10_saml_token_with_message_integrity_client_policy
oracle/wss11_saml_token_with_message_protection_service_policy
oracle/wss11_saml_token_with_message_protection_client_policy
oracle/wss11_saml20_token_with_message_protection_service_policy
oracle/wss11_saml20_token_with_message_protection_client_policy
次のセクションで、SAML構成の詳細を説明しています。
SAMLログイン・モジュールは、Webサービスに代わってSAMLトークンを検証します。次に、SAMLログイン・モジュールは認証を完了するために、検証されたトークンからユーザー名を抽出し、Oracle Platform Security Services(OPSS)に(間接的に)渡します。
「WebLogic Serverへの認証プロバイダの構成」の説明に従って、任意の構成済認証プロバイダを起動できます。
設計時に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アサーションを作成するためのユーザー名はサブジェクトのみから取得されます)。
Oracle WSMランタイムは、構成済アイデンティティ・ストアからこうした属性の値を読み取り、属性とその値をSAMLアサーションに含めます。
user.attributesプロパティは、1つのアイデンティティ・ストアに対してサポートされ、デフォルトではリスト内の最初のアイデンティティ・ストアのみが使用されます。そのため、ユーザーは、構成済WebLogic Serverの認証プロバイダで使用されるアイデンティティ・ストアに存在し、有効になっている必要があります。認証プロバイダについては、「WebLogic Serverへの認証プロバイダの構成」を参照してください。
複数のアイデンティティ・ストアを構成しており、すべてのアイデンティティ・ストアでユーザーを検索する場合は、すべての構成済アイデンティティ・ストアで検索を有効にするために、次の手順に従います。
ナビゲータ・ペインで「WebLogicドメイン」を開き、アイデンティティ・ストア・プロバイダの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ページの「アイデンティティ・ストア・プロバイダ」セクションで、「構成」をクリックしてアイデンティティ・ストアを操作するパラメータを構成します。
図10-23に示すように、「アイデンティティ・ストア構成」ページが表示されます。
「追加」をクリックしてカスタム・プロパティを追加します。
図10-24に示すように、値「true」のプロパティ「virtualize」を追加します。
「OK」をクリックして変更内容を送信します。
Fusion Middleware Controlを再起動します。
ユーザーのロールをSAMLアサーションの属性文として渡すことができます。このためには、デプロイ後にuser.role.includeプロパティを「true」に構成します。このポリシーのデフォルト値は「false」です。
設計時にユーザーのロールを構成するには、BindingProviderのuser.role.includeプロパティをtrueに設定します。
事前定義済SAMLポリシーに関してOPSSを構成するには、次の手順を実行します。
「SAMLおよびKerberosログイン・モジュールの構成」の説明に従って、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です。このため、通常はデフォルト値を使用でき、発行者の構成は不要です。
発行者を追加する必要があるのは、次の2つの状況です。
SAML事前定義済Webサービス・ポリシーまたはアサーションの場合、saml.trusted.issuerプロパティの値を設定します。このプロパティに値を設定する場合は、その信頼できる発行者を「発行者」リストに追加する必要があります。
SAML事前定義済Webサービス・ポリシーまたはアサーションの場合、saml.issuer.nameプロパティの値を設定します。このプロパティに値を設定する場合は、同じ値の信頼できる発行者を「発行者」リストに追加する必要があります。
別のクライアント、たとえば.NET/STSが事前定義済SAMLポリシーによって保護されたWebサービスと通信する場合、その発行者を「発行者」リストに追加する必要があります。
|
注意: ここで説明したメカニズムによって発行者を追加できますが、ただしこれは下位互換性専用です。優先される方法は、プラットフォーム・ポリシーの構成レベルで信頼できる発行者を構成することです。「署名証明書の信頼できる発行者および信頼できるDNリストの定義」を参照してください。 信頼できる発行者の決定方法は、次の順位で決められます。
ここに記載されたメカニズムによってSAML発行者を定義した場合、発行者は |
別のSAMLアサーション発行者を「発行者」リストに追加する手順
ナビゲータ・ペインで「WebLogicドメイン」を開き、発行者の追加が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
必要に応じてSAMLログイン・モジュールまたはSAML2ログイン・モジュールを選択し、「編集」をクリックします。
図10-25に示すように、ページの「SAML固有の属性」セクションから、「追加」をクリックして、別の発行者名を追加します。
クライアント・ポリシーの場合、デプロイ時に、SAMLクライアント・ポリシーの「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。ポリシーのデフォルト値はwww.oracle.comです。
設計時に発行者を構成するには、BindingProviderのsaml.issuer.nameプロパティを設定します。
Oracle WSMには、アイデンティティ切替えを有効にする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権限を持つことが要求されます。つまり、Oracle WSMが外部から提供されるアイデンティティをアプリケーションから受け入れるには、そのアプリケーションがWSIdentityPermission権限を持つ必要があります。
これにより、Oracle WSMが潜在的に悪質なアプリケーションからアイデンティティを提供されるのを回避します。
|
注意:
このポリシーは、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.agent.common_${jrf.version}/wsm-agent-core.jarと入力します。
|
注意: 権限付与の詳細を定義する場合、ディレクトリまたはJARの名前で製品バージョン番号の使用は避けることをお薦めします。これによって、将来の新しいリリースへのアップグレード時に影響を最小限に抑えることができます。 |
ページの「権限」セクションで、開始点の権限クラスを選択して「編集」をクリックします。
「権限クラス」フィールドにoracle.wsm.security.WSIdentityPermissionと入力します。リソース名はSOAのコンポジット名で、Java EEクライアントのアプリケーション名です。図10-26に示すように、アクションは常にassertです。
WLSTを使用してoracle.wsm.security.WSIdentityPermission権限を追加するには、次のコマンドを実行します。
grantPermission(codeBaseURL="file:${common.components.home}/modules/
oracle.wsm.agent.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のリストを定義できます。
デフォルトでは、Oracle WSMは、受信した発行者名を構成済の発行者のリストと照合してチェックし、SAML署名をOracle WSMキーストアにある構成済の証明書と照合してチェックします。また、信頼できるDNリストを定義する場合は、SAML署名がその発行者に関連付けられている特定の証明書に基づいて署名されているかどうかが検証されます。
信頼できるDNリストの構成はオプションです。詳細な制御を必要とするユーザーは、これにより各発行者を1つ以上の署名証明書のリストに関連付けることができます。信頼できる発行者のDNリストが定義されていない場合、証明書がOracle WSMキーストアに存在する証明書によって信頼されているかぎり、その証明書に基づいて署名できます。
SAML署名証明書の信頼できるDNリストの定義の詳細は、「署名証明書の信頼できる発行者および信頼できるDNリストの定義」を参照してください。
すべてのSAMLポリシーで、匿名ユーザーの伝播が許可されます。たとえば、認証ユーザーまたは匿名ユーザーのいずれかが操作できるADFアプリケーションが存在し、このADFアプリケーションでWebサービスへのコールを行い、現在のユーザーを伝播する必要がある場合、いずれかのSAMLポリシーを使用して認証ユーザーおよび匿名ユーザーの両方を伝播できます。セキュリティの観点からは、SAML経由での匿名ユーザーの伝播は、サービスに認証トークンを送信しないクライアントと等価です。
1つのポリシーで認証ユーザーおよび匿名ユーザーの両方をサポートできる利便性のために、SAML経由での匿名ユーザーが許可されています。ただし、SAML経由での匿名の伝播は非標準であり、他のベンダーとは相互運用できないことに注意してください。クライアントおよびWebサービスの両方でOracle WSMを使用している場合にのみ、使用すべきです。
アイデンティティ・コンテキストにより、組織は、Oracle Access Managementプラットフォームに組み込まれているコンテキストを意識したポリシー管理および認可機能を使用することで、増大するセキュリティの脅威に対応できます。アイデンティティ・コンテキストでは、従来のセキュリティ制御(ロールやグループなど)とともに、認証および認可中に確立される動的データ(認証強度、リスク・レベル、デバイス・トラストなど)を使用することで、リソースへのアクセスのセキュリティが確保されます。
たとえば、アプリケーションでは、次のためにアイデンティティ・コンテキストを使用できます。
ユーザーがスマート・カードなど強力な資格証明を使用して認証されていない場合、特定のビジネス機能を無効化します。
組織が(Identity Federationを使用して)取引しているビジネス・パートナによって提供されたアイデンティティ・データに基づいてトランザクションへのアクセスのセキュリティを確保します。
不正行為で知られる場所からアクセスされていることが検出された場合、追加の認証資格証明を要求します。
管理者の(サードパーティで管理されている)業界認定証が有効期限切れになっている場合、管理権限の範囲を制限します。
不明なデバイスからアクセスされていることが検出された場合、特定のビジネス機能を無効化します。
Oracle WSMは、Webサービス・クライアントからWebサービスにアイデンティティ・コンテキストを伝播した後、認証および認可の目的のために、他のコンポーネントに対して使用可能に(「公開」)できます。
アイデンティティ・コンテキストは、Webサービス・クライアントおよびWebサービスに対して不透過であり、ポリシーのアイデンティティ・コンテキストの伝播を有効にした後、アイデンティティ・コンテキストのサポートのためにWebサービス・クライアントまたはWebサービスで追加コーディングまたは追加処理を実行する必要はありません。
|
注意: アイデンティティ・コンテキストの伝播は、SOA、WebCenterおよびWebLogic(Java EE)Webサービス・アプリケーションではサポートされません。 |
アイデンティティ・コンテキスト、アイデンティティ・コンテキスト・サービスの構成、アイデンティティ・コンテキストAPIの使用に関する詳細は、『Oracle Access Management管理者ガイド』のアイデンティティ・コンテキストの使用tに関する項を参照してください。
この機能を使用するには、Webサービス・ポリシーおよびWebサービス・クライアント・ポリシーの両方について、propagate.identity.context構成プロパティを使用することにより、アイデンティティ・コンテキストの伝播を明確に有効にする必要があります。つまり、Webサービス・クライアント・ポリシーおよびWebサービス・ポリシーの両方で明確に許可する場合にのみ、Oracle WSMでアイデンティティ・コンテキストを伝播できます。
Oracle WSMは、SAML 1.1またはSAML 2.0アサーションを使用することにより、Webサービス・クライアントからWebサービスにアイデンティティ・コンテキストを伝播します。したがって、SAMLポリシーにのみpropagate.identity.context構成プロパティが含まれます。
次のSAMLポリシーには、propagate.identity.context構成プロパティが含まれます。
oracle/http_saml20_token_bearer_service_policyおよびoracle/http_saml20_token_bearer_client_policy
oracle/http_saml20_token_bearer_over_ssl_service_policyおよびoracle/http_saml20_token_bearer_over_ssl_client_policy
oracle/wss_saml_or_username_token_service_policy
oracle/wss_saml_or_username_token_over_ssl_service_policy
oracle/wss_saml_token_bearer_over_ssl_service_policyおよびoracle/wss_saml_token_bearer_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_service_policyおよびoracle/wss_saml_token_over_ssl_client_policy
oracle/wss_saml20_token_bearer_over_ssl_service_policyおよびoracle/wss_saml20_token_bearer_over_ssl_client_policy
oracle/wss_saml20_token_over_ssl_service_policyおよびoracle/wss_saml20_token_over_ssl_client_policy
oracle/wss10_saml_token_service_policyおよびoracle/wss10_saml_token_client_policy
oracle/wss10_saml_token_with_message_integrity_service_policyおよびoracle/wss10_saml_token_with_message_integrity_client_policy
oracle/wss10_saml_token_with_message_protection_service_policyおよびoracle/wss10_saml_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_service_policyおよびoracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy
oracle/wss10_saml20_token_service_policyおよびoracle/wss10_saml20_token_client_policy
oracle/wss10_saml20_token_with_message_protection_service_policyおよびoracle/wss10_saml20_token_with_message_protection_client_policy
oracle/wss11_saml_token_with_message_protection_service_policyおよびoracle/wss11_saml_token_with_message_protection_client_policy
oracle/wss11_saml_or_username_token_with_message_protection_service_policy
oracle/wss11_saml20_token_with_message_protection_service_policyおよびoracle/wss11_saml20_token_with_message_protection_client_policy
ここでの説明に従ってポリシーの「構成」タブで propagate.identity.contextに値を指定するか、ポリシーのアタッチ時にこの値をオーバーライドできます。
ポリシーのアタッチ後のpropagate.identity.contextプロパティのオーバーライドに関する詳細は、次のトピックを参照してください。
|
注意: 有効なポリシー・セットが常にあるように、事前定義済ポリシーは編集しないことをお薦めします。ただし、「SAMLポリシーを使用したアイデンティティ・コンテキストの伝播」に記載された事前定義済SAMLポリシーを使用して、(サーバーおよびクライアントの両方の)新しいポリシーを作成できます。新しいポリシーの作成に関する詳細は、「既存のポリシーからのWebサービス・ポリシーの作成」を参照してください。新しいポリシーを作成した後、次のようにしてポリシーを編集し、 |
デフォルトでは、propagate.identity.context構成プロパティは未設定であり、これはFalseと等価です。アイデンティティ・コンテキストの伝播を使用するには、propagate.identity.contextに明確にTrueを設定する必要があります。
ナビゲータ・ペインで「WebLogicドメイン」を開き、アイデンティティ・コンテキストの伝播の構成が必要なドメインを表示します。ドメインを選択します。
コンテンツ・ウィンドウで、「WebLogicドメイン」、「Webサービス」、および「ポリシー」の順に選択します。
アイデンティティ・コンテキストの伝播を有効にするSAMLポリシーを選択し、「編集」をクリックします。Webサービス・クライアントおよびWebサービス・ポリシーの両方についてアイデンティティ・コンテキストの伝播を有効にする必要があることに注意してください。
「ポリシーの編集」ページで、「構成」タブを選択します。
プロパティのリストからpropagate.identity.contextを選択し、「編集」をクリックします。
図10-27に示すように、値フィールドをTrueに変更し、「OK」をクリックします。
図10-27 propagate.identity.contextプロパティをTrueに設定する
対応するクライアント・ポリシーまたはサービス・ポリシーについて、必要に応じて手順3から6を繰り返します。
「保存」をクリックして変更を送信します。
Oracle Fusion Middleware 11gリリース1では、次に示す事前定義済のポリシーとともに、Kerberosトークンもサポートされています。
oracle/wss11_kerberos_token_client_policy
oracle/wss11_kerberos_token_service_policy
oracle/wss11_kerberos_token_with_message_protection_client_policy
oracle/wss11_kerberos_token_with_message_protection_service_policy
oracle/wss11_kerberos_token_with_message_protection_basic128_client_policy
oracle/wss11_kerberos_token_with_message_protection_basic128_service_policy
また、次のアサーション・テンプレートを使用して、ポリシーを作成することもできます。
oracle/http_spnego_token_client_template
oracle/http_spnego_token_service_template
oracle/wss11_kerberos_token_client_template
oracle/wss11_kerberos_token_service_template
oracle/wss11_kerberos_token_with_message_protection_client_template
oracle/wss11_kerberos_token_with_message_protection_service_template
これらのポリシーおよびアサーションの詳細は、付録B「事前定義済ポリシー」および付録C「事前定義済アサーション・テンプレート」を参照してください。
この項に記載されている手順に従って、KerberosをWebサービス・クライアントとWebサービスで使用できるように構成します。
Microsoft Active DirectoryをKey Distribution Center(KDC)とともに使用することもできます。「Active DirectoryのKerberosおよびメッセージ保護との使用」を参照してください。
Key Distribution Center (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 welcome1 >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-8に、サンプルの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-8 サンプルの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 }
Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。サービス・プリンシパル名の設定は、「プリンシパルの作成」で行います。
「構成」ページでservice.principal.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。デフォルト(プレースホルダ)値は、HOST/localhost@example.comです。
Kerberosクライアント側ポリシーを実行するWebサービス・クライアントは、アクセスを試行するサービスのサービス・プリンシパル名を認識している必要があります。サービス・プリンシパル名の設定は、「プリンシパルの作成」で行います。
設計時に構成のオーバーライドを使用し、次のようにサービス・プリンシパル名を指定します。
JAX-WS Clients: ((BindingProvider)port).getRequestContext().put(SecurityConstants.ClientConstants.WSSEC_KERBEROS_SERVICE_PRINCIPAL, SOAP/myhost.example.com@example.com);
適切なKDCに対してWebサービスを認証するように構成します。KDCの構成は、UNIXホストの場合は/etc/krb5.confに存在し、Windowsホストの場合はC:\windows\krb5.iniに存在します。
例10-8に、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で転送する場合は、バイナリ・モードを使用してください。
「Configuring the SAML and Kerberos Login Modules」の説明に従って、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 welcome1
これにより、チケット認可チケットを含むファイルシステムにチケット・キャッシュが作成されます。このことを確認するには、次のコマンドを入力します。
>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ユーザー名およびパスワードに対するプロンプトが表示されます。この場合、チケット・キャッシュはファイルシステムに作成されず、メモリーに保持されます。
SPNEGO(Simple and Protected GSSAPI Negotiation Mechanism)は、クライアントおよびサービスが認証に使用する方法をネゴシエートすることを可能にする標準です。SPNEGOではネゴシエーションを実行するためにHTTPヘッダーを使用するので、HTTPを使用するSOAPおよびRESTのエンドポイントが一般的であるWebなどのクロス・プラットフォームのコンテキストで特に役立ちます。
SPNEGOネゴシエーションでKerberosが使用される場合、KerberosトークンはHTTPヘッダーのauth-scheme Negotiateの下でラップされます。次のようにして、クライアントとサービス間でSPNEGOトークンの通信のために、WWW-AuthenticateおよびAuthorizationヘッダーが使用されます。
Authorizationヘッダーなしでクライアント・リクエストがサーバーの保護されたサービスにアクセスします。
リクエストにAuthorizationヘッダーがないので、サーバーはステータス・コード401(未認可)およびWWW-Authenticate: Negotiateとともに応答します。
クライアントは、Kerberosトークンを取得するためにユーザー資格証明を使用し、新しいリクエストのAuthorizationヘッダーでサーバーにそのトークンを送信します。たとえば、Authorization: Negotiate a87421000000492aa874209....のようになります。
サーバーは、このトークンをacceptSecContext() GSS-APIに渡すことによりデコードします。コンテキストが完了していない場合(相互認証の場合)、サーバーはGSS-APIデータを含む401ステータス・コードおよびWWW-Authenticateヘッダーとともに応答します。たとえば、WWW-Authentiate: Negotiate 74900a2a....のようになります。
クライアントはこのデータをデコードし、新しいデータをサーバーに返信します。セキュリティ・コンテキストが確立されるまでこのサイクルが続行されます。
Oracle WSMは、SPNEGOネゴシエーションを使用して、クライアントおよびサービスで認証用にKerberosを使用できるようにするために、次のアサーション・テンプレートを提供します。
これらのアサーション・テンプレートは、SOAPまたはRESTのエンドポイントにアタッチされたポリシーによって使用できます。
Microsoft Active DirectoryをKey Distribution Center(KDC)とともに使用することもできます。この項では、Active DirectoryをKerberosとメッセージ保護とともに使用する場合のKDCの構成方法について説明します。
この項では、Active Directoryに習熟していることを前提として説明します。詳細については、Active Directoryのドキュメントを参照してください。
この項では、次のタスクについて説明します。
Active Directoryを使用してユーザー・アカウントを新規作成します。DES暗号化は使用しないでください。デフォルトでは、ユーザー・アカウントはRC4-HMACを使用して作成されます。
たとえば、ユーザーtestpolをユーザー・ログオン名test/testpolで作成できます。
ユーザー・ログオン名は、container/nameの形式にする必要があります。アカウントは任意のコンテナに作成できます。
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は指定しないでください。
setSpnを使用して、サービス・プリンシパル名をユーザーにマッピングします。
setSpn -A test/testpol testpol setSpn -L testpol (this should display the availabel mapping)
ユーザーにマッピングするサービス・プリンシパル名は1つのみにする必要があります。ユーザーにマッピングされたサービス・プリンシパル名が複数ある場合は、setSpn -D <spname> <username>を使用して削除します。
次の手順を実行して、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>
「SAMLおよびKerberosログイン・モジュールの構成」の説明に従って、krb5ログイン・モジュールを変更し、keytabの場所とサービス・プリンシパル名を指定します。
keytabファイルへの絶対パスを使用してください。また、サービス・プリンシパル名には必ず@realmnameを追加してください。たとえば、次のようにします。
principal value=test/testpol@example.com
Webサービス・クライアントをwss11_saml_token_with_message_protection_client_policy policyで保護し、対応するWebサービスをwss11_saml_token_with_message_protection_service_policy policyで保護すると仮定します。
この項では、この2つのポリシーを使用して手順を説明します。
次の項目について説明します。
この項では、このSAMLメッセージ保護のユースケースを構成するために必要となる知識について説明します。次の項目について説明します。
wss11_saml_token_with_message_protection_service_policyは、WS-Security 1.1標準に従って、インバウンドSOAPリクエストに対して、メッセージ・レベルの保護(つまり、メッセージ整合性とメッセージの機密保護)とSAMLベースの認証を行います。
メッセージは、WS-Securityの対称鍵テクノロジのBasic 128スイートを使用して保護されます。具体的には、メッセージ機密保護にはRSA鍵メカニズム、メッセージ整合性にはSHA-1ハッシュ・アルゴリズムが使用され、AES-128ビット暗号化も使用されます。メッセージ保護に使用できるアルゴリズムの詳細は、「サポートされているアルゴリズム・スイート」を参照してください。
そのため、キーツール(またはその他のツール)を使用してこのポリシーに必要な署名や暗号化キーを作成する場合は、必ずRSA鍵メカニズム、SHA-1アルゴリズム、そしてAES-128ビット暗号化を使用して、キーのポリシー要件を満たす必要があります。
このポリシーは対称鍵テクノロジを使用しています。対称鍵暗号は、次のような単一の共有の秘密鍵に依存します。
クライアントは、対称鍵を作成し、それを使用して署名してメッセージを暗号化し、そしてリクエスト・メッセージでWebサービスとそれを共有します。
対称鍵を保護するために、リクエスト・メッセージで送信された対称鍵は、サービスの証明書を使用して暗号化されます。
Webサービスはリクエスト・メッセージ内の対称鍵を使用して、リクエスト・メッセージの署名を検証してそれを復号化し、それからレスポンス・メッセージに署名して暗号化します。
次のプロセス・フローを考慮します。
リクエストを作成するために、Oracle WSMエージェントは次のことを行います。
共有の対称鍵を生成し、それを使用してリクエスト・メッセージの署名と暗号化の両方を行います。
その独自の秘密鍵を使用して、リクエスト・メッセージの署名を裏書きします。
Webサービスの公開鍵を使用して、対称鍵を暗号化します。
対称鍵をリクエストとともにWebサービスに送信します。クライアントはリクエストで公開鍵を送信して、Webサービスがその署名を検証できるようにします。
Webサービスがリクエストを受け取ると、次のことを行います。
秘密鍵を使用して、対称鍵を復号化します。
対称鍵を使用して、リクエスト・メッセージを復号化し、その署名を検証します。
リクエスト・メッセージ内のクライアントの公開鍵を使用して、その裏書署名を検証します。
クライアントにレスポンスを送信するために、Webサービスは次のことを行います。
リクエストとともに送信されたクライアントが生成した同じ対称鍵を使用して、レスポンス・メッセージに署名します。
クライアントが生成した同じ対称鍵を使用して、レスポンス・メッセージを暗号化します。
Oracle WSMエージェントはレスポンス・メッセージを受け取ると、次のことを行います。
最初に生成した対称鍵を使用して、レスポンス・メッセージを復号化します。
最初に生成した対称鍵を使用して、レスポンス・メッセージの署名を検証します。
クライアントとWebサーバーが、同じキーストアにアクセスする同じドメインにある場合は、同じ秘密/公開鍵のペアを共有できます。
つまり、クライアントが秘密鍵"orakey"を使用してリクエスト・メッセージの署名を裏書きし、公開鍵"orakey"を使用して対称鍵を暗号化できます。次に、Webサービスが公開鍵"orakey"を使用して裏書きを検証し、秘密鍵"orakey"を使用して対称鍵を復号化します。
デモの目的で、このユースケースでは1つの鍵ペアを作成します。
クライアントとWebサーバーが同じドメインになく、同じキーストアにアクセスしない場合は、クライアントとWebサービスは各自が秘密/公開鍵のペアを持つ必要があります。
表10-2に示すように、マルチドメインのユースケースで次の要件について考慮します。
表10-2 マルチドメインのユースケース要件
| Webサービス・クライアント | Webサービス |
|---|---|
|
クライアントのキーストアに独自の秘密/公開鍵のペアが必要です。 |
サービス・キーストアに独自の秘密/公開鍵のペアが必要です。 |
|
Webサービスの公開鍵が必要です。 |
クライアントのキーストア内の公開鍵に対応する中間証明書とルート証明書が必要です。 これらの証明書を使用して、信頼される証明チェーンを生成して署名を検証します。 |
|
実行時の対称鍵の生成 |
対称鍵が必要ですが、これはリクエスト・メッセージで送信されます。 |
クライアントが対称鍵を暗号化するために使用する公開鍵、つまりWebサービスの公開鍵については、次の2つのアプローチがあります。
「サービス・アイデンティティ証明拡張の使用」で説明されているように、Webサービスのbase64エンコードされた公開証明書は、Webサービス・クライアントが使用するためにWSDLでパブリッシュされます。そのため、この使用方法では、Webサービスの公開鍵はクライアントのキーストアになくても構いません。
証明書がWSDLでパブリッシュされていない場合、「構成」ページでkeystore.recipient.aliasの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。キーストア受信者の別名は、アウトバウンドSOAPメッセージの暗号化用のキーを取得するときにキーストア内の公開鍵を検索するために使用される別名を指定します。この方法では、Webサービスの公開鍵はクライアントのキーストアにある必要があります。
クライアント・ポリシーのsaml.issuer.nameプロパティは、SAMLトークンの発行者とwww.oracle.comの値のデフォルトを特定します。このユースケースでは、www.oracle.comデフォルトを使用します。
オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
ポリシーで別のSAML認証局(発行者)を使用する場合は、その発行者名をクライアントで構成し、SAMLログイン・モジュール内の使用可能な発行者のリストに含める必要があります。この方法については、「別のSAMLアサーション発行者名の追加」を参照してください。
この項では、SAMLメッセージ保護のユースケースを構成する手順について説明します。次の項目について説明します。
SAMLトークン内のユーザーは、WebLogic Serverアイデンティティ・ストアにすでに存在している必要があります。
Webサービスのランタイムは、WS-SecurityヘッダーからSAMLトークンを抽出し、SAMLトークン内の名前を使用してWebLogic Serverアイデンティティ・ストアに対してユーザーを検証します。
特に、SAMLログイン・モジュール(「SAMLおよびKerberosログイン・モジュールの構成」を参照)では、WebサービスのかわりにSAMLトークンが検証されます。次に、SAMLログイン・モジュールは認証を完了するために、検証されたトークンからユーザー名を抽出し、Oracle Platform Security Services(OPSS)に(間接的に)渡します。
デフォルトの認証プロバイダなど、構成済のWebLogic Server認証プロバイダをここで呼び出すことができます。
ユーザーの作成
Oracle WebLogic Server管理コンソールのヘルプで説明されているように、WebLogic Server管理コンソールを使用して、ユーザーをアイデンティティ・ストアに追加します。
便宜のために、ここにも手順を掲載します。
WebLogic Server管理コンソールでユーザーを作成する手順
左側のペインで、「セキュリティ・レルム」を選択します。
「セキュリティ・レルム」ページの「サマリー」で、レルムの名前を選択します(たとえば、myrealm)。
「レルム名」ページの「設定」で、「ユーザーとグループ」→「ユーザー」を選択します。
「ユーザー」表に、管理プロバイダで定義されているすべてのユーザーの名前が表示されます。
「新規」をクリックします。
「新規ユーザーの作成」ページの「名前」フィールドに、ユーザーの名前を入力します。
ユーザー名は大文字と小文字が区別され、一意である必要があります。カンマ、タブ、および次の「、」で区切ったリストの文字は使用しないでください。<>、#、|、&、?、( )、{ }
(オプション)「説明」フィールドに説明を入力します。説明は、ユーザーの完全な名前にします。
「プロバイダ」ドロップダウン・リストで、ユーザーの認証プロバイダを選択します。
セキュリティ・レルムに複数のWebLogic認証プロバイダが構成されている場合は、それらがリストに表示されます。新規ユーザーの情報を格納するWebLogic認証プロバイダのデータベースを選択します。
「パスワード」フィールドに、ユーザーのパスワードを入力します。
WebLogic認証プロバイダで定義されるユーザーの最大パスワード長は8文字です。
「パスワードの確認」フィールドにユーザーのパスワードを再入力します。
「OK」をクリックして変更内容を保存します。
ユーザー名が「ユーザー」表に表示されます。
この項では、keytoolユーティリィティによるJavaキーストアの作成および管理のアウトラインを示します。また、キーストアを作成し、秘密鍵および信頼できるCA証明書をロードする方法について説明します。
keytoolユーティリティのコマンドや引数の詳細は、Webサイト(http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html)を参照してください。
|
注意: -genkeyコマンドを使用してエンティティをキーストアに追加してキーペア(公開鍵と秘密鍵)を生成する場合、または-importコマンドを使用して証明書または証明書チェーンを信頼できる証明書のリストに追加する場合は、別名を指定します。 その後のkeytoolコマンドでは、この同じ別名を使用してエンティティを参照する必要があります。 |
新しいキー・ペアと自己署名証明書を作成します。
genKeyコマンドを使用してキー・ペア(公開鍵と秘密鍵)を作成します。秘密鍵が存在しない場合、genKeyは新しい秘密鍵を作成します。
次のコマンドでは、署名アルゴリズムRSA-SHA1とdefault-keystore.jksキーストアの別名「orakey」を使用して、RSA鍵が生成されます。任意の別名を選択できます。別名を「orakey」にする必要はありません。
keytool -genkey -alias orakey -keyalg "RSA" -sigalg "SHA1withRSA" -dname "CN=test, C=US" -keystore default-keystore.jks
keytoolユーティリティから必要な鍵とキーストアのパスワードを要求するプロンプトが表示されます。これらのパスワードは後で必要になります。
認証局への証明書リクエストを生成します。
リクエストの生成には、-certreqコマンドを使用します。次のコマンドでは、orakey別名の証明書リクエストが生成されます。
CAから証明書または証明書チェーンが返されます。
keytool -certreq -alias orakey -sigalg "SHA1withRSA" -file certreq_file -storetype jks -keystore default-keystore.jks
自己署名証明書を信頼できるCA証明書で置き換えます(インポートします)。
既存の自己署名証明書をCAから返される証明書で置き換える必要があります。これを実行するには、-importコマンドを実行します。次のコマンドでは、default-keystore.jksキーストアの信頼できるCA証明書で置き換えます。keytoolユーティリティから必要なパスワードを要求するプロンプトが表示されます。
keytool -import -alias orakey -file certreq_file -keystore default-keystore.jks
次の手順を実行して、Oracle Web Services Managerキーストアを構成します。
ナビゲータ・ペインで「WebLogicドメイン」を開き、キーストアの構成が必要なドメインを表示します。ドメインを選択します。
Fusion Middleware Controlを使用して、「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」をクリックします。
ページの下部近くにある「キーストア」コントロールのプラス記号(+)をクリックして開き、「構成」をクリックします。
図10-3に示すように、Web Services Managerの「キー・ストアの構成」ページが表示されます。
「キーストア管理の構成」チェック・ボックスがまだ選択されていない場合は、選択します。
作成するキーストアのパスと名前を入力します。デフォルトのキーストア名は、このユースケースで使用したように、default-keystore.jksです。キーストア・タイプはJKSにする必要があります。
キーストアのパスワードを入力して確認します。
署名と暗号化キーの別名とパスワードを入力します。
このユースケースでは、orakeyは署名と暗号化キーの両方の別名です。
パスワードを確認します。
「OK」をクリックして変更内容を送信します。
このページのフィールドを変更した場合、変更内容を反映するにはFusion Middleware Controlを再起動する必要があります。
「資格証明ストアへの鍵およびユーザー資格証明の追加」で説明されているように、復号化キーのパスワードは資格証明ストアに格納する必要があります。キー名としてkeystore.enc.csf.keyを使用します。
「単一のサブジェクトへのポリシーの添付」の説明に従って、wss11_saml_token_with_message_protection_service_policyをWebサービスに添付します。
ポリシー・アサーションを、メッセージの署名およびメッセージの暗号化に構成します。
デフォルトでは、リクエストおよびレスポンスの本体全体を署名および暗号化します。そのかわりに、特定の本体要素を指定して署名および暗号化する方法もあります。署名および暗号化するヘッダー要素を追加で指定することもできます。ここで設定したものは、クライアント・ポリシー設定と一致している必要があります。
|
注意: ore.sig.csf.key and keystore.enc.csf.key, as described in 「オーバーライド可能なWebサービス・ポリシーの添付」で説明されているように、keystore.sig.csf.keyおよびkeystore.enc.csf.keyをオーバーライドできます。 これらの値をオーバーライドする場合は、新しい値のキーがキーストアにあることが必要です。つまり、値をオーバーライドしても、これらのキーをキーストアに構成する必要がなくなるわけではありません。 |
「Webサービス・クライアントへのポリシーの添付」の説明に従って、wss11_saml_token_with_message_protection_client_policyをWebサービス・クライアントに添付します。
ポリシー・アサーションを、メッセージの署名、メッセージの暗号化またはその両方用に構成します。
デフォルトでは、本体全体を署名および暗号化します。そのかわりに、特定の本体要素を指定して署名および暗号化する方法もあります。署名および暗号化するヘッダー要素を追加で指定することもできます。ここで設定したものは、Webサービス・ポリシー設定と一致している必要があります。
「サービス・アイデンティティ証明拡張の使用」で説明されているように、Webサービスのbase64エンコードされた公開証明書は、Webサービス・クライアントが使用するためにWSDLでパブリッシュされます。WSDLの証明書は、デフォルトではサービスの公開鍵です。これはWeb Services Managerキーストアを構成したときに指定した暗号化キー("orakey")によって決まります。
そのため、keystore.recipient.aliasを設定または変更する必要はありません。
オプションで、「構成」ページでsaml.issuer.nameの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。saml.issuer.nameプロパティのデフォルトは、www.oracle.comです。詳細は、「SAML発行者をオーバーライドするタイミング」を参照してください。
「構成」ページでuser.roles.includeの値を指定できます。または、ポリシーを添付するときに「セキュリティ構成の詳細」コントロールを使用して、クライアントごとにこの値をオーバーライドできます。
ここでは、事前定義済WS-Trustポリシーおよびその構成と使用の方法について説明します。次の項目について説明します。
WS-Trust 1.3仕様は、セキュリティ・トークンのリクエストおよび発行を行う際の枠組みを提供するWS-Securityへの拡張機能と、ブローカ・トラスト関係への拡張機能を定義します。WS-Trust拡張機能は、セキュリティ・トークンの発行、更新および検証を行う方法を提供しています。
Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。WS-Trustの仕様で定義されているように、こうした資格証明は、信頼ブローカとして動作する信頼できるSecurityTokenService(STS)から取得できます。つまり、相互運用可能なセキュリティ・トークンを入手するには、Webサービス・クライアントとWebサービスの両者がそのSTSを信頼している必要があります。
この項の内容は次のとおりです。
一般的に、環境内には1つのSTSのみが存在します。数百の様々なWebサービスが存在し、そのすべてにこのSTS構成ポリシーがアタッチされていれば、ポリシーを変更することにより、異なるSTSを参照するようにすべてのWebサービスを簡単に変更できます。
この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構成としてメモリー内に保存されます。この情報はメモリー内にのみ格納され、Oracle WSM Repository内で永続化されません。(リポジトリの詳細は、第17章「Oracle WSMリポジトリの管理」を参照してください)。
WebサービスSTS構成ポリシーでSTS URIを指定し、それをWebサービスにアタッチした場合、クライアントでそのSTSの使用が強制されます。オーバーライドはできません。
自動ポリシー構成を使用せず、かわりにWebサービスを起動する前に、クライアントにSTS構成ポリシーをアタッチし、STSに関連する情報(port-endpoint、port-uri、公開鍵別名、STSへの認証に使用されるOracle WSMクライアント・ポリシーへの参照)をすべて指定します。この場合、STS構成ポリシーからのすべての情報が実行時にすでに使用可能です。
一般的なトークン・リクエスト/レスポンス・プロセスは、次のとおりです。この手順の詳細は、「WS-Trustのユースケースの例」に記載されているユースケースを参照してください。
Webサービス・クライアントでWebサービスを起動する必要があります。Oracle WSMエージェントは、WebサービスのWSDLをフェッチし、発行済トークン・サービス・ポリシーの抽出を試みます。Oracle WSMエージェントは、WSDLで識別されたSTSと対話するために、(必要に応じてオーバーライドされた)ローカル・クライアント・ポリシーを使用します。
Webサービス・ポリシーでは、特定のSTSから発行されるトークンを求めることができます。
Webサービス・クライアントは、STSにトークンの発行をリクエストします。Webサービス・クライアントは、特定のSTSにトークンをリクエストできます。
リクエスト・セキュリティ・トークン(RST)は、セキュリティ・トークンのリクエストです。RequestSecurityTokenResponse(RSTR)は、リクエスト・ユーザーの要求に伴って、STSによって生成されたRSTに対するレスポンスです。
Webサービス・クライアントは、STSによって送信されたRSTRを処理し、発行済トークンをWebサービスに伝播します。
Webサービスは、発行済トークンを処理および検証し、返信レスポンスを生成します。
ここでは、WS-Trustのユースケースの例について説明します。
Webサービス・クライアントは、Webサービスを起動します。WebサービスのWSDLは、Webサービスが特定のSTSからのセキュリティ・トークンを要求していることを示します。
Webサービス・クライアント(要求者)は、付随する資格証明とともに、認証リクエストをSTSに送信します。
STSは、クライアントによって提示された資格証明を検証した後、クライアントがSTSにより認証されたことを証明するセキュリティ・トークンをレスポンスで発行します。レスポンス・メッセージRSTRには、認証済ユーザーのトークンおよび(必要に応じて)要求が含まれます。
要求者はRSTRを検証し、トークンを抽出し、Webサービスに渡します。
Webサービスは、発行されたトークンを受信し、トークンが信頼できるSTSによって発行されたことを確認します。これによって、クライアントがSTSにより正常に認証されたことが証明されます。
Webサービスは、トークンが検証されると、リクエストを処理し、応答を返信します。
図10-28に、要求者、STSおよびWebサービス間のメッセージ・フローを示します。
「On Behalf Of」は、Webサービス・クライアントが別のエンティティに代わってSTSトークンをリクエストするアイデンティティ伝播ユースケースです。
次のシナリオを考えてみます。
Webサービス・クライアントは、別のエンティティのトークンを取得するためにSTSを起動します。このエンティティは、エンド・ユーザーまたはその他の外部エンティティでもかまいません。エンティティの資格証明は、onBehalfOf要素のRSTに含まれます。
STSは、Webサービス・クライアントによって提示された資格証明を検証し、onBehalfOf要素内で識別済エンティティのセキュリティ・トークンを発行します。
Webサービス・クライアントはRSTRを検証し、トークンを抽出し、Webサービスに渡します。
Webサービスは、エンド・ユーザーのSAMLアサーションを受信し、トークンが信頼できるSTSによって発行されたことを確認します。
「On Behalf Of」ユースケースは、表8-4に記載されている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鍵を使用して確立されたアイデンティティが他のエンティティに代わって送信されます。この場合は、パスワードを持つユーザー名またはパスワードを持たないユーザー名です。
STSからのRSTRレスポンス・メッセージには、返されたトークンの妥当性を示す存続期間要素(<trust:Lifetime>)が含まれる場合があります。存続期間要素が存在する場合、Oracle WSMはタイムスタンプを検証し、レスポンスが期限切れであればメッセージを拒否します。
STSは、理論的にはクライアントから任意のトークンを受信でき、それを他の任意のトークンに交換できますが、実際には一般に次のいずれかのトークンを受け入れ、SAMLアサーションを返します。
ユーザー名トークン。このトークン・タイプの場合:
Webサービス・クライアントは、ユーザー名とパスワードをSTSに送信します。
STSはパスワードを検証し、SAMLアサーションを返します。
クライアントは、WebサービスにSAMLアサーションを送信します。
このシナリオは、Webサービスにはパスワードを検証する機能がなく、したがってパスワードの検証をSTSに依存する場合に役立ちます。
Kerberosトークン。このトークン・タイプの場合:
クライアントはユーザー名とパスワードをKDCに送信し、Kerberosトークンを取得します。
クライアントはKerberosトークンをSTSに送信し、SAMLアサーションを取得します。
クライアントは、WebサービスにSAMLアサーションを送信します。
このシナリオは、Windows環境で役立ちます。Windowsマシン上で実行するクライアントはログオン済ユーザー・コンテキストを持ち、このコンテキストを使用して該当ユーザーのSTSからSAMLアサーションを取得できます。
このシナリオでは、クライアントはパスワードを持たず、したがってユーザー名トークンは使用できません。Kerberosのみを使用できます。
X509トークン - このトークン・タイプでは、クライアントは自身をSTSに対して認証するために秘密鍵を使用します。
これを受けてSTSは、一般に次のいずれかのトークンを返します。
SAML対称鍵所有者。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>要素は存在しません。証明鍵は暗黙に示されます。
Oracle WSMエージェントは、署名および暗号化のための鍵の内容としてクライアント・エントロピを使用します。
鍵の部分的内容としてクライアント・エントロピを受け入れ、両鍵の部分的内容の関数として証明鍵を計算するために、鍵の部分的内容として追加STSサーバー側エントロピを提示します。
STSにより提供されたエントロピを含む<wst:Entropy>要素がRSTR内に存在します。また、RSTRには<wst:RequestedProofToken>要素があり、この要素には計算鍵のメカニズムが含まれます。アルゴリズムのデフォルト値は、http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1です。
Oracle WSMエージェントおよびSTSは、指定された計算鍵メカニズムを使用して両方のエントロピを組み合せることにより、証明鍵を計算します。
クライアント側エントロピを拒否し、単独鍵の内容としてSTSサーバー側エントロピを証明鍵に使用します。
証明鍵を含む<wst:RequestedProofToken>要素がRSTR内に存在します。Oracle WSMエージェントは、署名および暗号化のための鍵の内容として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送信者保証トークンを取得したことを認識しておらず、クライアントの署名をチェックします。
自動ポリシー構成では、STS WSDLドキュメントを解析することにより、STSに関する情報を動的に生成します。
STS構成ポリシーが(クライアントではなく)Webサービスにアタッチされている場合、クライアントからサーバーへの最初の接続で実行時に自動ポリシー構成が行われます。
STS構成ポリシー(oracle/sts_trust_config_service_policy)で提供する情報は、ターゲットSTSのport-uriのみです。このポリシーが(発行済トークン・サービス・ポリシーとともに)Webサービスにアタッチされた場合、STSのport-uriがWebサービスWSDLのIssuedTokenアサーションに発行者アドレスとして示されます。
その結果としてOracle WSMは、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の公開証明書をOracle WSMキーストアにインポートします。
必要に応じて、「証明書の署名用の信頼できる発行者および信頼できるDNリストの定義」の説明に従って、信頼できるSTSリストにSTSのDNを追加します。
SAML HOK対称を使用する場合は、WebサービスおよびWebサービスの証明書のエントリをOracle OpenSSO STS構成に追加する必要があります。STSは、この証明書を使用して対称鍵を暗号化します。
sts_trust_config_service_policyポリシーのコピーを作成します。
orasp:port-uriフィールドを編集し、STSのport-uriを追加します。
STSは通常、様々な入出力トークン・タイプの複数のURIポイントを公開しているので、必要なトークンに対応するURIを使用します。Oracle OpenSSO STSでは、orasp:port-uriの可能な値は次のとおりです。
http://<host:port>/openssosts/sts/wss10x509
http://<host:port>/openssosts/sts/wss10un
http://<host:port>/openssosts/sts/wss11kerberos
https://<host:ssl_port>/openssosts/sts/tlswss10un
自動ポリシー構成のためのWebサービス・クライアントの構成
自動ポリシー構成の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。
ユースケースに応じて、発行済トークン・ポリシーの次のプロパティを設定またはオーバーライドします。プロパティの説明は、表8-4を参照してください。
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キーストア内で使用可能であることを確認します。この方法の詳細は、「メッセージ保護に関するキーストアの構成」を参照してください。
自動ポリシー構成のためのWebサービスの構成
編集したsts_trust_config_service_policyをWebサービスにアタッチします。
|
注意:
|
(クライアントにアタッチされたポリシーに対応する)発行済トークンのサービス・ポリシーをアタッチします。次の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をオーバーライドします。
Oracle WSMキーストアでクライアントの公開鍵が使用可能であることを確認します。
「STSの自動ポリシー構成の設定」の説明に従って、WebサービスからSTS構成ポリシーを構成することをお薦めします。ただし、次の条件では、Webサービス・クライアントから構成する必要があります。
WebサービスからSTS構成ポリシーを構成しなかった場合、または
SAML送信者保証確認の方法を使用している場合、または
JSEクライアントを使用している場合。自動ポリシー構成は、JSEクライアントでは動作しません。
Webサービス・クライアントからSTS構成ポリシーを構成するには、次の手順を実行します。
必要に応じて、Fusion Middleware Controlを使用して、oracle/sts_trust_config_template(「新しいWebサービス・ポリシーの作成」を参照してください)または既存のoracle/sts_trust_config_client_policyポリシー(「既存のポリシーからのWebサービス・ポリシーの作成」を参照してください)から新しいポリシーを作成します。
一意のポリシーを使用することで、構成がより明確になる場合もあります。
Fusion Middleware Controlを使用して、選択したoracle/sts_trust_config_client_policyポリシーを編集します。
例10-9に事前定義済のoracle/sts_trust_config_client_policyポリシーを示します。少なくとも、次の情報を提供する必要があります。
発行者アドレス - Port-uriは、STSの実際のエンドポイントのURIです。
Oracle WSMセキュリティ・ポリシー参照 - policy-reference-uriは、STSと通信するためにクライアントによって使用されるクライアント・ポリシーURIです。WSDLでの識別に従い、選択するポリシーはSTSの認証要件に応じて異なります。
このパラメータを設定する方法によって、後ほど発行トークン・クライアント・ポリシーで設定またはオーバーライドする必要がある対象が決まります。
policy-reference-uriポリシーを参照する場合、STSに対して認証し、ユーザー名トークンを作成するためのsts.auth.user.csf.keyパラメータの構成を行います。また、署名鍵および暗号化鍵の別名を指定するためのsts.auth.x509.csf.keyの構成を行います。
policy-reference-uriでx509ベースのポリシーを参照する場合、STSに対する認証用のX509証明書を指定するためのsts.auth.x509.csf.keyパラメータの構成を行います。
port-endpoint - target-namespace#wsdl.endpoint(service-name/port-name)として指定するWebサービスのエンドポイントです。
STS証明書の別名 - sts-keystore-recipient-aliasは、キーストアに追加したSTS証明書の別名です。デフォルトの別名はsts-csf-keyです。
例10-9 oracle/sts_trust_config_client_policy
<orasp:sts-trust-config xmlns:orasp="http://schemas.oracle.com/ws/2006/01/securitypolicy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" orasp:policy-reference-uri="oracle/wss10_username_token_with_message_protection_client_policy" orasp:port-endpoint="target-namespace#wsdl.endpoint(service-name/port-name)" orasp:port-uri="http://host:port/sts-service" orasp:soap-version="12" orasp:sts-keystore-recipient-alias="sts-csf-key" orasp:wsdl-uri="http://host:port/sts?wsdl" orawsp:Enforced="true" orawsp:Silent="true" orawsp:category="security/sts-config" orawsp:name="STS Trust Configuration"> <orawsp:bindings> <orawsp:Config orawsp:configType="declarative" orawsp:name="StsTrustConfig"> <orawsp:PropertySet orawsp:name="standard-security-properties"> <orawsp:Property orawsp:contentType="constant" orawsp:name="role" orawsp:type="string"> <orawsp:Value>ultimateReceiver</orawsp:Value> </orawsp:Property> </orawsp:PropertySet> </orawsp:Config> </orawsp:bindings> </orasp:sts-trust-config>
変更を保存します。
表10-3のクライアント・ポリシーから発行トークン・クライアント・ポリシーを選択します(まだそうしていない場合)。次を選択できます。
oracle/wss_sts_issued_saml_bearer_token_over_ssl_client_policy
oracle/wss11_sts_issued_saml_hok_with_message_protection_client_policy
oracle/wss11_sts_issued_saml_with_message_protection_client_policy
「オーバーライド可能なクライアント・ポリシーの添付」の説明に従って、Webサービス・クライアントに双方のWebサービス・クライアント・ポリシーをアタッチします。ポリシーは次の順序でアタッチする必要があります。
sts_trust_config_client_policy
発行済トークン・クライアント・ポリシー
oracle/sts_trust_config_client_policyの複数のインスタンスをアタッチした場合に、エラーは生成されません。しかし、実行されるのは1つのインスタンスのみであり、それをどのインスタンスにするかを制御できません。
Fusion Middleware Controlを使用して、選択した発行トークン・クライアント・ポリシーを編集します。
変更を保存します。
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の自動ポリシー構成の設定」を参照してください)。
表10-3に、使用可能なWS-Trustポリシーを示します。
表10-3 使用可能なWS-Trustポリシー
| 名前 | 説明 |
|---|---|
|
oracle/sts_trust_config_service_policy |
このポリシーを使用して、トークン交換のためにSTSの起動に使用されるSTS構成情報を指定します。このポリシーは、Webサービスで使用します。 |
|
oracle/sts_trust_config_client_policy |
このポリシーを使用して、トークン交換のためにSTSの起動に使用されるSTS構成情報を指定します。自動ポリシー構成を使用しない場合にのみ、Webサービス・クライアントでこのポリシーを使用します。 |
|
oracle/wss_sts_issued_saml_bearer_token_over_ssl_client_policy |
このポリシーは、信頼できるSTSによって発行されたSAMLベアラー・アサーションを挿入します。メッセージは、SSLを使用して保護されます。 |
|
oracle/wss_sts_issued_saml_bearer_token_over_ssl_service_policy |
このポリシーは、WS-Security SOAPヘッダーの、確認方法がベアラーのSAMLトークンに含まれる資格証明を使用してユーザーを認証します。SAMLトークンの資格証明は、SAMLログイン・モジュールに対して認証されます。このポリシーは、トランスポート・プロトコルによりSSLメッセージ保護が提供されることを検証します。このポリシーは、SOAPベースのすべてのエンドポイントに適用できます。 |
|
oracle/wss11_sts_issued_saml_hok_with_message_protection_client_policy |
このポリシーは、信頼できるSTSによって発行されたSAML HOKアサーションを挿入します。メッセージは、STSによって提供される証明鍵の内容によって保護されます。 |
|
oracle/wss11_sts_issued_saml_hok_with_message_protection_service_policy |
このポリシーは、信頼できるSTSによって発行されたSAML HOKアサーションを認証します。メッセージは、対称鍵テクノロジのWS-SecurityのBasic 128スイートを使用して保護されます。 |
|
oracle/wss11_sts_issued_saml_with_message_protection_client_policy |
このポリシーは、信頼できるSTSによって発行されたSAML送信者保証アサーションを挿入します。メッセージは、クライアントの秘密鍵を使用して保護されます。 |
表11-2に、プログラムによる構成のオーバーライドを利用して特定のポリシーに設定できるプロパティを示します。
表10-4は、STSプロパティをプログラムによってオーバーライドする方法を示す一連のサンプル・ユースケースを示しています。
表10-4 STSのプログラムによる構成のユースケース
| ユースケース | サンプル・コード |
|---|---|
|
トークン交換ユーザー名トークン - 対称証明鍵によるSAML |
|
|
トークン交換x509トークン - 対称証明鍵によるSAML |
|
|
トークン交換ユーザー名トークン - 非対称証明鍵によるSAML |
|
|
トークン交換x509トークン - 非対称証明鍵によるSAML |
|
|
サブジェクトからのOn Behalf Ofユーザー名と要求者トークン・ユーザー名のOn Behalf Ofトークンの交換 - 対称証明鍵によるSAML |
|
|
On Behalf Ofユーザー名と要求者トークン・ユーザー名のOn Behalf Ofトークンの交換 - 対称証明鍵によるSAML |
|
|
On Behalf Ofユーザー名と要求者トークンx509のOn Behalf Ofトークンの交換 - 対称証明鍵によるSAML |
|
|
サブジェクトからのOn Behalf Ofユーザー名と要求者トークン・ユーザー名のOn Behalf Ofトークンの交換 - 非対称証明鍵によるSAML |
|
|
On Behalf Ofユーザー名と要求者トークン・ユーザー名のOn Behalf Ofトークンの交換 - 非対称証明鍵によるSAML |
(
|
|
On Behalf Ofユーザー名と要求者トークンx509のOn Behalf Ofトークンの交換 - 非対称証明鍵によるSAML |
|
Oracle WSMでは、標準WS-Trustクライアントを提供しています。このクライアントは、OpenSSO STSサーバーと相互運用できることが認定されています。OpenSSO STSサーバーの使用例のシナリオの詳細は、「OpenSSO STSでのWS-Trustの使用例」を参照してください。
次の項では、以降のセキュリティのシナリオを構成するためにOpen SSO Security Token Service (STS)サーバーでWS-Trustを使用したエンド・ツー・エンドの例を紹介しています。
次に、ここで説明する各例のシナリオで使用するためのOpenSSO STSの構成に必要な手順を示します。
OpenSSO STSインスタンスにログインします。
「構成」→「グローバル」→「セキュリティ・トークン・サービス」に移動します。
「セキュリティ」→セキュリティ・メカニズム→STSサービスによって受け入れられるセキュリティ・トークンで、すべてのオプションを有効にします。
ユーザー・トークンの資格証明セクションで必要に応じて、名前とパスワードのセットを含むトークンの新しい資格証明を追加します。これには、test/testを設定します。
On Behalf ofトークンセクションで、On Behalf ofトークンの認証チェーンドロップダウンリストから「ldapService」eを選択します。
「署名」セクションで、次のオプションを有効にします。
- リクエストの署名は検証済
- レスポンスの署名は有効(「本文」および「タイムスタンプ」を選択します)
「暗号化」セクションで、次のオプションを有効にします。
- 「暗号化は必要」(「本文」および「ヘッダー」を選択します)
- レスポンスは暗号化済
「暗号化アルゴリズム」ドロップダウン・リストから「AES」を選択し、暗号化強度ドロップダウン・リストから128を選択します。
メッセージ保護要求者トークンとともにWS-Security 1.1 Kerberosトークンをサポートするには、Kerberosの構成セクションで次の値を構成します。
SSLをサポートするには、次の手順を実行します。
トークン発行属性セクションで、OpenSSOインスタンスに基づいてSSLエンドポイントを編集します。
「署名」で、トランスポートがSSLにより保護されている場合に署名の検証を無効にするオプションを有効にします。
「暗号化」で、トランスポートがSSLにより保護されている場合に復号化を無効にするオプションを有効にします。
OpenSSO STSをホストするサーバー上でSSLをサポートするには:
OpenSSO STSをホストするWebLogic ServerでSSLを構成する場合は、「SSLに関するキーストアの構成」に記載されている手順を実行します。
Open SSO STSをホストするGlassfishサーバーの場合は、次の手順を実行します。
次のコマンドを発行することによりアプリケーション・サーバーのための新しい鍵ペアを生成します。
keytool -genkey -keyalg <algorithm for generating the key pair> -keystore keystore.jks -validity <days> -alias <alias_name>
たとえば、次のようにします。
keytool -genkey -keyalg RSA -keystore <glassfish_install_dir>/domains/<sts_deploy_domain>/config/keystore.jks -validity 365 -alias owsm
氏名の入力を求めるプロンプトが表示されたら、証明書を生成する対象のマシンのホスト名を入力します。また、他のプロンプトでも、該当する詳細を入力します。
次のコマンドを発行することにより証明書署名リクエスト(CSR)を生成します。
keytool -certreq -alias owsm -file owsm.csr -keystore keystore.jks -storepass changeit
有効な証明書を取得するために、生成後にowsm.csrファイルに書き込まれたリクエストを認証局に送信する必要があります。たとえば、OpenSSO QAチームによって維持されている証明書管理サーバー(https://mahogany.red.iplanet.com)に送信します。
証明書管理サーバー(https://mahogany.red.iplanet.com)にアクセスし、左側のペインでSSLサーバーをクリックし、.csrファイルの「BEGIN CERTIFICATE REQUEST」から「END CERTIFICATE REQUEST」までの内容をPKCS # 10リクエストフィールドに貼り付けます。
必要に応じてその他のフィールドに入力し、リクエストを送信します。リクエストが承認されると、同じページの取得タブから証明書を取得できます。
BEGIN CERTIFICATEからEND CERTIFICATEの証明書の内容(PKCS # 7形式)を.cert拡張子のファイルにコピーし、次のkeytoolコマンドを使用することによりサーバー証明書を<glassfish_install_dir>/domains/<sts_deploy_domain>/config/keystore.jksファイルにインポートします。
keytool -import -v -alias owsm -file owsm.cert -keystore keystore.jks -storepass changeit
証明書を信頼する場合は、プロンプトが表示されたら「YES」を入力します。
認証局のSSL証明書にアクセスします。https://mahogany.red.iplanet.comにアクセスし、SSLサーバー→取得タブ→証明書のリスト→「検索」に移動します。ページの最初の「詳細」ボタンをクリックし、BASE64でエンコードされた証明書を別の.certファイルにコピーします(例: mahogany.cert)。
次のコマンドを使用して、この証明書を別名「rootca」として<glassfish_install_dir>/domains/<sts_deploy_domain>/config/cacerts.jksファイルにインポートします。
keytool -import -v -alias rootca -file mahogany.cert -keystore cacerts.jks -storepass changeit
クライアント側のtruststore.jksファイルについても、前述の手順を繰り返すことが必要になる場合があります。該当ファイルから既存のrootca別名を削除し、前述のように新たにインポートします(キーストア・ファイルの場所を変更します)。
新しい証明書でGlassFishを構成するために、http://hostname:admin-port/で管理コンソールにアクセスします。「構成」→HTTPサービス→http-listener2 (デフォルトSSL対応ポート)→「SSL」に移動し、証明書のニックネームをs1as(自己署名証明書)からowsmに変更します。
Glassfishを再起動します。
次の手順では、OpenSSO STSでWS-Trustを使用してメッセージ保護付きでSAML鍵所有者を構成する方法について説明します。この例のシナリオでは、WebLogic WebサービスおよびSOAコンポジット・クライアントを使用します。
OpenSSO STSでWS-Trustを使用してメッセージ保護付きでSAML鍵所有者を構成するには:
「OpenSSO STSの構成」の説明に従って、OpenSSO STSを構成します。
「自動ポリシー構成のためのポリシーの構成」の手順に従ってSTSサービス・ポリシーを構成します。
後述するように、oracle/sts_trust_config_service_policyをコピーし、要求者トークン・タイプに基づいてポリシー構成を編集します。
メッセージ保護要求者トークンでWS-Security 1.0ユーザー名トークンをサポートするには:
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10un"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss10un?wsdl"(オプション)
メッセージ保護要求者トークンでSSL経由でWS-Security 1.0ユーザー名トークンをサポートするには:
orasp:port-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un"
orasp:wsdl-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un?wsdl"(オプション)
メッセージ保護要求者トークンでWS-Security 1.0 X509トークンをサポートするには:
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10x509"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss10x509?wsdl"(オプション)
メッセージ保護要求者トークンでWS-Security 1.1 Kerberosトークンをサポートするには:
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss11kerberos"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss11kerberos?wsdl"(オプション)
「自動ポリシー構成のためのWebサービスの構成」の手順に従ってWebサービス・ポリシーを構成します。
手順2で作成したポリシー、その後でoracle/wss11_sts_issued_saml_hok_with_message_protection_service_policyをWebLogic Webサービスにアタッチします。詳細は、「単一のサブジェクトへのポリシーの添付」を参照してください。
|
注意: デフォルトでは、oracle/wss11_sts_issued_saml_hok_with_message_protection_service_policyポリシーはトークン・タイプSAML 1.1により構成されています。このトークン・タイプをSAML 2.0で構成する場合は、「既存のポリシーからのWebサービス・ポリシーの作成」の説明に従って、ポリシーをコピーして編集する必要があります(この値はクライアント・ポリシーに一致する必要があります)。 |
「自動ポリシー構成のためのWebサービス・クライアントの構成」の手順に従ってWebサービス・クライアント・ポリシーを構成します。
SOAコンポジット・クライアントにoracle/wss11_sts_issued_saml_hok_with_message_protection_client_policyポリシーをアタッチし、要求者トークンの必要に応じて、表8-4に記載されているクライアント構成プロパティをオーバーライドします。
sts.auth.user.csf.keyには、デフォルトのOpenSSO STS構成で使用可能なユーザー資格証明を設定する必要があります。つまり、ユーザー名test、パスワードtestです。ただし、X509要求者トークンでは設定する必要はありません。
|
注意: ポリシーをアタッチする場合のクライアント構成プロパティのオーバーライドの詳細は、「Webサービス・クライアントへのポリシーの添付」を参照してください。 デフォルトでは、 oracle/wss11_sts_issued_saml_hok_with_message_protection_client_policyポリシーはトークン・タイプSAML 1.1により構成されています。このトークン・タイプをSAML 2.0で構成する場合は、「既存のポリシーからのWebサービス・ポリシーの作成」の説明に従って、ポリシーをコピーして編集する必要があります(この値はサービス・ポリシーに一致する必要があります)。 |
次の手順では、OpenSSO STSでWS-Trustを使用してメッセージ保護付きでSAML送信者保証を構成する方法について説明します。この例のシナリオでは、WebLogic WebサービスおよびSOAコンポジット・クライアントを使用します。
OpenSSO STSでWS-Trustを使用してメッセージ保護付きでSAML送信者保証を構成するには:
「OpenSSO STSの構成」の説明に従って、OpenSSO STSを構成します。
「Webサービス・クライアントからのSTS構成ポリシーの手動による構成: メイン手順」の手順に従って、クライアント側のSTSポリシーを構成します。
oracle/sts_trust_config_client_policyをコピーし、要求者トークン・タイプに基づいてポリシー構成を編集します。
メッセージ保護要求者トークンでWS-Security 1.0ユーザー名トークンをサポートするには:
orasp:policy-reference-uri="oracle/wss10_username_token_with_message_protection_client_policy"
orasp:port-endpoint="http://<host>:<port>/openfm/SecurityTokenService/#wsdl.endpoint(SecurityTokenService/ISecurityTokenService_Port_UN_WSS10_SOAP12):
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10un"
orasp:sts-keystore-recipient-alias="test"
メッセージ保護要求者トークンでSSL経由でWS-Security 1.0ユーザー名トークンをサポートするには:
orasp:policy-reference-uri="oracle/wss_username_token_over_ssl_client_policy"
orasp:port-endpoint="http://localhost:8080/openfm/SecurityTokenService/#wsdl.endpoint(SecurityTokenService/ISecurityTokenService_Port_TLS_UN_WSS10_SOAP12)"
orasp:port-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un"
orasp:sts-keystore-recipient-alias="test"
メッセージ保護要求者トークンでWS-Security 1.0 X509トークンをサポートするには:
orasp:policy-reference-uri="oracle/wss10_x509_token_with_message_protection_client_policy"
orasp:port-endpoint="http://localhost:8080/openfm/SecurityTokenService/#wsdl.endpoint(SecurityTokenService/ISecurityTokenService_Port_X509_WSS10_SOAP12)"
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10x509"
orasp:sts-keystore-recipient-alias="test"
WebLogic Webサービスにoracle/wss11_saml_token_with_message_protection_service_policyポリシーをアタッチし(SAML送信者保証のシナリオでは対応する発行済トークン・ポリシーはありません)、サービスの暗号化鍵の別名およびパスワードを指定するためにkeystore.enc.csf.keyをオーバーライドします。
|
注意: デフォルトでは、oracle/wss11_saml_hok_with_message_protection_service_policyポリシーはトークン・タイプSAML 1.1により構成されています。このトークン・タイプをSAML 2.0で構成する場合は、「既存のポリシーからのWebサービス・ポリシーの作成」の説明に従って、ポリシーをコピーして編集する必要があります |
手順2で作成したポリシー、その後でoracle/ws11_sts_issued_saml_with_message_protection_client_policyポリシーをSOAコンポジット・クライアントにアタッチし、要求者トークンの必要に応じて、表8-4に記載されているクライアント構成プロパティをオーバーライドします。
「On Behalf Of」ユースケースは、表8-4に記載されているsts.auth.on.behalf.of.csf.keyプロパティおよびon.behalf.ofプロパティに依存します。詳細は、「On Behalf Ofユースケース」を参照してください。
on.behalf.ofプロパティをtrueに設定する必要があります。sts.auth.on.behalf.of.csf.keyには、「on behalf of」ユースケースをサポートするデフォルトのOpen SSO STS構成で使用可能なユーザー資格証明を設定する必要があります。つまり、demo、パスワードchangeitです。
ユーザーに「代わって(on behalf of)」OpenSSO STSからのトークンをリクエストする権限をクライアント・アプリケーションに付与するために、<MW_HOME>/user_projects/domains/base_domain/config/fmwconfig/system-jazn-data.xmlファイルを編集して次のコードを含めます。
<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=<Client App. Name></name>
<actions>assert</actions>
</permission>
</permissions>
</grant>
次の手順では、OpenSSO STSでWS-Trustを使用してメッセージ保護付きでSAMLベアラーを構成する方法について説明します。この例のシナリオでは、WebLogic WebサービスおよびSOAコンポジット・クライアントを使用します。
OpenSSO STSでWS-Trustを使用してメッセージ保護付きでSAMLベアラーを構成するには:
「OpenSSO STSの構成」の説明に従って、OpenSSO STSを構成します。
「自動ポリシー構成のためのポリシーの構成」の手順に従ってSTSポリシーを構成します。
後述するように、oracle/sts_trust_config_service_policyをコピーし、要求者トークン・タイプに基づいてポリシー構成を編集します。
メッセージ保護要求者トークンでWS-Security 1.0ユーザー名トークンをサポートするには:
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10un"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss10un?wsdl"(オプション)
メッセージ保護要求者トークンでSSL経由でWS-Security 1.0ユーザー名トークンをサポートするには:
orasp:port-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un"
orasp:wsdl-uri="https://<host:ssl_port>/openssosts/sts/tlswss10un?wsdl"(オプション)
メッセージ保護要求者トークンでWS-Security 1.0 X509トークンをサポートするには:
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss10x509"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss10x509?wsdl"(オプション)
メッセージ保護要求者トークンでWS-Security 1.1 Kerberosトークンをサポートするには:
orasp:port-uri="http://<host>:<port>/openssosts/sts/wss11kerberos"
orasp:wsdl-uri="http://<host>:<port>/openssosts/sts/wss11kerberos?wsdl"(オプション)
「自動ポリシー構成のためのWebサービスの構成」の手順に従ってWebサービス・ポリシーを構成します。
手順2で作成したポリシー、その後でoracle/wss11_sts_issued_saml_bearer_token_over_ssl_service_policyをアタッチします。詳細は、「単一のサブジェクトへのポリシーの添付」を参照してください。
「自動ポリシー構成のためのWebサービス・クライアントの構成」の手順に従ってWebサービス・クライアント・ポリシーを構成します。
oracle/ws11_sts_issued_saml_bearer_token_over_ssl_client_policyポリシーをSOAコンポジット・クライアントにアタッチし、要求者トークンの必要に応じて、表8-4に記載されているクライアント構成プロパティをオーバーライドします。
sts.auth.user.csf.keyには、デフォルトのOpenSSO STS構成で使用可能なユーザー資格証明を設定する必要があります。つまり、ユーザー名test、パスワードtestです。ただし、X509要求者トークンでは設定する必要はありません。
