| Oracle Application Server Web Servicesセキュリティ・ガイド 10gリリース3（10.1.3） B31870-01 |
|
 戻る |
 次へ |
この章では、SOAPメッセージに対するメッセージ・レベル・セキュリティの構成方法について説明します。これにはキーストア、セキュリティ・トークン、署名および暗号の構成が含まれます。この章で使用される用語については、「Webサービス・セキュリティの概念」に説明があります。
この章の内容は次のとおりです。
この項では、Webサービス・セキュリティで使用できるキーストアの作成および構成の方法について説明します。また、パスワード・インダイレクションの採用によるキーストア、署名鍵および暗号鍵のパスワード保護の強化についても説明します。
|
注意: この項は、トラスト・ストア、証明書、公開鍵および秘密鍵などの公開鍵インフラストラクチャの概念についての知識がユーザーにあることを前提としています。あまり知識がない場合は、次のマニュアルおよびWebサイトでこれらの概要を参照してください。
|
キーストアは、使用可能な公開鍵および秘密鍵に関する情報を提供するファイルです。鍵は、認証やデータ整合性などの様々な目的に使用されます。次に例を示します。
データに署名するには、署名者の秘密鍵が必要です。
署名を検証するには、信頼できるCA証明書と、秘密鍵に一致する公開鍵が必要です。
データを暗号化するには、受信者の公開鍵が必要です。
データを復号化するには、公開鍵に対応する秘密鍵が必要です。
これらの信頼できる証明書と公開鍵および秘密鍵はキーストアに格納されます。Oracle Application Server Web Servicesセキュリティは、Oracle Wallet、PKCS12、およびSun社のJava Key Store（JKS）形式などの、様々なキーストアをサポートします。次の項では、信頼できる証明書の取得場所と、これらのキーストアの作成および使用方法について説明します。
ユーザーはVerisign社やEntrust社などのCertificate Authority（CA）から証明書を取得して、それをキーストアに格納できます。証明書を取得するには、証明書リクエストを作成してCAに提出する必要があります。CAは証明書の要求者を認証し、リクエストに基づいてデジタル証明書を作成します。ユーザーはその証明書をWalletに格納します。
Java Key Store（JKS）はSun社で定義された独自のキーストア形式です。JKSで鍵および証明書を作成して管理するには、Java JDKとともに配布されたkeytoolユーティリティを使用します。keytoolユーティリティを使用して次のタスクを実行できます。
公開鍵と秘密鍵のペアの作成、他のパーティに属す公開鍵に対する信頼対象としての指定、およびキーストアの管理。
適切なCertification Authority（CA）への証明書リクエストの発行、および結果として返された証明書のインポート。
ユーザー保有の公開鍵および秘密鍵のペアと関連付けられた証明書の管理。これによって、ユーザー保有の鍵および証明書を使用して、他のユーザーおよびサービスに対してユーザーを認証することができます。このプロセスは自己認証として知られています。また、デジタル署名を使用した、データ整合性および認証サービスに対してもユーザー保有の鍵および証明書を使用できます。
ユーザーの通信相手の公開鍵のキャッシュ。この鍵は証明書の形式でキャッシュされます。
次の項では、keytoolユーティリティによるJKSの作成および管理のアウトラインを示します。ここでは、キーストアの作成と、秘密鍵および信頼できるCA証明書のロードの方法を説明します。次のWebサイトで、keytoolユーティリティに対するコマンドおよび引数の詳細を参照できます。
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html
新規の秘密鍵と自己署名済の証明書を作成します。
秘密鍵を作成するにはgenKeyコマンドを使用します。このコマンドは、秘密鍵が存在しない場合は新規の秘密鍵を作成します。次のコマンドでは、RSA-SHA1という署名アルゴリズム、test.jksキーストアのtestという別名でRSA鍵が生成されます。
keytool -genkey -alias test -keyalg "RSA" -sigalg "SHA1withRSA" -dname "CN=test, C=US" -keypass test123 -keystore test.jks -storepass test123
デフォルトでは、鍵のペアを生成するためのアルゴリズム（keyalg）を省略した場合、genKeyコマンドはDSA鍵を生成します。署名アルゴリズム（sigalg）引数を省略した場合、署名アルゴリズムはkeyalgの値に基づいて導出されます。
keyalgおよびsigalg引数には、ユーザーの署名構成に基づいた正しい値を必ず使用してください。鍵のペアを生成するための基礎アルゴリズム（keyalg）がDSAの場合は、デフォルトの署名アルゴリズム（sigalg）のSHA1withDSAが使用されます。基礎のkeyalgがRSAの場合は、デフォルトのsigalg RSAwithMD5が使用されます。
キーストアを表示します。
次のコマンドではキーストアのコンテンツが表示されます。このコマンドではキーストアのパスワードが求められます。
keytool -list -v -keystore test.jks
信頼できるCA証明書をキーストアにインポートします。
証明書をインポートするには-importコマンドを使用します。次のコマンドは、信頼できるCA証明書をtest.jksキーストアにインポートします。このコマンドは、キーストアが存在しない場合は新規のキーストアを作成します。
keytool -import -alias aliasfortrustedcacert -trustcacerts -file trustedcafilename -keystore test.jks -storepass test123
証明書リクエストを生成します。
リクエストを生成するには-certreqコマンドを使用します。次のコマンドは、test別名用の証明書リクエストを生成します。CAは証明書または証明連鎖を返します。
keytool -certreq -alias test -sigalg "RSAwithSHA1" -file certreq_file -keypass test123 -storetype jks -keystore test.jks -storepass test123
自己署名済証明書を信頼できるCA証明書に置き換えます。
既存の自己署名済証明書を、CAからの証明書に置き換える必要があります。これを行うには、-importコマンドを使用します。次のコマンドは、test.jksキーストア内の信頼できるCA証明書を置き換えます。
keytool -import -alias test -file trustedcafilename -keystore test.jks -storepass test123
Oracle Walletは、公開鍵および秘密鍵とX.509証明書の格納と管理を行うためのキーストアとして機能します。Walletを作成するため、OracleにはORACLE_HOME/binディレクトリにorapkiユーティリティが用意されています。
この項では、orapkiユーティリティによるOracle Walletの作成および管理のアウトラインを示します。次のWebサイトでOracle Walletの詳細を参照できます。
http://www.oracle.com/technology/products/oid/oidhtml/sec_idm_training/html_masters/basics06.htm
orapkiユーティリティを使用したOracle Walletの作成および管理の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
「自己署名済証明書によるOracle Walletの作成方法」ではOracle Walletの作成、自己署名済証明書の追加およびエクスポートの方法を説明します。
「Oracle Walletとユーザー証明書の作成方法」では証明書リクエストおよびリプライの処理方法を説明します。ステップ1〜3では証明書リクエストの作成およびエクスポートの方法を説明します。
次に、自己署名済証明書によるOracle Walletの作成、Walletの表示、および証明書のエクスポートの手順を示します。
ルートOracle Walletを作成します。
orapki wallet create -wallet wallet_dir wallet_dir
このコマンドはwallet_dirディレクトリにルートOracle Walletを作成します。デフォルトでWalletはewallet.p12と名付けられます。
ルート証明書をOracle Walletに追加します。
orapki wallet add -wallet wallet_dir -dn 'CN=root_test,C=US' -keysize 2048 -self_signed -validity 3650
このコマンドは自己署名済（ルート）証明書をWalletに追加します。自己署名済証明書は3650日間の有効期限で作成されます。サブジェクトの識別名はCN=root_test,C=USです。証明書の鍵サイズは2048ビットです。
自己署名済証明書をOracle Walletからエクスポートします。
orapki wallet export -wallet wallet_dir -dn 'CN=root_test,C=US' -cert b64certificate.txt
このコマンドは自己署名済証明書をb64certificate.txtファイルにエクスポートします。使用される識別名は前のステップの識別名と同じなので注意してください。
ルートOracle Walletのコンテンツを表示します。
orapki wallet display -wallet wallet_dir
次に、Oracle Walletの作成、証明書リクエストの追加とエクスポート、および受け取った証明書のインポートの手順を示します。
自動ログインを有効にしてOracle Walletを作成します。
orapki wallet create -wallet server -auto_login
このコマンドは、自動ログインを有効にして/private/user/serverにOracle Walletを作成します。
証明書リクエストをOracle Walletに追加します。
orapki wallet add -wallet server -dn 'CN=server_test,C=US' -keysize 2048
このコマンドは証明書リクエストを、作成されたWalletに追加します。サブジェクトの識別名はCN=server_test,C=USです。指定された鍵サイズは2048ビットです。
Oracle Walletから証明書リクエストをエクスポートします。
orapki wallet export -wallet server -dn 'CN=server_test, C=US' -request creq.txt
このコマンドは証明書リクエストを指定されたファイルのcreq.txtにエクスポートします。識別名の順序が（証明書リクエストが作成されたときに）逆になるので注意してください。
テストのため、署名済証明書を証明書リクエストから作成します。
orapki cert create -wallet wallet_dir -request creq.txt -cert cert.txt -validity 3650
このコマンドは証明書cert.txtを3650日間の有効期限で作成します。証明書は前のステップで生成された証明書リクエストから作成されます。
証明書を表示します。
orapki cert display -cert cert.txt -complete
このコマンドは前のステップで生成された証明書を表示します。-completeオプションでは、シリアル番号や公開鍵などの追加的な証明書情報を表示できます。
信頼できる証明書をOracle Walletに追加します。
orapki wallet add -wallet server -trusted_cert -cert b64certificate.txt
このコマンドは信頼できる証明書のb64certificate.txtをWalletに追加します。ユーザー証明書を追加する前に、ユーザー証明書の証明連鎖内のすべての信頼できる証明書を追加する必要があります。
ユーザー証明書をOracle Walletに追加します。
orapki wallet add -wallet server -user_cert -cert cert.txt
このコマンドはユーザー証明書のcert.txtをWalletに追加します。
Oracle Walletのコンテンツを表示します。
orapki wallet display -wallet server
キーストア、署名および暗号の鍵はグローバル・レベルまたはポート・レベルで構成できます。Oracle Web Serviceセキュリティの実装ではJKS、PKCS12またはOracle Walletを使用するように構成できます。
グローバルのキーストアおよび鍵設定は、特定のOC4JインスタンスにデプロイされるすべてのWebサービス・アプリケーションに適用されます。グローバル・キーストアの詳細は、「キーストア要素」を参照してください。インスタンス・レベルのキーストアおよび鍵を構成するには、Application Server Controlツールを使用します。詳細は、Application Server Controlのオンライン・ヘルプでインスタンス・キーストアとID証明書の表示または変更に関するトピックを参照してください。
Oracle Webサービス・アプリケーションに対するキーストアおよび鍵を、インスタンスに属するものとは別に使用することができます。アプリケーション固有のキーストアおよび鍵設定は、インスタンス固有の設定より優先されます。
アプリケーション固有のキーストアおよび鍵を構成するには、<key-store>、<signature-key>および<encryption-key>要素をサーバーではoracle-webservices.xmlファイル、クライアントでは<generated_name>_Stub.xmlファイルの<security>要素の下に追加します。
例3-1にWebサービス・アプリケーションに対するキーストア構成を示します。キーストアの名前はmykeystore.jksで、これにアクセスするためのパスワードはabcです。
キーストア、署名鍵および暗号鍵などの多くのOC4Jコンポーネントでは、認証にパスワードが必要です。これらのパスワードをoracle-webservice.xmlなどのデプロイメント・ディスクリプタに埋め込むことは、特に対象ファイルであらゆるユーザーがパスワードを読み取ることが許可されている場合に、セキュリティ上のリスクを伴います。この問題を回避するため、パスワード・インダイレクションを採用します。パスワード・インダイレクションはクリアテキスト・パスワードを、別の場所にあるパスワードの参照に必要な情報に置き換えます。
キーストアおよび鍵のパスワードをインダイレクションするには、Application Server Control管理コンソールのインスタンス/アプリケーション・キーストア設定画面を使用します。この処理によってインダイレクションされたユーザー名およびパスワードのユーザー・エントリが、インスタンス固有のORACLE_HOME/j2ee/instance/config/system-jazn-data.xmlに自動的に追加されます。
|
関連資料: インダイレクション・パスワードの作成および使用の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
現在のリリースでは、Application Server Controlを使用して、キーストア、署名鍵および暗号鍵のパスワードを曖昧化する必要があります。曖昧化中は、間接ユーザーのアカウントはsystem-jazn-data.xmlファイル内に作成されます。
アプリケーションをアンデプロイする場合、これらの間接ユーザー・アカウントは削除されません。Application Server Controlを使用して、これらを手動で削除する必要があります。
次のリストは、グローバル・レベルおよびポート・レベルのキーストアと鍵に対する間接ユーザー・アカウントの名前をどのように識別するかを説明しています。
ポート・レベルのキーストアでは、間接ユーザー・アカウントの名前は次の書式で作成されます。
applicationName.portName.keystore.actual-keystore-name
次に例を示します。
my-security-sample.myport.keystore.myks.jks
グローバル・レベルのキーストアでは、間接ユーザー・アカウントの名前は次の書式で作成されます。
default.keystore.actual-keystore-name
次に例を示します。
default.keystore.myks.jks
ポート・レベルの鍵では、間接ユーザー・アカウントの名前は次の書式で作成されます。
applicationName.portName.key.actual-key-alias
次に例を示します。
my-security-sample.myport.key.mysignkey
グローバル・レベルの鍵では、間接ユーザー・アカウントの名前は次の書式で作成されます。
default.key.actual-key-alias
次に例を示します。
default.key.mysignkey
Web Servicesセキュリティでは、セキュリティ要素としてユーザー名、X.509またはSAMLトークンを採用できます。これらは、Oracle Containers for J2EEで定義された多くのセキュリティ・プロバイダと統合できます。Webサービス・セキュリティとOracleAS Web Servicesセキュリティ・フレームワークの統合の詳細は、「Webサービス・セキュリティの統合」を参照してください。
表3-1に、ユーザー名、X.509およびSAMLトークンについてサポートされているセキュリティ・プロバイダの一覧を示します。
表3-1 Webサービス・セキュリティでサポートされているセキュリティ・トークンとセキュリティ・プロバイダ
| トークン名 | ファイルベースのセキュリティ・プロバイダ（XML） | Oracle Identity Management（リリース10.1.2.0.xおよび10.1.4） | 外部LDAPセキュリティ・プロバイダ | カスタム・セキュリティ・プロバイダ | Oracle Access Manager（リリース7.0.4および10.1.4） |
|---|---|---|---|---|---|
|
ユーザー名トークン、プレーン・テキスト・パスワード |
○ |
○ |
○ |
○ |
○ |
|
ユーザー名トークン、ダイジェスト・パスワード |
○ |
× |
× |
× |
× |
|
X.509トークン |
○ |
○ |
○ |
× |
○ |
|
SAMLトークン |
○ |
○ |
○（ただし手動による構成が必要） |
× |
○ |
この項では、サーバーおよびクライアントに対するユーザー名トークンの構成方法について説明します。また、トークンとOC4Jセキュリティ・プロバイダとの統合方法も説明します。
サーバーでは、oracle-webservices.xmlデプロイメント・ディスクリプタでユーザー名トークンを構成します。サーバーのユーザー名トークンの構成には次のステップがあります。
パスワードを要求しないサービスの構成（オプション）
ダイジェスト・パスワードによるNonceキャッシュの構成（オプション）
このステップはダイジェスト・パスワードのみで必須です。
サーバー側のユーザー名トークンを構成するには、<verify-username-token>要素を使用します。この要素は、<inbound>要素の下位要素として1回だけ使用されます。<verify-username-token>要素の属性を使用すると、パスワードの詳細や、Nonceまたは作成時間をトークンに含むかどうかなどを構成できます。
パスワードの詳細はpassword-type属性で指定されます。パスワードはplaintextまたはdigestのどちらかに指定できます。plaintextは、暗号化されていない判読可能な形式のパスワードをトークンが要求することを示します。digestは、パスワードが（クリアテキストではなく）ダイジェスト形式で送信されたことを示します。つまり、暗号化チェックサム値が、トークンとともに送信されたパスワードについて計算済であることを示します。この値の目的は、パスワードが確実に改ざんされないようにすることです。パスワードの受信者（この場合はサーバー）は暗号化チェックサムを再計算して、それをパスワードで渡された暗号化チェックサムと比較します。これが一致すれば、パスワードが送信中に改ざんされていないことがほぼ確実となります。
ダイジェスト・パスワードの送信を選択した場合は、Nonceまたは作成時間をユーザー名トークンに含むかどうか選択する必要があります。require-nonce属性はNonceをユーザー名トークンに含める必要があるかどうかを指定します。Nonceは、リプレイ攻撃を防止するためユーザー名トークンに含まれるランダム値です。サーバーは、次に続くリクエストに含まれるNonceと比較するため、この値をキャッシュします。Nonceを使用することで、アプリケーションは起動時に毎回異なるパスワード・ダイジェストを生成できます。2つのNonceダイジェストは、たとえパスワードと作成時間の値が同じ場合であっても、異なるものになります。
require-created属性は、トークンの作成時間をユーザー名トークンに含める必要があるかどうかを指定します。これはリプレイ攻撃の防止にも使用できます。
|
関連項目:
|
例3-2にユーザー名トークンの構成例を示します。
パスワードを要求することなくユーザー名トークンを認証するよう、Webサービスを構成することができます。パスワードを要求しないことにより、他のベンダーとの相互運用性は拡張します。
パスワードのないトークンの認証をサービスで可能にするために、OracleAS Web Servicesでは<verify-username-token>要素の<property>下位要素としてブール型のusername.token.allow.nopasswordプロパティを提供します。
たとえば、次の構成をoracle-webservices.xmlファイルに入力して、パスワードを要求しないユーザー名トークンの認証をサービスで行えるようにします。
...
<inbound>
<verify-username-token>
<property name="username.token.allow.nopassword" value="true"/> </verify-username-token> </inbound>
...
クライアントがこの構成を持つサービスに対してパスワードなしでユーザー名トークンを送信すると受け入れられます。パスワードを宣言しないユーザー名トークンのクライアント構成例を次に示します。
.. <outbound> <username-token name="oc4jadmin" add-nonce="true" add-created="true"/> </outbound> ...
Nonceキャッシュはjavacache.xmlファイル（ORACLE_HOME/j2ee/home/config/javacache.xml）で静的に構成できます。OracleAS Web Servicesランタイムはこのファイルを使用して、実行時にJava Object Cacheを構成します。Nonceキャッシュは、このファイルの<max-size>および<max-objects>要素の値を編集することで構成できます。
<max-size>要素は、Java Object Cacheで使用可能なメモリーの最大サイズ（MB）を指定します。<max-objects>要素は、キャッシュで許容されるメモリー内オブジェクトの最大数を指定します。この数にはグループ・オブジェクトや、ディスクにスプールされて現在はメモリー内にないオブジェクトは含まれません。
|
関連項目:
|
例3-3に、javacache.xmlファイルのNonceキャッシュ構成の例を示します。Nonceキャッシュが、最大2000オブジェクトを保持し、512KBサイズまで拡大できるように構成されています。
サーバーのユーザー名トークンを構成するには、次のツールを使用できます。
インバウンド・ポリシー認証ページでユーザー名トークンを構成できます。詳細は、Application Server Controlのオンライン・ヘルプでこのページの状況依存ヘルプを参照してください。
認証は、セキュアなWebサービス・ウィザードの「認証」ページ、またはWebサービス・エディタで設定されます。詳細は、Oracle JDeveloperのオンライン・ヘルプでWebサービスの認証設定に関するトピックを参照してください。
クライアントでは、<generated_name>_Stub.xmlデプロイメント・ディスクリプタでユーザー名トークンを構成します。クライアントのユーザー名トークンの構成には次のステップがあります。
<username-token>要素は、ユーザー名トークンをセキュリティ・ヘッダー・ブロックに挿入することを指定します。nameおよびpassword属性に適切な値を指定すると、メッセージがサービスにアクセスできます。
add-nonce属性でNonceを、add-created属性でリクエスト作成時間をトークンに追加すると、セキュリティがさらに強化されます。ダイジェスト・パスワードを選択する場合、これらの属性が存在しtrueに設定される必要があります。これらの属性はプレーン・テキスト・パスワードではオプションです。
例3-4にサーバーのユーザー名トークンの構成例を示します。
コールバック・ハンドラはjavax.security.auth.callback.CallbackHandlerインスタンスで、これによってログイン・モジュールがユーザーと対話してログイン情報を取得できます。コールバック・ハンドラは、アプリケーションによるユーザーへのアクセス制御の認証および実施を可能にする、Java Authentication and Authorization Service（JAAS）パッケージで定義されます。
コールバック・ハンドラには3つのタイプがあり、それぞれjavax.security.auth.callbackパッケージ内のクラスで表されます。
NameCallback: ユーザー名を処理するためのコールバック・ハンドラ
PasswordCallback: パスワードを処理するためのコールバック・ハンドラ
TextInputCallback: ユーザー名またはパスワード・フィールド以外のログイン・フォームのテキスト・フィールドを処理するためのコールバック・ハンドラ
|
関連資料: コールバック・ハンドラの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
ユーザー名およびパスワードを動的にサービスに渡すため、クライアントはコールバック・ハンドラを使用できます。通常は、callbackパッケージ内にある1つ以上のクラスを実装する、独自のコールバック・ハンドラ・クラスを記述します。次に、<username-token>要素のcbhandler-name属性を使用してハンドラ・クラスの名前を指定します。
例3-5にユーザー定義のUsernameTokenCallbackHandlerコールバック・ハンドラ実装のフラグメントを示します。このコールバック・ハンドラは、javax.security.auth.callback.NamecallbackおよびPasswordcallbackを処理してユーザー名とパスワードを渡します。
例3-5 ユーザー名トークンのコールバック・ハンドラ
... package oracle.ws.wssecurity.usernametoken; ... import javax.security.auth.callback.Callback; import javax.security.auth.callback.CallbackHandler; import javax.security.auth.callback.PasswordCallback; import javax.security.auth.callback.NameCallback; import javax.security.auth.callback.TextOutputCallback; ... public class UsernameTokenCallbackHandler implements CallbackHandler { Callback c = null; public void handle(Callback[] callbacks) { try { if (callbacks == null) { return; } for (int i = 0; i < callbacks.length; i++) { c = callbacks[i]; if (c instanceof NameCallback) { NameCallback nc = (NameCallback)c; nc.setName("name"); } else if (callbacks[i] instanceof PasswordCallback) { PasswordCallback pc = (PasswordCallback)callbacks[i]; pc.setPassword("password".toCharArray()); } } } catch (Exception e) { e.printStackTrace(); } } }
例3-6は、前述の例で定義したコールバック・ハンドラoracle.ws.wssecurity.usernametoken.UsernameTokenCallbackHandlerを使用するように構成された<username-token>要素のcbhandler-name属性を示しています。
<username-token>属性のnameとpasswordを構成に含めない場合、クライアント・ランタイムはJAX-RPCでサポートされているStub.USERNAME_PROPERTYおよびStub.PASSWORD_PROPERTYプロパティを使用して、ユーザー名トークンを動的に構築できます。Stubプロパティの詳細は、「アウトバウンド・メッセージに対するユーザー名トークン要素」を参照してください。
例3-7に、Stub.USERNAME_PROPERTYとStub.PASSWORD_PROPERTYを使用して、ユーザー名oc4jadmin、パスワードwelcomeのWebサービスをコールするクライアント・コードを示します。
例3-7 Stubプロパティを使用したWebサービスへのアクセス
...
public void UserNameWithSystemProperties() throws Exception {
// Call the service with Stub property username/password
((Stub) stub)._setProperty(Stub.USERNAME_PROPERTY, "oc4jadmin");
((Stub) stub)._setProperty(Stub.PASSWORD_PROPERTY, "welcome");
String response = stub.helloUser(MESSAGE);
System.out.println("Response: ["+response+"]");
...
クライアントのユーザー名トークンを構成するには、次のツールを使用できます。
認証は、セキュアなWebサービス・ウィザードの「認証」ページ、またはWebサービス・エディタで設定されます。詳細は、Oracle JDeveloperのオンライン・ヘルプでWebサービスの認証設定に関するトピックを参照してください。
表3-1に、ユーザー名トークンで使用できるセキュリティ・プロバイダのサマリーを示します。ユーザー名トークンで使用可能なセキュリティ・プロバイダはすべて、Application Server Controlを使用して構成できます。
Webサービス・セキュリティを構成する前に、セキュリティ・プロバイダでOC4Jを構成します。表3-2に、ユーザー名トークンで使用できるセキュリティ・プロバイダの構成に関する追加情報の参照先を示します。
表3-2 ユーザー名トークンで使用できるセキュリティ・プロバイダ
| セキュリティ・プロバイダ・タイプ | 詳細参照先のリソース |
|---|---|
|
ファイルベースのセキュリティ・プロバイダ |
ユーザー名セキュリティ・トークンに対するファイルベースのプロバイダの構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
|
Oracle Identity Management |
ユーザー名セキュリティ・トークンに対するOracle Identity Management（Oracle Internet Directory（OID）を含む）の構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 シングル・サインオンはユーザー名トークンでは使用できません。 |
|
外部LDAPプロバイダ |
ユーザー名セキュリティ・トークンに対する外部LDAPプロバイダの構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
|
カスタム・セキュリティ・プロバイダ |
ユーザー名セキュリティ・トークンに対するカスタム・プロバイダの構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
|
Oracle Access Manager |
ユーザー名セキュリティ・トークンに対するセキュリティ・プロバイダとしてのOracle Access Managerの構成方法については、「ユーザー名トークン認証に対するセキュリティ・プロバイダとしてのOracle Access Managerの使用」を参照してください。 Oracle Access Managerの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
ユーザーのデプロイの一部にOracle Access Managerがある場合は、セキュリティ・プロバイダとして使用してサービスのアクセス・システムと統合できます。Oracle Access Managerセキュリティ・プロバイダは、Oracleで提供されるCoreIDLoginModuleログイン・モジュールを使用します。CoreIDLoginModuleはORACLE_HOME/j2ee/instance/config/system-jazn-data.xmlファイルで定義されます。
ログイン・モジュールはそれぞれのアプリケーション用に構成されます。
クライアントで、ユーザー名トークンは認証にユーザー名およびパスワードを使用します。したがって、WebサービスがOracle Access Managerログイン・モジュールを使用してユーザー名およびパスワードに対する検証を定義する必要があります。ユーザー名およびパスワード検証に対する認証方式を定義したら、coreid.name.attributeおよびcoreid.password.attributeプロパティを使用してこれらの変数の値をログイン・モジュールで定義する必要があります。
名前を認証するには、credential_mappingプラグインでユーザー名を検証するため定義された変数名にcoreid.name.attributeプロパティの値を設定します。このプロパティは<login-module>要素の下のオプションとして設定されます。
パスワードを認証するには、validate_passwordプラグインでパスワードを検証するため定義された変数名にcoreid.password.attributeプロパティの値を設定します。
|
関連資料:
|
例3-8に、ユーザー名トークンに対するユーザー名を認証するためのcoreid.name.attributeプロパティの設定を示します。username_variable値は、credential_mappingプラグインでユーザー名を認証するために使用される変数名です。
例3-8 ユーザー名ログイン・モジュールのOracle Access Managerに対するユーザー名変数の設定
...
<login-module>
...
<option>
<name>coreid.name.attribute</name>
<value>username_variable</value>
</option>
...
</login-module>
...
例3-9に、ユーザー名トークンに対するパスワードを認証するためのcoreid.password.attributeプロパティの設定を示します。username_password値は、validate_passwordプラグインでパスワードを認証するために使用される変数名です。
例3-9 ユーザー名ログイン・モジュールのOracle Access Managerに対するパスワード変数の設定
...
<login-module>
...
<option>
<name>coreid.password.attribute</name>
<value>username_password</value>
</option>
...
</login-module>
...
例3-10に、system-jazn-data.xmlファイルのユーザー名トークンに対するCoreIDLoginModule構成の例を示します。<name>要素の値、application_nameは、Webサービス・アプリケーションの名前を表します。
例3-10 ユーザー名トークン認証に対するCoreIDLoginModule
<application>
<name>application_name</name>
<login-modules>
<login-module>
<class>
oracle.security.jazn.login.module.coreid.CoreIDLoginModule
</class>
<control-flag>required</control-flag>
<options>
<option>
<name>addAllRoles</name>
<value>true</value>
</option>
<option>
<name>coreid.resource.type</name>
<value>res_type</value>
</option>
<option>
<name>coreid.resource.operation</name>
<value>res_operation</value>
</option>
<option>
<name>coreid.resource.name</name>
<value>/res_name</value>
</option>
<option>
<name>coreid.name.attribute</name>
<value>username_variable</value>
</option>
<option>
<name>coreid.password.attribute</name>
<value>username_password</value>
</option>
</options>
</login-module>
</login-modules>
</application>
認証にユーザー名トークンを使用する場合は、メッセージ・リプレイ攻撃を防止するためNonceを使用できます。メッセージ・リプレイ攻撃は、中間点のリスナー（介在者）が認証済および検証済のメッセージを捕捉したときに発生します。介在者は、クライアントとサーバーでメッセージを独自に識別する手段がないかぎり、捕捉したメッセージを繰り返しリプレイできます。
Nonceはメッセージに含まれる一意のランダムな数で、クライアントとサーバーでメッセージを独自に識別する際に役立ちます。たとえば、アプリケーションはパスワード・ダイジェストの作成時にNonceを次のように使用できます。
password_digest = SHA1 (nonce + created + password)
Nonceを使用することで、アプリケーションは起動時に毎回異なるパスワード・ダイジェストを生成できます。2つのNonceダイジェストは、たとえパスワードと作成時間の値が同じ場合であっても、異なるものになります。
Nonceは、パスワード・タイプがダイジェストでもプレーン・テキストでも、ユーザー名トークンに追加できます。Nonceを追加するには、add-nonce="true"およびadd-created="true"属性を<username-token>要素に含めます。
プレーン・テキスト・パスワード・タイプでは、add-nonceおよびadd-created属性はオプションです。
パスワード・タイプをDIGESTに指定すると、add-nonceおよびadd-created属性が必須となり、デフォルトでtrueに設定されます。次の例では、add-nonceおよびadd-created属性を指定する必要はありません。これらは暗黙的にtrueに設定されます。
<username-token name="jdoe" password="password" password-type="DIGEST"/>
この項では、サーバーおよびクライアントに対するX.509トークンの構成方法について説明します。また、トークンとOC4Jセキュリティ・プロバイダとの統合方法も説明します。
|
注意: OracleAS Web ServicesセキュリティはX.509（#X509V3）のシンプルな証明書処理のみを取り扱います。証明書パス（#X509PK1PathV1）や、証明書およびCRLのセット（#PKCS7）はサポートしていません。 |
サーバーでは、oracle-webservices.xmlデプロイメント・ディスクリプタでX.509トークンを構成します。サーバーのX.509トークンの構成には次のステップがあります。
サーバー側のX.509トークンを構成するには、<verify-x509-token>要素を使用します。<verify-x509-token>要素は<inbound>要素の下位要素です。例3-11にサーバーのX.509トークンの構成例を示します。
X.509トークンで必要な秘密鍵、公開鍵および証明書を格納するためのキーストアを作成します。Java Key Store（JKS）またはOracle Walletのどちらかを使用できます。このどちらかのキーストアの構成に関連する手順については、「キーストアの使用方法」を参照してください。
マッピング属性（mapping.attribute）はX.509証明書をXMLまたはLDAPリポジトリの有効ユーザーへマップします。LDAPリポジトリは、Oracle Internet Directory（OID）、またはActive DirectoryやiPlanetなどの外部リポジトリのいずれかになります。デフォルト・マッピング属性はDN、つまりX.509証明書の識別名を使用して、証明書をLDAPレルムのユーザーへマップします。
XMLプロバイダ（jazn-data.xml）についてはCN、つまり共通名がデフォルトで使用されます。レルムはセキュリティ・プロバイダ構成をベースとします。
ブートストラップのjazn.xmlファイル（ORACLE_HOME/j2ee/instance_name/config/jazn.xml）のmapping.attributeを設定することで、マッピングをカスタマイズできます。
例3-12に、mapping.attribute属性を使用した、emailアドレスに基づくX.509証明書に対するLDAPリポジトリ内のユーザーのマッピングを示します。この例では、デフォルトのDNが証明書のマップに使用され、そのDNが次のように定義されていると想定しています。
DN = "CN=jdoe, OU=security, O=Oracle, email=jdoe@oracle.com"
証明書はjdoe@oracle.comという電子メール・アドレスを持つユーザーにマップされます。
例3-12 ユーザーのX.509証明書へのマッピング
<jazn provider="LDAP" location=".... "> <property name="mapping.attribute" value="email"/> </jazn>
マッピング属性と一致するユーザーが複数見つかった場合は、リクエストが拒否されます。mapping.attribute属性の値は、Application Server Controlを使用して変更することはできません。
表3-3で、各セキュリティ・プロバイダ・タイプのマッピング属性のデフォルト値を説明します。
サーバーのX.509トークンを構成するには、次のツールを使用できます。
インバウンド・ポリシー認証ページでX.509トークンを構成できます。詳細は、Application Server Controlのオンライン・ヘルプでこのページの状況依存ヘルプを参照してください。
認証は、セキュアなWebサービス・ウィザードの「認証」ページ、またはWebサービス・エディタで設定されます。詳細は、Oracle JDeveloperのオンライン・ヘルプでWebサービスの認証設定に関するトピックを参照してください。
クライアントでは、<generated_name>_Stub.xmlデプロイメント・ディスクリプタでX.509トークンを構成します。クライアントのX.509トークンの構成には次のステップがあります。
サブジェクト鍵識別子によるX.509トークンの認証（オプション）
X.509トークンの署名（オプション）
X.509トークンに対するクライアントを構成するには、<x509-token>要素を使用します。例3-13に構成例を示します。
クライアント上のX.509トークンで必要な署名鍵を格納するためのキーストアを作成します。これを提供するには、Java Key Store（JKS）またはOracle Walletのどちらかを使用できます。署名鍵の取得と、このどちらかのキーストアの構成に関連する手順については、「キーストアの使用方法」を参照してください。
X.509トークンの認証では、認証に使用されるX.509証明書について受信者に事前知識がある場合、証明書全体のかわりにサブジェクト鍵識別子を送信できます。サブジェクト鍵識別子は、公開鍵の算出に使用される証明書の拡張領域です。証明書にサブジェクト鍵識別子がない場合、リクエストは拒否されます。
サブジェクト鍵識別子で認証するには、<generated_name>_Stub.xmlファイルに次の変更を行います。
<signature>要素の<property>下位要素を、サブジェクト鍵識別子プロパティのoracle.security.wss.signwithskiに設定します。
<property>下位要素のvalue属性をtrueに設定します。デフォルトではこのプロパティはfalseに設定されます。
例3-14に、X.509トークンを認証するためのサブジェクト鍵識別子プロパティoracle.security.wss.signwithskiの使用方法を示します。
例3-14 サブジェクト鍵識別子が指定されたX.509トークン
<x509-token/> <signature> <property name="oracle.security.wss.signwithski" value="true"/> </signature>
|
注意: 署名者の秘密鍵を示すにはセキュリティ構成で署名鍵を構成します。署名者の証明書にはSubjectKeyIdentifierExtensionが必要です。また、受信者のキーストアには、サブジェクト鍵識別子を解決するための署名者の証明書が存在する必要があります。 |
未署名のX.509トークンは保護されていないため、他のトークンに置き換えることが可能です。アウトバウンド・メッセージでX.509トークンに署名することで、このトークンを保護できます。これを実行するため、OracleAS Web Servicesセキュリティは<x509-token>でブール型のoracle.security.wss.signX509tokenプロパティを定義します。
このプロパティは、<x509-token>が署名<signature>で使用されている場合のみ適用されます。trueに設定されている場合（デフォルト）、X.509トークンは署名されます。falseに設定されている場合、X.509トークンは署名されません。
このプロパティの詳細は、「アウトバウンド・メッセージに対するX.509トークン要素」を参照してください。
例3-15に、<x509-token>および<signature>要素とともに使用されるoracle.security.wss.signX509tokenプロパティを示します。
クライアントのX.509トークンを構成するには、次のツールを使用できます。
認証は、セキュアなWebサービス・ウィザードの「認証」ページ、またはWebサービス・エディタで設定されます。詳細は、Oracle JDeveloperのオンライン・ヘルプでWebサービスの認証設定に関するトピックを参照してください。
このツールを使用して、セキュリティ構成をWebサービス・クライアント・プロキシにアセンブルできます。これを実行するには、<generated_name>_Stub.xmlデプロイメント・ディスクリプタにX.509トークンの構成を含めます。ddFileName引数を使用して、このファイルをWebServicesAssemblerのgenProxyコマンドの入力として指定します。ddFileName引数とWebサービス・クライアントのアセンブルの詳細は、『Oracle Application Server Web Services開発者ガイド』の「WebServicesAssemblerの使用方法」を参照してください。
表3-1に、X.509セキュリティ・トークンで使用できるセキュリティ・プロバイダのサマリーを示します。X.509トークンで使用可能なセキュリティ・プロバイダはすべて、Application Server Controlを使用して構成できます。
Webサービス・セキュリティを構成する前に、セキュリティ・プロバイダでOC4Jを構成します。表3-4に、X.509トークンで使用できるセキュリティ・プロバイダの構成に関する追加情報の参照先を示します。
表3-4 X.509トークンで使用できるセキュリティ・プロバイダ
| セキュリティ・プロバイダ・タイプ | 詳細参照先のリソース |
|---|---|
|
ファイルベースのセキュリティ・プロバイダ |
X.509セキュリティ・トークンに対するファイルベースのプロバイダの構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
|
Oracle Identity Management |
X.509セキュリティ・トークンに対するOracle Identity Management（Oracle Internet Directory（OID）とSingle Sign-onを含む）の構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
|
外部LDAPプロバイダ |
X.509セキュリティ・トークンに対する外部LDAPプロバイダの構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
|
Oracle Access Manager |
X.509セキュリティ・トークンに対するセキュリティ・プロバイダとしてのOracle Access Managerの構成方法については、「X.509トークン認証に対するセキュリティ・プロバイダとしてのOracle Access Managerの使用」を参照してください。 Oracle Access Managerの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
ユーザーのデプロイの一部にOracle Access Managerアクセス・システムがある場合は、セキュリティ・プロバイダとして使用してサービスのアクセス・システムと統合できます。Oracle Access Managerセキュリティ・プロバイダは、CoreIDLoginModuleログイン・モジュールを使用します。ログイン・モジュールはそれぞれのアプリケーション用に構成されます。CoreIDLoginModuleはORACLE_HOME/j2ee/instance_name/config/system-jazn-data.xmlファイルで定義されます。
X.509認証でOracle Access Managerを使用するには、認証プラグインにマッピング属性を使用するようにOracle Access Managerログイン・モジュールを構成します。credential_mappingプラグインでマッピング属性を検証するため定義されたCN変数の値にcoreid.name.attributeプロパティを設定します。このプロパティは<login-module>要素のオプションとして設定されます。
|
関連資料:
|
例3-16に、X.509トークンに対するマッピングを認証するためのCoreIDLoginModuleにおけるcoreid.name.attributeプロパティの設定を示します。cn_variable値は、マッピングを認証するために使用される変数名です。
例3-16 X.509認証のためのOracle Access Managerログイン・モジュールに対するCN変数の設定
...
<login-module>
...
<option>
<name>coreid.name.attribute</name>
<value>cn_variable</value>
</option>
...
</login-module>
...
例3-17に、system-jazn-data.xmlファイルのX.509トークン認証に対するCoreIDLoginModuleを示します。<name>要素の値、application_nameは、Webサービス・アプリケーションの名前を表します。
例3-17 X.509トークン認証に対するCoreIDLoginModule
<application>
<name>application_name</name>
<login-modules>
<login-module>
<class>
oracle.security.jazn.login.module.coreid.CoreIDLoginModule
</class>
<control-flag>required</control-flag>
<options>
<option>
<name>addAllRoles</name>
<value>true</value>
</option>
<option>
<name>coreid.resource.type</name>
<value>res_type</value>
</option>
<option>
<name>coreid.resource.operation</name>
<value>res_operation</value>
</option>
<option>
<name>coreid.resource.name</name>
<value>/res_name</value>
</option>
<option>
<name>coreid.name.attribute</name>
<value>cn_variable</value>
</option>
</options>
</login-module>
</login-modules>
</application>
この項では、サーバーおよびクライアントに対するSAMLトークンの構成方法について説明します。また、トークンとOC4Jセキュリティ・プロバイダとの統合方法も説明します。SAMLトークンの使用例の詳細は、「SAMLトークン・プロファイル」を参照してください。
サーバー上のSAMLトークンの構成では、使用する確認メソッドに応じて3つの使用ケースがあります。これらの確認メソッドはsender-vouches（未署名）、sender-vouches（署名済）およびholder-of-keyです。
sender-vouches（未署名）: 受信SAMLトークンはsender-vouches確認メソッドを提供し、トークンは署名されていない必要があります。
sender-vouches（署名済）: 受信SAMLトークンはsender-vouches確認メソッドを提供し、トークンへの参照が署名されている必要があります。
holder-of-key: 受信SAMLトークンはholder-of-key確認メソッドを提供する必要があります。アサーションにはユーザーの公開鍵が必要です。
次の項では、これらの各使用ケースにおけるSAMLトークンの構成手順について説明します。
sender-vouches（未署名）
SAMLアサーション・サブジェクトのマップ（オプション）
発行者名はデフォルトでwww.oracle.comに設定されます。この値は、ユーザーのアサーション発行者の名前に変更することをお薦めします。
sender-vouches（署名済）
発行者名はデフォルトでwww.oracle.comに設定されます。この値は、ユーザーのアサーション発行者の名前に変更することをお薦めします。
SAMLアサーション・サブジェクトのマップ（オプション）
holder-of-key
サーバー側のSAMLトークンを構成するには、<verify-saml-token>要素を使用します。<verify-saml-token>要素は<inbound>要素の下位要素です。
<verify-saml-token>要素にはオプションで<subject-confirmation-method>下位要素があります。インバウンドの<verify-saml-token>ポリシーの一部として使用されるとき、この下位要素は受信SOAPメッセージにおけるIDの伝播に使用される確認メソッドを参照します。
実際の確認メソッドは<confirmation-method>要素で指定されます。これは<subject-confirmation-method>要素の下位要素です。<confirmation-method>について使用できる値はSENDER-VOUCHES、SENDER-VOUCHES-UNSIGNEDおよびHOLDER-OF-KEYです。
例3-18に、SAMLトークンを検証するため<verify-saml-token>要素を使用する構成例を示します。この構成はユーザーの公開鍵を含むSAMLトークンを許容します。トークン自体は署名済、未署名、または鍵保有者になります。
SAMLトークンで必要な秘密鍵、公開鍵および証明書を格納するためのキーストアを作成します。holder-of-key確認メソッドでは、署名を検証するためのユーザーの信頼できる証明書がキーストアに含まれる必要があります。また、SAMLLoginModuleのアサーション発行者オプションをすべてApplication Server Controlで構成する必要があります。SAMLLoginModuleオプションの詳細は、「SAMLLoginModuleのオプションの設定」を参照してください。
sender-vouches（署名済）確認メソッドでは、公開鍵と信頼できる証明書がキーストアに含まれる必要があります。また、SAMLログイン・モジュールの発行者名オプションをApplication Server Controlで構成する必要があります。
sender-vouches（未署名）確認メソッドでは、キーストアが構成されている必要はありません。
Java Key Store（JKS）またはOracle Walletのどちらかをキーストアとして使用できます。このどちらかのキーストアの構成に関連する手順については、「キーストアの使用方法」を参照してください。
デフォルトではSAMLLoginModuleはOracleのアサーション発行者によって構成されます。名前識別子形式が省略されている、または指定されていない場合は、jazn.xml（ORACLE_HOME/j2ee/instance_name/config/jazn.xml）ファイルのmapping.attribute属性を構成する必要があります。この属性の値はApplication Server Controlを使用して変更できないため、ファイルを手動で編集します。
SAMLトークンに名前識別子形式がある場合は、表3-5に説明のあるマッピング属性の1つが使用されます。マッピング属性プロパティは必要ありません。サブジェクトの名前形式については、「SAMLアサーションのサブジェクト名および形式の構成」を参照してください。
表3-5 サブジェクトの名前識別子形式と対応するマッピング値
| サブジェクトの名前識別子形式 | OIDのマッピング属性 | Active Directoryのマッピング属性 | iplanetのマッピング属性 |
|---|---|---|---|
|
EMAIL_ADDRESS |
|
|
|
|
X509_SUBJECT_NAME |
DN |
DN |
DN |
|
WINDOWS_DOMAIN_NAME |
|
|
適用不可 |
|
UNSPECIFIED / OMITTED |
|
|
|
表3-6で、各セキュリティ・プロバイダ・タイプのmapping.attribute属性のデフォルト値を説明します。
表3-6 各セキュリティ・プロバイダ・タイプのmapping.attributeの値
| デフォルト・プロパティ値 | セキュリティ・プロバイダ・タイプ |
|---|---|
|
CN |
ファイルベースのセキュリティ・プロバイダ。 |
|
DN |
Oracle Identity Managementセキュリティ・プロバイダ、外部LDAPプロバイダおよびOracle Access Manager。 |
例3-19に、mapping.attributeプロパティを使用した、XMLリポジトリ内の有効ユーザーに対するSAMLアサーション・サブジェクトのマッピングを示します。
SAMLアサーションを成功させるため、ユーザーは信頼できるSAMLアサーション発行者をSAMLLoginModuleオプションの一部として構成する必要があります。SAMLLoginModuleは受信したSAMLトークンを認証するシステム・ログイン・モジュールです。
SAMLLoginModuleには、信頼できるSAML発行者名、信頼ポイント別名、キーストア・パス、キーストア・タイプ、および信頼できるSAML発行者のパスワードを設定するためのオプションがあります。デフォルトでSAMLログイン・モジュールはキーストアとともに構成されていません。
信頼できるSAML発行者名、キーストア、および信頼ポイント別名のオプションをApplication Server Controlの「信頼できるSAMLオーソリティ」画面で設定できます。
|
注意: holder-of-keyサブジェクト確認メソッドでは、発行者がSAMLアサーションに署名します。このメソッドを構成する場合は、発行者名、信頼ポイント別名、およびすべてのキーストア・オプションを設定する必要があります。 |
表3-7でSAMLLogingModuleオプションを説明します。これらのオプションは各アサーション発行者について構成する必要があります。オプション名の変数Nはアサーション発行者の数を表します。
表3-7 SAMLLoginModuleオプション
| SAMLLoginModuleオプション | 説明 | このオプションが必須となる確認メソッド |
|---|---|---|
|
有効値: 1...N キーストア・パスワードを指定します。 |
Holder-of-Key |
|
|
有効値: 1...N アサーション発行者の証明書が格納されるキーストア・パスを指定します。 |
Holder-of-Key |
|
|
有効値: 1...N アサーション発行者のキーストア・タイプを指定します。デフォルトのキーストア・タイプは |
Holder-of-Key |
|
|
有効値: 1...N 発行者名を指定します。OC4Jのスタンドアロン |
Holder-of-Key、Sender Vouches |
|
|
有効値: 1...N アサーション発行者の信頼ポイントの鍵別名を指定します。この設定は、Holder-Of-Keyのサブジェクト確認ケースにおけるアサーション発行者の証明書の検証に使用されます。 |
Holder-of-Key |
Webサービス・クライアントでは、SAMLトークンはsender-vouches（未署名）、sender-vouches（署名済）またはholder-of-key確認メソッドについて構成できます。構成は、<generated_name>_Stub.xmlファイルの<saml-token>要素値をハード・コーディングすることで静的にするか、動的に設定できます。
sender-vouches（未署名）
この構成は静的または動的のどちらかになります。静的構成は、<generated_name>_Stub.xmlファイルにおけるSAML要素の値の提供にかかわります。動的構成では、Stubプロパティ、コールバック・ハンドラ、ID伝播またはSAMLPを使用できます。これらの各構成の詳細は、次の項を参照してください。
sender-vouches（署名済）
この構成は静的または動的のどちらかになります。静的構成は、<generated_name>_Stub.xmlファイルにおけるSAML要素の値の提供にかかわります。動的構成では、Stubプロパティ、コールバック・ハンドラ、ID伝播またはSAMLPを使用できます。これらの各構成の詳細は、次の項を参照してください。
署名鍵および証明書によるキーストアの構成
holder-of-key
holder-of-keyに対するクライアント側のSAMLトークン構成は静的にできません。これは、コールバック・ハンドラまたはSAMLPのどちらかを使用して動的に実行する必要があります。
鍵および証明書によるキーストアの構成
SAMLアサーション・サブジェクト名
アサーション・サブジェクト名の形式
アサーション発行者の名前
認証文と属性文
これらの値は静的または動的のどちらかで指定できます。静的構成ではSAML要素の値を指定します。動的構成ではSAMLトークン・コールバック・ハンドラを書き込みます。
この項では、静的なSAML構成に対する必須の値の提供方法について説明します。セキュリティのクライアント構成は<generated_name>_Stub.xmlファイルに表示されます。
アサーション・サブジェクトの名前を、<saml-token>要素のname属性の値を指定することで選択できます。この名前の先頭にはオプションでアサーションのレルム名を付加できます。レルム名がすでに存在する場合、これはname修飾子として設定されます。name属性の書式は次のとおりです。
name = [realm-name/]name
アサーション・サブジェクト名の形式はname-format属性の設定で指定されます。この属性の使用可能な値については、表2-14「<saml-token>要素の属性」を参照してください。
アサーション発行者名はissuer-name属性の設定で構成できます。この属性の値が指定されていない場合は、デフォルトのアサーション発行者のwww.oracle.comが使用されます。この値は、ユーザーのアサーション発行者の名前に変更することをお薦めします。この要素の詳細は、表2-14「<saml-token>要素の属性」を参照してください。
認証文はデフォルトで生成されます。属性文を生成する場合は、サブジェクトの属性を含むattributes.propertiesファイルを追加します。
attributes.propertiesファイルの場所を示すには、attributes要素のpath属性を使用します。
<attributes path=<location-of-attributes.properties file >>
attributes要素の先頭にはオプションでネームスペース値を付加できます。
[attribute-name-space/]name=value
次に例を示します。
jazn.com/name=john doe
この項では、OracleAS Web Servicesセキュリティでサポートされる確認メソッドのタイプを説明します。
デフォルトの確認メソッドはsender-vouches（暗黙的署名）です。
sender-vouches（署名済）確認メソッドを構成するには、<saml-token>および<signature>要素を構成します。例3-20にsender-vouches（署名済）アサーション・トークンを生成するための構成を示します。<saml-token>要素の後に<signature>要素が続きます。<signature-method>要素は署名アルゴリズムを指定します。アルゴリズムが指定されていない場合は、デフォルトのRSA-SHA1が使用されます。
<signature-method>要素の詳細は表2-17「<signature>要素の下位要素」を参照してください。表2-18「署名アルゴリズムと短縮名」には要素に使用できる値の説明があります。
例3-21にsender-vouches（未署名）アサーション・トークンを生成するための構成を示します。<confirmation-method>要素は未署名のアサーションに使用される確認タイプを指定します。<confirmation-method>要素に使用できる値の詳細は表2-15「<saml-token>要素の下位要素」を参照してください。
例3-22にコールバック・ハンドラを使用したholder-of-keyアサーションを送信するための構成を示します。cbhandler-name属性は、SAMLTokenCallbackコールバック・ハンドラを取り扱うユーザー定義クラスを指定します。この例ではmypackage.SAMLTokenCallbackHandlerがユーザー定義クラスです。
cbhandler-name属性の詳細は、表2-15を参照してください。「SAMLトークン・コールバック・ハンドラの書込み」でSAMLトークンに対するコールバック・ハンドラの作成について説明します。
<saml-token>要素を構成に含めない場合、クライアント・ランタイムはJAX-RPCでサポートされているStub.USERNAME_PROPERTYを使用してトークンを動的に構築できます。このプロパティの使用の詳細は、表2-15「<saml-token>要素の下位要素」を参照してください。
次の例では、Stubはjavax.xml.rpc.Stubで、_portはWebServicesAssemblerで生成されるstubです。
((Stub) _port)._setProperty(Stub.USERNAME_PROPERTY, name);
|
注意: 静的構成ファイルでname値を指定し、ユーザー名をUSERNAME_PROPERTYで動的に設定する場合、USERNAME_PROPERTY値は静的構成の値を上書きします。 |
ID伝播では、アプリケーションがWebサービスにIDを伝播できます。ID情報はアサーション・サブジェクトに存在します。oracle.security.wss.propagate.identityプロパティをtrueに設定することで、アサーション・サブジェクトを現在の実行スレッドから取得できます。このプロパティはポート・レベルのみで設定できます。次に例を示します。
<property name="oracle.security.wss.propagate.identity" value ="true"/>
プロパティがtrueに設定されていてIDがすでに存在する場合は、IDはWebサービスに伝播されます。IDが現在の実行スレッドに関連付けられていない場合は、リクエストは拒否されます。このプロパティがfalse（デフォルト）に設定されている場合は、IDは伝播されません。
SAMLトークン・コールバック・ハンドラを書き込んで、アサーションをクライアント・インターセプタに伝達できます。コールバック・ハンドラ実装がSAMLTokenCallbackオブジェクトを処理できるようにする必要があります。SAMLTokenCallbackオブジェクトは双方向です。つまり、アサーションがリクエストされた対象のサブジェクトの名前は、コールバックgetName()メソッドを使用して取得できます。
例3-23にSAMLトークン・コールバック・ハンドラ実装の例を示します。getName()メソッドはサブジェクトの名前を取得します。getAssertion(subject)メソッドはsubjectの値に基づいてアサーションを取得します。これらの行は太字で表示されています。
例3-23 SAMLトークン・コールバック・ハンドラの実装例
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import oracle.webservices.security.callback.SAMLTokenCallback;
public class SAMLTokenCallbackHandlerHK implements CallbackHandler {
Callback c = null;
public void handle(Callback[] callbacks) {
try {
if (callbacks == null) {
return;
}
for (int i = 0; i < callbacks.length; i++) {
c = callbacks[i];
if (c instanceof SAMLTokenCallback) {
SAMLTokenCallback sc = (SAMLTokenCallback) c;
String subject = sc.getName();
Document doc = getAssertion(subject);
sc.setXMLToken(
doc.getDocumentElement());
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
public Document getAssertion(String subject) {
//User implementation for getting the
assertion subject
}
}
この項では、外部SAML認証局からSAMLトークンを取得するためのクライアント構成方法について説明します。OracleAS Web ServicesクライアントはSAMLPリクエストを発行してトークンを取得できます。トークンを取得するには、<saml-token>要素のオプションの下位要素である<saml-authority>要素を構成する必要があります。この要素の詳細は、表2-16「<saml-authority>要素の属性」を参照してください。
例3-24に、外部SAML認証局からSAMLトークンを受け入れるクライアント構成を示します。ユーザー名jdoeおよびパスワードpasswordがSAML認証局へ認証を提供します。<require-signature="true">は、SAMLPリクエストがクライアントの署名鍵で署名されることを示しています。これは、クライアント側のキーストアが適切な署名鍵で構成されることも暗に示しています。
SAMLトークンで必要な秘密鍵、公開鍵および証明書を格納するため、キーストアを作成（または既存のキーストアを使用）します。holder-of-keyまたはsender-vouches（署名済）確認メソッドでは、秘密鍵がキーストアに含まれる必要があります。sender-vouches（未署名）確認メソッドでは、キーストアが構成されている必要はありません。
Java Key Store（JKS）またはOracle Walletのどちらかをキーストアとして使用できます。
静的および動的な手法を組み合せてSAML構成をクライアントに提供できます。たとえば、SAMLサブジェクト名を静的に宣言してから、それをコールバック・ハンドラに渡すことができます。
|
関連項目:
|
表3-1に、SAMLセキュリティ・トークンで使用できるセキュリティ・プロバイダのサマリーを示します。
Webサービス・セキュリティを構成する前に、セキュリティ・プロバイダでOC4Jを構成します。表3-8に、SAMLトークンで使用できるセキュリティ・プロバイダの構成に関する追加情報の参照先を示します。
表3-8 SAMLトークンで使用できるセキュリティ・プロバイダ
| セキュリティ・プロバイダ・タイプ | 詳細参照先のリソース |
|---|---|
|
ファイルベースのセキュリティ・プロバイダ |
SAMLセキュリティ・トークンに対するファイルベースのプロバイダの構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
|
Oracle Identity Management |
SAMLセキュリティ・トークンに対するOracle Identity Management（Oracle Internet Directory（OID）とSingle Sign-onを含む）の構成方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 このトークンに対するシングル・サインオンの構成方法の詳細は、「SAMLを使用したシングル・サインオンの構成」を参照してください。 |
|
外部LDAPプロバイダ |
SAMLトークンは外部LDAPプロバイダで使用できますが、手動で構成する必要があります。これらの手動ステップについて次の項で説明します。 |
|
Oracle Access Manager |
トークンに対するセキュリティ・プロバイダとしてのOracle Access Managerの構成方法については、「SAMLトークン認証に対するセキュリティ・プロバイダとしてのOracle Access Managerの使用」を参照してください。 Oracle Access Managerの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
ユーザーのデプロイの一部にOracle Access Managerがある場合は、セキュリティ・プロバイダとして使用してサービスのアクセス・システムと統合できます。Oracle Access Managerセキュリティ・プロバイダは、Oracleで提供されるCoreIDLoginModuleログイン・モジュールを使用します。CoreIDLoginModuleはORACLE_HOME/j2ee/instance_name/config/system-jazn-data.xmlファイルで定義されます。
Oracle Access Managerログイン・モジュールがSAMLログイン・モジュールの前に表示されるようにsystem-jazn-data.xmlファイルを編集します。
SAMLLoginModule
CoreIDLoginModule
モジュールを逆の順序で入力すると、その構成は無効になります。<control-flag>要素は、SAMLLoginModuleおよびCoreIDLoginModuleの両方でrequiredに設定する必要があります。ログイン・モジュールはそれぞれのアプリケーション用に構成されます。
SAML認証でOracle Access Managerを使用するには、認証プラグインにマッピング属性を使用するようにOracle Access Managerログイン・モジュールを構成します。credential_mappingプラグインでマッピング属性を検証するため定義されたSAMLサブジェクトの値にcoreid.name.attributeプロパティを設定します。このプロパティは<login-module>要素のオプションとして設定されます。
|
関連資料: このプロパティと |
例3-25に、SAMLサブジェクトを認証するためのcoreid.name.attributeプロパティの設定を示します。subject_variable値は、credential_mappingプラグインでSAMLサブジェクトを認証するために使用される変数名です。
例3-25 SAML認証のためのOracle Access Managerログイン・モジュールに対するSAMLサブジェクト変数の設定
...
<login-module>
...
<option>
<name>coreid.name.attribute</name>
<value>subject_variable</value>
</option>
...
</login-module>
...
例3-26に、system-jazn-data.xmlファイルのSAMLLoginModuleとCoreIDLoginModuleを示します。SAMLLoginModuleがCoreIDLoginModuleの前に示されていることに注意してください。<name>要素の値、application_nameは、Webサービス・アプリケーションの名前を表します。
例3-26 SAMLサブジェクト認証のためのOracle Access ManagerおよびSAMLログイン・モジュールの使用
<application>
<name>application_name</name>
<login-modules>
<login-module>
<class>
oracle.security.jazn.login.module.saml.SAMLLoginModule
</class>
<control-flag>required</control-flag>
<options>
<option>
<name>addAllRoles</name>
<value>true</value>
</option>
<option>
<name>issuer.name.1</name>
<value>www.oracle.com</value>
</option>
</options>
</login-module>
<login-module>
<class>
oracle.security.jazn.login.module.coreid.CoreIDLoginModule
</class>
<control-flag>required</control-flag>
<options>
<option>
<name>addAllRoles</name>
<value>true</value>
</option>
<option>
<name>coreid.resource.type</name>
<value>res_type</value>
</option>
<option>
<name>coreid.resource.operation</name>
<value>res_operation</value>
</option>
<option>
<name>coreid.resource.name</name>
<value>/res_name</value>
</option>
<option>
<name>coreid.name.attribute</name>
<value>subject_variable</value>
</option>
</options>
</login-module>
</login-modules>
</application>
受信SAMLトークンをActive DirectoryやiPlanetなどの外部LDAPプロバイダに対して認証するには、SAMLLoginModuleおよびLDAPLoginModuleをORACLE_HOME/j2ee/instance_name/config/system-jazn-data.xmlファイルで構成する必要があります。モジュールは次の順序でファイルに入力する必要があります。
SAMLLoginModule
LDAPLoginModule
モジュールを逆の順序で入力すると、その構成は無効になります。<control-flag>要素は、SAMLLoginModuleおよびLDAPLoginModuleの両方でrequiredに設定する必要があります。ログイン・モジュールはそれぞれのアプリケーション用に構成されます。
|
関連資料:
|
例3-27に構成例を示します。SAMLLoginModule、LDAPLoginModuleおよび<control-flag>の項目が太字で表示されています。
例3-27 外部LDAPプロバイダに対してSAMLトークンを認証するための構成例
<application>
<name>MyApplication</name>
<login-modules>
<login-module>
<class>oracle.security.jazn.login.module.saml.SAMLLoginModule</class>
<control-flag>required</control-flag>
<options>
……
</options>
</login-module>
<login-module>
<class>oracle.security.jazn.login.module.LDAPLoginModule </class>
<control-flag>required</control-flag>
<options>
…..
</options>
</login-module>
</login-modules>
</application>
この項では、2つの異なるコンテナにデプロイされたWebアプリケーションとWebサービス間におけるOracle Single Sign-Onの確立方法について説明します。WebアプリケーションとWebサービスが両方ともSAMLを使用するように構成されていることが前提です。
この使用例では、Oracle Single Sign-Onと関連付けられているOC4JコンテナにWebアプリケーションがデプロイされていると想定しています。リクエストがWebアプリケーションに届くと、これはOracle Single Sign-Onで認証されるOracle Identity Managementにリダイレクトされます。
Webアプリケーションは、認証メカニズムとしてSAMLを使用するWebサービスを起動します。Oracle Single Sign-OnのIDがWebアプリケーションからSAMLアサーションとしてWebサービスに伝播されます。Webサービス・アプリケーションはSAMLアサーションを受け取ると、アサーションを検証してユーザーを認証します。
図3-1にクライアント、WebアプリケーションおよびWebサービス間における制御の実行時フローを示します。
図示されたWebコンポーネント間の実行時フローの手順を次に示します。
クライアントがWebアプリケーションにログインします。Webアプリケーションは認証にOracle Single Sign-Onを使用します。
WebアプリケーションがWebサービス・スタブをコールします。
Webサービス・スタブがWebサービスを起動します。スタブはOracle Single Sign-OnのIDとともにSAMLアサーションをWebサービスに渡します。
Webサービス・アプリケーションはアサーションを検証し、Oracle Internet Directoryを使用してOracle Single Sign-OnのIDをマップします。
WebアプリケーションとWebサービス間におけるOracle Single Sign-Onの構成手順を次に示します。
ステップ1: Oracle Identity Management 10.1.2のインストールとOC4Jとの関連付け
10.1.2 Identity Managementをインストールします。
Application Server Controlを使用して、Oracle Identity Management10.1.2をOC4Jと関連付けます。
|
関連資料: Oracle Identity Managementの構成方法は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
ステップ2: Single Sign-Onを使用するためのWebアプリケーションの構成
Application Server Controlを使用して、Oracle Single Sign-Onを使用するようにWebアプリケーションを構成します。Application Server Controlを使用したOracle Single Sign-Onの構成の詳細は、Application Server Controlのオンライン・ヘルプを参照してください。
|
関連資料: Single Sign-Onの構成方法は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
ステップ3a: Webサービス・クライアントのアセンブルと保護
Oracle JDeveloperを使用してWebサービス・クライアントを生成します。「セキュリティ」オプションで、SAML sender-vouches確認メソッドを選択します。
ポート・レベルのoracle.security.wss.propagate.identityプロパティをtrueに設定します。
<property name="oracle.security.wss.propagate.identity" value ="true"/>
このプロパティがtrueに設定されている場合、Webアプリケーション認証済IDがSAMLサブジェクトとして伝播されます。
Webサービスのプロキシ/クライアント・キーストアをWebアプリケーションでパッケージ化し、それをOC4JコンテナのWebアプリケーションにデプロイします（図3-1の「10.1.3.1 OC4Jコンテナ1」）。
ステップ3b: WebアプリケーションとWebサービス・クライアントの統合
WebアプリケーションでWebサービス・スタブのインスタンスを取得します。
Stub.ENDPOINT_ADDRESS_PROPERTYを実際のWebサービス・エンドポイント・アドレスに設定します。
ステップ4: Webサービス（サーバー側）のアセンブルと保護
Oracle JDeveloperを使用してWebサービスをアセンブルします。
Webサービス・アプリケーションをデプロイします。キーストアと署名鍵をバンドルして、それをアプリケーションとともにデプロイします。
Application Server Controlを使用して、SAML sender-vouches確認メソッドを使用するようにWebサービスを構成します。
Application Server Controlを使用して、Oracle Identity Managementを使用するように、Webサービスを含むOC4Jコンテナ（図3-1の「10.1.3.1 OC4Jコンテナ2」）を構成します。
メッセージ・レベル暗号をグローバル・レベルまたはポート・レベルのどちらかのWebサービスについて構成できます。<encryption-key>要素はメッセージの復号化に必要な鍵を示します。この要素がグローバル・レベルで構成される場合は、グローバル・レベル・キーストアの暗号鍵を示します。この要素がポート・レベルで構成される場合は、ポート・レベル・キーストアの暗号鍵を示します。要素がポート・レベルで構成されていない場合は、グローバル・レベルの値が使用されます。
<encryption-key>要素は別名とパスワードを保持できます。Oracle JDeveloperとコマンドライン・キーストア・ツール（Oracle WalletおよびJava Key Store）では、鍵の作成時に別名およびパスワードを割り当てるオプションを使用できます。
次の項でSOAPメッセージの暗号化および復号化について説明します。
<outbound>要素の<encrypt>下位要素は送信者の秘匿性要件を指定します。<encrypt>要素には、暗号化メソッドおよびアルゴリズムを指定するための下位要素が含まれます。ユーザーは<encryption-method>要素によって、メッセージの暗号化に使用される暗号化アルゴリズムを指定できます。<keytransport-method>要素は、対象となる受信者への暗号鍵の暗号化に使用できるアルゴリズムを指定できます。<use-request-cert>を使用すると、クライアントが元のリクエスト・メッセージで送信した署名証明書で、Webサービス・アプリケーションがレスポンス・メッセージを暗号化できます。
<recipient-key>要素は受信者の公開鍵に対する別名とパスワードを提供します。この鍵はキーストアに存在する必要があります。受信者の公開鍵はデータ暗号鍵の暗号化に使用されます。
暗号化されるSOAPメッセージの要素を指定するには、<tbe-elements>を使用できます。この要素では、メッセージ要素全体、または要素のコンテンツのみを暗号化できます。
|
関連項目:
|
インバウンド・メッセージでは、<inbound>要素の<decrypt>下位要素が、受信したメッセージの復号化方法を指定します。ユーザーは<encryption-method>要素によって、受信メッセージについて受入れ可能な暗号化アルゴリズムを指定できます。<keytransport-method>要素は暗号鍵について受入れ可能な暗号化アルゴリズムを指定します。
受信メッセージについて、<tbe-elements>要素はどの要素を暗号化するかを示します。インバウンド・メッセージに対する<tbe-elements>要素の使用方法については、「SOAPメッセージの要素の復号化」を参照してください。復号化に使用される受信者の秘密鍵は、キーストアに存在する必要があります。
復号鍵の別名は<keystore>要素の<encryption-key>要素で構成する必要があります。
SOAPメッセージ・ボディはApplication Sever ControlまたはOracle JDeveloperで暗号化できます。メッセージ・ボディに対するエントリは、local-part属性の値としてBody、mode属性の値としてCONTENTを持つ<tbe-element>要素で作成されます。これらの要素および属性の詳細は、表2-19「<encrypt>要素の下位要素」を参照してください。
|
注意: SOAPBody要素を暗号化する場合は、mode属性をCONTENTに設定する必要があります。 |
例3-28に、SOAPメッセージ・ボディを暗号化する<tbe-element>要素の下のエントリ例を示します。
SOAPメッセージ・ボディはApplication Sever ControlまたはOracle JDeveloperで復号化できます。メッセージ・ボディに対するエントリは、local-part属性の値としてBody、mode属性の値としてCONTENTを持つ<tbe-element>要素で作成されます。これらの要素および属性の詳細は、表2-8「<decrypt>要素の下位要素」を参照してください。
|
注意: SOAPBody要素を復号化する場合は、mode属性をCONTENTに設定する必要があります。 |
例3-29に、SOAPメッセージ・ボディを復号化する<tbe-elements>要素の下のエントリ例を示します。
name-spaceおよびlocal-part属性を持つ<tbe-element>要素を追加することで、SOAPメッセージのどの部分を暗号化することもできます。指定された名前のSOAPメッセージ内に要素が1つしか存在しない場合は、ネームスペースを省略できます。
デフォルトでは、要素のコンテンツのみが暗号化されます。要素全体を暗号化するには、mode属性をELEMENTに設定します。
例3-30にユーザー名トークンの暗号化のコードを示します。
特定の要素を復号化するには、name-spaceおよびlocal-part属性を持つ<tbe-element>を指定します。デフォルトでは、要素のコンテンツのみが復号化されます。要素全体を復号化するには、mode属性をELEMENTに設定します。
受信リクエストで要素が暗号化されていない場合、リクエストは拒否されます。
例3-31にUsernameToken要素を復号化するコードを示します。
Webサービス・アプリケーションが同じクライアントに対してレスポンスを送り返すとき、クライアントが最初のメッセージ交換で送信した署名証明書を使用して、そのレスポンスを暗号化することを選択できます。これは、最初のメッセージ交換の際に、Webサービス・クライアントが署名済SOAPメッセージを送信し、Webサービス・アプリケーションが署名を正常に検証したことを前提としているので、注意してください。
アプリケーションが、クライアントの署名証明書でレスポンスを暗号化できるようにするには、Webサービス・アプリケーションのアウトバウンド暗号化ポリシーの一部として<use-request-cert>要素を構成します。サーバー・インターセプタが署名証明書を見つけられない（つまり、クライアントが署名済SOAPメッセージを送信していないか、署名検証が失敗している）場合、Webサービス・アプリケーションは暗号化リクエストを拒否するので注意してください。
OracleAS Web Servicesで定義されているサービスのデフォルトの動作では、メッセージの復号化に対して1つの暗号鍵のみを受け入れます。<decrypt>要素で設定されるブール型プロパティのoracle.security.wss.decryptusingskiを使用すると、多くの鍵の中のいずれかで暗号化されている可能性があるメッセージを、Webサービスが復号化できます。
decryptusingskiプロパティがtrueに設定されている場合、受信メッセージ内の<encryption-key>要素のサブジェクト鍵識別子は、キーストアの秘密鍵に対して解決されます。このプロパティがfalseに設定されている場合、Webサービスはメッセージを復号化する1つの暗号鍵のみを受け入れます。デフォルトではこのプロパティはfalseに設定されます。
キーストア内の秘密鍵、および鍵にアクセスするためのユーザー・アカウントの設定方法の手順を次に示します。
セキュリティ構成の<keystore>要素で構成されるキーストアに、復号化に使用される秘密鍵を追加します。
Application Server Controlを使用して、ORACLE_HOME/j2ee/instance_name/config/system-jazn-data.xmlでユーザー・アカウントを作成します。ユーザー名は次のようなタイプにします。
application-name.portname.key.<decryption-key-alias>
たとえば、ポートSecurePortおよび別名deckeyを持つSecureServiceアプリケーションに対する復号鍵を作成するには、ユーザー名は次のようになります。
SecureService.SecurePort.key.deckey
パスワードは復号鍵パスワードになります。
例3-32にoracle.security.wss.decryptusingskiプロパティの使用例を示します。
メッセージ・レベル署名をグローバル・レベルまたはポート・レベルのどちらかのWebサービスについて構成できます。<signature-key>要素はメッセージの署名に必要な鍵を示します。この要素がグローバル・レベルで構成される場合は、グローバル・レベル・キーストアの署名鍵を示します。この要素がポート・レベルで構成される場合は、ポート・レベル・キーストアの署名鍵を示します。要素がポート・レベルで構成されていない場合は、グローバル・レベルの値が使用されます。署名を検証するには、信頼できるルート証明書がキーストア内に存在する必要があります。自己署名済証明書を使用する場合は、<signature-key>要素で別名を指定できます。
<signature-key>要素は別名とパスワードを保持できます。Oracle JDeveloperとコマンドライン・キーストア・ツール（Oracle WalletおよびJava Key Store）では、鍵の作成時に別名およびパスワードを割り当てるオプションを使用できます。
次の項でSOAPメッセージ上の署名に関する署名と検証について説明します。
<utbound>要素の<signature>下位要素は、アウトバウンド・メッセージの署名に使用できるオプションを指定します。ユーザーは<signature-method>要素によって、メッセージの署名に使用されるアルゴリズムを指定できます。
署名されるSOAPメッセージの要素を指定するには、<tbs-elements>を使用できます。この要素では、メッセージ要素全体、または要素のコンテンツのみを署名できます。
<add-timestamp>要素では、署名にタイムスタンプを追加することでセキュリティ・レベルを上げることができます。このタイムスタンプは受信メッセージに対する<verify-timestamp>要素で検証されます。
|
関連項目:
|
インバウンド・メッセージでは、<inbound>要素の<verify-signature>下位要素が、受信したメッセージ上の署名が検証される方法を指定します。ユーザーは<signature-method>要素によって、受信メッセージについて受入れ可能な署名アルゴリズムを指定できます。
<verify-timestamp>要素は、署名上の有効期限と、作成時間が含まれるかどうかを定義します。このタイムスタンプ要素は、送信メッセージの署名に対して定義された<add-timestamp>要素で構成されます。
受信メッセージについて、<tbs-elements>要素はメッセージのどの要素を署名するかを示します。
追加プロパティのclock-skewも、受信メッセージに対して定義できます。これは時間誤差の値です。このプロパティでは、許容できるクライアントとサーバー間の時間誤差を指定できます。
|
関連項目:
|
Application Sever ControlまたはOracle JDeveloperを使用して、デジタル署名をSOAPメッセージ・ボディに適用できます。詳細は、Oracle JDeveloperのオンライン・ヘルプでWebサービスに対するWS-Securityの実装に関するトピックを、また、Application Server Controlのオンライン・ヘルプでWebサービスのセキュリティ構成に関するトピックを参照してください。
要素を特定するためのname-spaceおよびlocal-part属性を持つ<tbs-element>要素を追加することで、SOAPメッセージのどの部分に署名することもできます。指定された名前のSOAPメッセージ内に要素が1つしか存在しない場合は、name-space属性を省略できます。
例3-33にSOAPメッセージのUsernameToken要素を署名するためのコードを示します。
例3-33 SOAPメッセージ要素の署名
<signature> <tbs-elements> <tbs-element name-space=http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-wss-wssecurity-sec-ext-1.0.xsd local-part="UsernameToken"/> </tbs-elements> </signature>
SOAP Body要素は、Oracle JDeveloperまたはApplication Sever Controlで署名および暗号化できます。その他のすべての要素については、oracle-webservices.xmlおよび<generated_name>_Stub.xmlファイルを手動で編集する必要があります。
特定の要素上の署名を検証するには、name-spaceおよびlocal-part属性を持つ<tbs-element>要素を指定します。受信リクエストで要素が署名されていない場合、リクエストは拒否されます。
例3-34に署名されたユーザー名トークンを検証するためのコードを示します。
署名済メッセージの受信者に、署名者の公開鍵証明書について事前知識がある場合、メッセージで証明書全体を送信するかわりに証明書のサブジェクト鍵識別子を送信できます。サブジェクト鍵識別子は、公開鍵の算出に使用される証明書の拡張領域です。証明書にサブジェクト鍵識別子がない場合、リクエストは拒否されます。
サブジェクト鍵識別子で署名するには、署名内のproperty要素をoracle.security.wss.signwithskiに、value属性をtrueに設定します。デフォルトではこのプロパティはfalseに設定されます。
例3-35に、<property>下位要素におけるサブジェクト鍵識別子oracle.security.wss.signwithskiプロパティの設定方法を示します。
例3-35 サブジェクト鍵識別子によるメッセージ・ボディの署名
<signature>
<tbs-elements>
<tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body"/>
</tbs-elements>
<property name="oracle.security.wss.signwithski" value="true"/>
</signature>
|
注意: 署名者の秘密鍵を示すにはセキュリティ構成で署名鍵を構成します。署名者の証明書にはSubjectKeyIdentifierExtensionが必要です。また、受信者のキーストアには、サブジェクト鍵識別子を解決するための署名者の証明書が存在する必要があります。 |
アプリケーションはリプレイ攻撃を防止するためタイムスタンプを使用できます。タイムスタンプは、有効期限（この期限後はメッセージが無効になる）の特定によるメッセージの保護に使用されます。Webサービスの受信によって検証が実行されます。
クライアントとサーバー間のあらゆる時間誤差をカバーするため、<verify-signature>要素のclock-skewプロパティを構成できます。このプロパティの詳細は、表2-7「<verify-signature>要素の下位要素」を参照してください。
<signature>要素の<add-timestamp>下位要素では、送信SOAPメッセージにタイムスタンプを追加できます。メッセージ・セキュリティを強化するため、expiry属性では署名の有効期限を設定できます。またcreated属性は署名の作成時間を挿入します。
例3-36にアウトバウンド・メッセージへのタイムスタンプの追加に対する構成を示します。この構成では、アウトバウンド・メッセージでタイムスタンプに作成時間が含まれ、メッセージが送信された後3000秒（50分）間、署名が有効です。
<verify-signature>要素の<verify-timestamp>下位要素では、インバウンドSOAPメッセージに存在するタイムスタンプを検証できます。<verify-timestamp>下位要素にはexpiryおよびcreatedの2つの属性があります。expiryの時間はメッセージの最新性の有効期限を設定します。メッセージが有効期限より後に到着した場合、メッセージは拒否されます。created属性がtrueに設定されている場合、作成時間が含まれているかどうかSOAPメッセージのタイムスタンプがチェックされます。作成時間が含まれていない場合、メッセージは拒否されます。
例3-37にタイムスタンプ検証の構成を示します。この構成では、インバウンド・メッセージでタイムスタンプに作成時間が含まれることが指定され、メッセージが送信された後28800秒（8時間）以内に到着した場合に署名が受け取られます。
OracleAS Web Servicesセキュリティには、別々のマシンで稼働する際のクライアントとWebサービス・アプリケーション間のあらゆる時間誤差を同期できる機能があります。これは、タイムスタンプが付加されたSOAPメッセージを受け渡す際に有効な機能です。
たとえば、あるマシン上で稼働するクライアントがSOAPメッセージに署名し、タイムスタンプを追加し、それをWebサービス・アプリケーションに送信します。別のマシンで稼働するアプリケーションはそのメッセージを受信し、署名とタイムスタンプを検証します。この2つのマシンの時計が同時刻ではない場合、タイムスタンプに不一致が生じてメッセージが拒否されます。
Web Servicesセキュリティには、2つのマシンの時間誤差を調整する、<verify-signature>要素のclock-skewプロパティが用意されています。clock-skewのデフォルト値は0で、単位はミリ秒です。
例3-38に、クライアントとWebサービス・アプリケーション間の時間誤差を3秒に設定する例を示します。
サーバーおよびクライアントの構成で、セキュリティ・トークン、暗号および署名をどのような組合せでも使用できます。クライアントおよびサーバーに対する構成は互換可能である必要があります。例として、この項では、暗号および署名とともに認証にSAMLトークンを使用するように、クライアント側およびサーバー側のデプロイメント・ディスクリプタを構成する方法について説明します。
例3-39にクライアント側デプロイメント・ディスクリプタの<generated_name>.Stub.xmlに対する構成を示します。この構成は認証にSAMLトークンを使用し、メッセージ・ボディおよびSAMLアサーションは整合性保護のため署名されます。メッセージ・ボディはメッセージ秘匿性を保護するため暗号化されます。これはOracle JDeveloperを使用して構成できます。
デフォルトでは、SAMLサブジェクト確認メソッドはsender-vouches（署名済）です。SAMLアサーションは、sender-vouches確認メソッドでユーザーID jdoeに対して生成されます。アサーションは、別名がsignkeyの署名鍵を使用して署名されます。
メッセージ・ボディはsignkeyを使用して署名され、有効期限が3000秒に設定されたタイムスタンプがメッセージ最新性のために追加されます。デフォルトの署名アルゴリズムRSA-SHA1が署名に使用されます。メッセージ・ボディも、enckeyという別名の受信者の鍵によって暗号化されます。デフォルトの暗号化アルゴリズムはAES-128で、デフォルトの鍵トランスポート・アルゴリズムはRSA-1_5です。署名と受信者の鍵はmykeystore.jksに格納されます。
例3-39 SAMLトークン、暗号および署名について構成されるクライアント側デプロイメント・ディスクリプタ
<oracle-webservice-clients>
<webservice-client>
<port-info>
<runtime enabled="security">
<security>
<key-store path="./mykeystore.jks" store-pass="password"/>
<signature-key alias="signkey" key-pass="password"/>
<outbound>
<saml-token name="jdoe"/>
<signature>
<tbs-elements>
<tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body"/>
</tbs-elements>
<add-timestamp created="true" expiry="3000"/>
</signature>
<encrypt>
<recipient-key alias="enckey"/>
<tbe-elements>
<tbe-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body"/>
</tbe-elements>
</encrypt>
</outbound>
</security>
</runtime>
<operations>
<operation name="sayHello">
</operation>
</operations>
</port-info>
</webservice-client>
</oracle-webservice-clients>
サーバーはメッセージを復号化し、メッセージ・ボディおよびアサーションの署名を検証してから、SAMLトークンを使用してユーザーを認証します。
例3-40に、サーバー側デプロイメント・ディスクリプタのoracle-webservices.xmlに対する補足構成を示します。この構成はOracle JDeveloperを使用して作成することもできます。
メッセージ・ボディはdeckeyという別名の秘密鍵を使用して復号化されます。署名（ボディおよびアサーションの両方の署名）は、SOAPメッセージにアタッチされた公開鍵を使用して検証されます。信頼できるCA証明書は、キーストアmykeystore.jksを使用して検証されます。ユーザーが認証され、サブジェクトがユーザーjdoeに対して作成されます。送信者の公開鍵証明書および信頼できる証明書は、復号化のための受信者の公開鍵証明書とともにmykeystore.jksに格納されます。
|
注意: <verify-saml-token>要素内のサブジェクト確認メソッドは省略できます。この確認メソッドが存在する場合、これは<saml-token>要素内のサブジェクト確認メソッドまたはデフォルト値のどちらかに一致する必要があります。 |
例3-40 SAMLトークン、暗号および署名について構成されるサーバー側デプロイメント・ディスクリプタ
<oracle-webservices>
<webservice-description name="SecureService">
<port-component name="SecurePort">
<runtime enabled="security">
<security>
<key-store path="./mykeystore.jks" store-pass="password"/>
<signature-key alias="signkey" key-pass="password"/>
<encryption-key alias="deckey" key-pass="password"/>
</security>
</runtime>
<operations>
<operation name="sayHello">
<runtime>
<security>
<inbound>
<verify-saml-token>
<subject-confirmation-methods>
<confirmation-method>SENDER-VOUCHES</confirmation-method>
</subject-confirmation-methods>
</verify-saml-token>
<verify-signature>
<tbs-elements>
<tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body"/>
</tbs-elements>
</verify-signature>
<decrypt>
<tbe-elements>
<tbe-element name-space="http://schemas.xmlsoap.org/soap/envelope/" local-part="Body"/>
</tbe-elements>
</decrypt>
</inbound>
</security>
</runtime>
</operation>
</operations>
</port-component>
</webservice-description>
</oracle-webservices>
