| Oracle Application Server Web Servicesセキュリティ・ガイド 10gリリース3（10.1.3） B31870-01 |
|
 戻る |
 次へ |
この章では、基本的なWebサービス・セキュリティの概念、標準、および仕様の概要を説明します。この章は次の項で構成されています。
従来、ほとんどのWebサービスは、Webの基盤テクノロジと同じ有効化テクノロジ、すなわちHTTPをベースとしてきました。この結果、Basic認証やSSLなどの、Webアプリケーションを保護する一般的なテクノロジは、Webサービスでも同様に機能します。これらのセキュリティ・テクノロジはあらゆる種類のオンライン・ビジネス・トランザクションにおいて何年間も有効な実績を上げており、これらはWebサービスについても同様に機能します。
ただし、SSLには制約があります。WebサービスにおけるSSLは全か無かという結果になります。たとえば、プロトコル経由で送信されるSOAPメッセージだけではなく、全体的なワイヤ・プロトコルを保護します。このため、開発者はドキュメントの個別箇所に個別レベルのセキュリティを適用することはできません。SSLはそのポイントツーポイント構造のため、ユーザー資格証明がトランザクション・チェーンの各ポイントで渡されるような、サービスまたはワークフロー・アプリケーションのチェーンをサポートしません。このため、それぞれの中間チェックポイントではメッセージが保護されません。SSLでは、監査証跡の概念もサポートされません。
メッセージ・レベルおよびトランスポート・レベル双方のセキュリティを実現可能にするのは、2004年4月に業界全体の推奨仕様としてリリースされたOASIS標準のWS-Securityです。WS-Securityは、トランスポートの独立性と個別セキュリティ・レベルをSOAPメッセージに追加するためのメカニズムを定義します。
WS-Securityは複数の認証方法を提供します。WS-Securityでは、個別のIDをサービス・リクエストに簡単に関連付けできます。これらのIDを使用して、認証後に認可を実行できます。
WS-Securityは中間点におけるSOAPトラフィックのサポートを提供します。
WS-Securityはトランスポートに依存しないため、よりフレキシブルにトランスポートを利用できます。
WS-Securityはターゲット型のセキュリティです。たとえば、メッセージ・ボディ全体、あるいはボディ・ペイロードの単一のXML要素のみを、署名または暗号化できます。
整合性と秘匿性を、SOAPメッセージ全体ではなく詳細なレベルに適用する必要がある場合、XMLの署名と暗号化を使用して、SOAPボディ、ヘッダー・ブロック、またはそのどちらかを保護できます。SOAPメッセージをトランスポート・セッションより上位レベルで保護する必要がある場合は、メッセージ・レベルのセキュリティを使用できます。個別の認証形式を使用することが必要な場合は、ユーザー名トークン、X.509トークンまたはSAMLトークンなどの、メッセージ・レベル・セキュリティの認証トークンを使用できます。
セキュリティの基盤となる概念は認証、メッセージ整合性、およびメッセージ秘匿性です。
メッセージ整合性: 「メッセージが転送中に消失、破損または変化したのは、事故によるものか、意図的なものか。」アプリケーションはメッセージを検証する必要があります。
メッセージ秘匿性: 「他人がこのメッセージを読むことは可能か。」アプリケーションはエンドポイント間でデータを暗号化し、参照が必要なアプリケーションのみにデータを公開する必要があります。
このマニュアルでは、多数のWebサービスおよびセキュリティ関連の用語と概念が使用されます。これらについて次の項で説明します。
SOAPプロトコルは、Webサービスのリクエストおよびレスポンス・メッセージに対するXMLベース標準で、このメッセージは通常、HTTPまたはHTTPS（SSL付きのHTTP）プロトコルを経由して転送されます。WS-Securityは、SOAPメッセージのコンテキストに沿うように設計された、SOAPの記述に対するXMLベースの拡張仕様です。これを参照するには、最初にSOAPメッセージの構造を理解する必要があります。
SOAPにおけるXMLスキーマの定義では、<Envelope>要素がSOAPメッセージのルート要素になります。SOAPメッセージにはヘッダー、ボディ、またはフォルト要素が含まれる場合があります。例1-1にSOAPの<Envelope>要素のコンテンツを示します。
例1-1 SOAPの<Envelope>要素のコンテンツ
<env:Envelope>
<env:Header>
</env:Header>
<env:Body>
.
.
.
</env:Body>
<env:Envelope>
|
注意: この例はSOAPリクエストのエンベロープを示しています。SOAPフォルト要素を含む可能性があるレスポンス・エンベロープもあります。 |
Webサービス開発者は主にSOAPボディのコンテンツに関心を寄せますが、ほとんどのセキュリティ関連要素はSOAPヘッダーの中にあります。ボディそのものは暗号化が可能であり、この場合、ボディには暗号文が含まれます。
Webサービスのセキュリティ・ポリシーによって、SOAPメッセージに適用されるセキュリティ・メカニズムが決まります。セキュリティ・ポリシーはサーバー側のWebサービスとWebサービス・クライアントに適用できます。Oracle Application Server Web Servicesのセキュリティは、次のようなタイプおよびレベルのセキュリティ・ポリシーを認識します。
インバウンド・ポリシーは、インバウンドSOAPメッセージに適用されるセキュリティ・メカニズムを決定します。decrypt値とverify-username-token値はインバウンド・ポリシーの2つの例です。decrypt値は、インバウンドSOAPメッセージの復号化に使用されるポリシーを表します。verify-username-token値もポリシーを表します。これは、受信したSOAPリクエストに、検証および認証が必要なユーザー名トークンがあることを示します。
インバウンド・ポリシーを構成するには、Application Server ControlまたはOracle JDeveloperを使用するか、手動で構成を作成します。セキュリティ構成は<inbound>要素の下位要素として表されます。<inbound>要素とその構成は、Webサービス・アプリケーションではoracle-webservcies.xmlファイル、Webサービス・クライアントでは<generated_name>_Stub.xmlファイルで参照できます。
アウトバウンド・ポリシーは、アウトバウンドSOAPメッセージに適用されるセキュリティ・メカニズムを決定します。<encrypt>値と<username-token>値はアウトバウンド・ポリシーの2つの例です。<encrypt>値は、アウトバウンドSOAPメッセージの暗号化に使用されるポリシーを表します。<username-token>値もポリシーを表します。これは、送信するSOAPメッセージにユーザー名トークンを含む必要があることを示します。
アウトバウンド・ポリシーを構成するには、Application Server ControlまたはOracle JDeveloperを使用するか、手動で構成を作成します。セキュリティ構成は<outbound>要素の下位要素として表されます。<outbound>要素とその構成は、Webサービス・アプリケーションではoracle-webservcies.xmlファイル、Webサービス・クライアントでは<generated_name>_Stub.xmlファイルで使用できます。
グローバル・レベル・セキュリティ・ポリシーは、OC4JインスタンスでデプロイされるWebサービスのすべてに適用されるセキュリティ・ポリシーです。グローバル・レベル・ポリシーはサーバー側でのみ構成できます。
グローバル・レベルでは次の項目を構成できます。
キーストア、署名および暗号の鍵
Nonce構成
インバウンド・ポリシー
アウトバウンド・ポリシー
Webサービスのコンテキストでは、ポートはアプリケーションと類似しています。ポート・レベル・セキュリティ・ポリシーは、Webサービスで定義されるすべての操作に適用されるセキュリティ・ポリシーです。ポート・レベル・ポリシーはサーバー側およびクライアント側で構成できます。
ポート・レベルでは次の項目を構成できます。
キーストア、署名および暗号の鍵
Nonce構成
インバウンド・ポリシー
アウトバウンド・ポリシー
リクエスト・エンベロープには、リモート・コールの処理に必要な情報が含まれます。各リクエスト・メッセージにはメッセージ・ヘッダーとメッセージ・ボディがあります。ヘッダーにはメッセージ・ルーティング、要件情報、およびセキュリティ情報などのプロセス情報が格納されます。メッセージのボディにはコール処理に必要な情報が格納されます。この情報はペイロードとも呼ばれます。
ペイロードには次の項目が含まれます。
コールされたサービスの名前
サービスの場所
サービスに渡されるパラメータ名およびデータ
SOAPレスポンス・エンベロープの書式タイプはリクエストと同一です。唯一の違いは、INパラメータがOUTパラメータに置き換えられることです。アプリケーションの出力はSOAPボディに含まれます。
|
注意: リクエスト・エンベロープおよびレスポンス・エンベロープの構造は、RPCエンコードまたはドキュメントリテラル、あるいはその両方のメッセージ書式をサービスがサポートするかどうかによって異なります。サポートされているメッセージ書式の詳細は、『Oracle Application Server Web Services開発者ガイド』の「Oracle Application Server Web Servicesメッセージ」を参照してください。 |
XML署名の仕様には、ルールと構文を処理するデジタル署名が記述されています。XML署名は、署名を含むXML内またはその他のどこに存在しても、整合性、メッセージ認証、またはあらゆるデータ・タイプに対する署名者の認証サービス（あるいはそのすべて）を提供します。
XML署名には、署名されたドキュメントの基本ハッシュが、署名されたデータおよび使用されたアルゴリズムをドキュメントの受信者に伝えるための情報とともに含まれています。XML署名は、署名が適用される対象のドキュメント内部に含まれるか、別のドキュメントに存在できます。XML署名はドキュメント・サブセットやXML以外のデータにも適用できます。
XML署名は次のような様々な署名タイプをサポートします。
enveloped: 署名されたドキュメントにXML署名が埋め込まれます。
enveloping: 署名されたデータがXML署名に埋め込まれます。
detached: 署名は、署名要素の外部にあるデータに対応します。
XML署名とWebサービス
Webサービスにおいて、XMLデジタル署名は有効性と、Webサービスのクライアントとサービス間で送信されたSOAPメッセージの同一性を保証します。XML署名は、署名者という唯一の人物が署名を作成できる手書きの署名と、概念的には同じです。署名の検証は2つのステップで行われます。
署名対象の全SOAPメッセージ要素のメッセージ・ダイジェストを算出してから、そのダイジェストをメッセージ署名の<SignedInfo>要素に配置します。
<SignedInfo>要素のメッセージ・ダイジェストを算出してから、このダイジェストに署名者の秘密鍵で署名します。署名に使用された鍵を<KeyInfo>要素に配置します。
署名されたSOAPメッセージは転送され、Webサービスのエンドポイントで署名者の公開鍵によって検証されます。次のステップは検証の手順を示しています。
<SignedInfo>要素の値を、<SignatureMethod>要素で指定されたダイジェスト・アルゴリズムを使用して再計算します。公開鍵を使用して、<SignatureValue>要素の値が<SignedInfo>要素のダイジェストに対して正しいことを検証します。
<SignedInfo>要素内に含まれた参照のダイジェストを再計算して、それを、各<Reference>要素に対応する<DigestValue>要素で表されたダイジェスト値と比較します。
例1-2は署名されたデータのXML表示を示します。SOAPメッセージのボディはRSA-SHA1アルゴリズムで署名されます。
例1-2 署名されたデータのXML表示
<dsig:Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#*rsa-sha1*"/>
<dsig:Reference URI="*#body*">
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>p5vhdagV0tjJafczbLB/I4aonlg=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>QKEJpRGwwRApPFWfA1R/6K4JFwCxyH2Ur0mdzTnzmpf
8DNvDVB9xdF9PVsQ68vEey8afbrL/Qwujghoq3gF22VlEBPj
TDrRTZ9JgnRVbOt/M/SacHP/BZn9gSfLySpJaQIj7x
MUbm5s29JiUvjQ0oR0/Skn+8f+KeQD0QEmbWX8=
</dsig:SignatureValue>
<dsig:KeyInfo>
<wsse:SecurityTokenReference xmlns="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/
01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
wsu:Id="_str"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/
01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Reference xmlns="http://docs.oasis-open.org/wss/2004/
01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/
01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
URI="#_bst"/>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
XML暗号の仕様には、データを暗号化し、その結果をXMLで表すためのプロセスが記述されています。データの選択は任意で、XMLドキュメント、XML要素、またはXML要素のコンテンツも可能です。データ暗号化の結果、暗号データを含む（子要素の1つのコンテンツを使用して）、または識別する（URI参照を使用して）、XML暗号化要素になります。標準ではドキュメントの選択箇所を暗号化できますが、ドキュメント全体は有効なXMLのままです。
XML暗号は次のような様々な暗号タイプをサポートします。
対称鍵の暗号化
公開鍵の暗号化
XML暗号とWebサービス
Webサービスにおいて、XML暗号は安全なデータ交換を必要とするアプリケーションに対するセキュリティを提供します。SSLはデータ交換保護の標準方式と考えられていますが、制約があります。たとえば、ドキュメントが最終的なエンドポイントに到達する前にいくつかのWebサービスを経由すると仮定します。XML暗号を使用することで、ドキュメントは停止中または転送中に暗号化できます。また、ドキュメント全体ではなくドキュメントの一部のみを暗号化することもできます。
例1-3はXMLで表示されたクレジット・カード・データを示します。
例1-3 クレジット・カード・データのXML表示
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
例1-4は、クレジット・カード番号、使用限度額、発行元銀行、および有効期限が暗号化され、暗号値で表された同じXMLスニペットを示します。
例1-4 暗号化されたクレジット・カード・データのXML表示
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</PaymentInfo>
Security Assertion Markup Language（SAML）は、セキュリティ情報を交換するためのXMLベースのフレームワークです。セキュリティ情報は、あるセキュリティ・ドメインにIDを持つサブジェクト（ユーザーまたはコンピュータ）についてのアサーションの形式で表されます。サブジェクトの1つの例として、電子メール・アドレスの特定のインターネットDNSドメインで識別されるユーザーがあります。アサーションは、サブジェクトで実行される認証結果の情報、サブジェクト属性だけでなく、特定リソースにサブジェクトがアクセスできるかどうかの認証決定も伝達します。
SAMLはビジネスとWebサービスにおいて認証、認可および属性などのユーザーに関するセキュリティ情報を交換するための、フレキシブルで拡張可能なフレームワークを提供します。たとえばSAMLでは、あるサービスが別のサービスにユーザーの認証を保証することができます。これによって、複数のサービスに対するシングル・サインオンなどの有用なアクティビティが利用できます。
SAMLでは、ユーザーが指定リソースにアクセス可能かどうかを、あるサービスが別のサービスに通知できます。これによって、ポリシーの実行をリソース・サービスから分離できます。
SAMLではワークサイト・アドレスなどのユーザーに関する属性情報を、ユーザーがあるサイトから別のサイトに移動する際にサービス間で交換できます。
OracleのWeb Servicesセキュリティ・モデルは、メッセージ・レベル・セキュリティを使用することでエンドツーエンドのセキュリティをサポートします。これは、接続以外にも、SOAPメッセージ自体が複数の中間点を介して転送される場合でも安全であることを意味しています。SOAPメッセージはデジタルで署名されて暗号化されています。署名と暗号化を行う要素を指定することで、細かいレベルに署名と暗号化を適用できます。クライアントとアプリケーションは、ユーザー名トークン、X.509トークンまたはSAMLトークンのような様々な認証トークンを渡すことで、お互いに認証できます。
SSL/TLSのような従来のテクノロジは、トランスポート・チャネルの保護に使用できます。SSLでは2つのアプリケーションが、ネットワーク経由で安全に接続し、お互いを認証することができます。また、アプリケーション間で交換されるデータを暗号化することもできます。OracleのWeb Servicesセキュリティ・モデルでは、このトランスポート・セキュリティ・メカニズムを使用して、ポイントツーポイント・セキュリティ、データ整合性およびデータ秘匿性を提供します。
Web Services Security（WS-Security）仕様は、メッセージの保護および秘匿性を向上させるSOAP 1.1の拡張機能を記述します。この拡張機能には、XMLデジタル署名によるメッセージの保護、XML暗号による秘匿性の保護、セキュリティ・トークンによる資格証明伝播の保護を行うための機能があります。この拡張の目標は、Webサービスにおける通信の保護をさらに全体的に拡大することです。
WS-Securityではこの保護を、トークンをメッセージと関連付けるメカニズムを定義して提供します。これは、複数のトークン書式をサポートしているという点で完全に拡張可能です。
仕様には、次のセキュリティ・トークンおよび鍵を指定する方法も記述されています。
X.509とKerberosチケットを使用したバイナリ・セキュリティ・トークン
ユーザー名トークンなどのテキストベースのトークン
署名および暗号の鍵
メッセージで指定する資格証明のタイプに制約はありません。
Oracle Web Services Securityでは、XML署名および暗号や、ユーザー名、X.509およびSAMLのトークン・プロファイルによる資格証明伝播などの、WS-Securityに対するサポートを提供します。
|
関連資料: WS-Securityの詳細および仕様は、次のWebサイトを参照してください。
|
OracleAS Web Servicesセキュリティは、次のセキュリティ・トークンの使用をサポートします。
ユーザー名トークンはBasic認証情報を伝達します。username-token要素は、メッセージを認証するためにユーザー名とパスワードの情報を伝播します。トークンで伝達された情報と信頼関係によって、ユーザーのIDを確立するためのベースが提供されます。
|
関連資料: ユーザー名トークン・プロファイルの詳細は、次のWebサイトを参照してください。
|
ユーザーの資格証明が付属したX.509証明書を、SOAPメッセージで渡すことができます。これは暗号化および復号化する場合のみSOAPメッセージの署名に使用できます。署名では、X.509トークンは署名の検証にのみ使用できます。
|
関連資料: X.509トークン・プロファイルの詳細は、次のWebサイトを参照してください。
|
SAMLセキュリティ・トークンは、認証文や属性文などのユーザーに関する1つ以上の文を含むアサーションで構成されています。SAMLトークンは、アサーション要素をヘッダー内に配置することで、SOAPメッセージにアタッチされます。
|
関連資料: SAMLトークン・プロファイルの詳細は、次のWebサイトを参照してください。
|
キーストアは、すべての信頼対象パーティの証明書など、プログラムで使用するための証明書を格納するために使用されます。キーストアによって、OC4J（例）などのエンティティは他のパーティを認証し、そのエンティティ自身を他のパーティに認証することもできます。Oracle HTTP Serverには、同じ目的を果すものとしてWalletがあります。
OracleAS Web Servicesセキュリティの実装では、Java Key Store（JKS）、Oracle WalletおよびPKCS#12などのキーストア・タイプをサポートします。Oracle WalletまたはJKSをキーストアとして使用し、秘密鍵、公開鍵、および信頼できるCA証明書を格納できます。
Oracle Walletには秘密鍵、ユーザー証明書、および一連の信頼ポイント（つまり、ユーザーが信頼するルート証明書のリスト）が含まれています。これは、各種の暗号化サービスで使用する記憶域と資格証明の取得を実装します。Oracle Walletファイルは実際にはPKCS#12ファイルであり、このファイルは解析、作成され、それ以外の場合はorapkiツール、Oracle Wallet ManagerおよびOpen SSLで操作されます。
この項の内容は次のとおりです。
OracleAS Web Servicesセキュリティは、次の仕様と標準で定義されます。
Web Services Security（WS-Security）はオープンなセキュリティ標準を定義します。
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
SAMLトークンはSAMLユーザーまたはサブジェクトがすでに認証済であると保証します。
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
X.509トークンは信頼関係に基づいてユーザーを認証するために使用できます。
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf
ユーザー名トークンはユーザー名とパスワードの情報を伝播します。
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
Web Service Interoperability（WS-I）は、Webサービス間における相互運用性のあるメッセージ交換のための汎用プロトコルを作成、宣伝、サポートするWebサービス組織です。
次のWeb Services Interoperability（WS-I） Organizationのドキュメントでは、今日のWebサービス環境におけるセキュリティの課題と脅威について論じられています。
http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf.
OracleAS Web Servicesでは、デジタル署名、暗号化および認証などのすべてのWS-Security機能が、インターセプタという構築済のJAX-RPCハンドラを使用して実装されます。Webサービス・クライアントがメッセージの送信をリクエストすると常に、SOAPメッセージがJAX-RPCハンドラでインターセプトされます。インターセプタは認証、署名および暗号などのWS-Security要素をSOAPメッセージに追加してから、そのメッセージを受信側のWebサービスに転送します。
受信側のWebサービスにもそれぞれインターセプタがあり、受信したメッセージを復号化し、署名を検証して認証します。
図1-1にこのフレームワークの動作を示します。図中の番号は次のステップにそれぞれ対応します。
Webサービス・クライアントがWebサービスにメッセージを送信します。クライアント・インターセプタは認証、署名および暗号などのWS-Security要素をアウトバウンドSOAPメッセージに追加してから、変更したメッセージを受信側のWebサービスに転送します。
レスポンス・メッセージを送信する際、Webサービスのサービス・インターセプタは整合性および秘匿性を保証するWS-Securityヘッダーを追加します。
クライアント・インターセプタはヘッダーを解析してから、それをクライアント・アプリケーションに伝達します。
サービス・セキュリティ・インターセプタは、受信したSOAPメッセージのフィルタとして機能します。デプロイメント・ディスクリプタのセキュリティ設定には、インターセプタを駆動する構成が記述されています。サービス・インターセプタは、受信したリクエスト・メッセージの復号化、検証、および認証を（この順序で）行います。レスポンス・メッセージを送信する際、サービス・インターセプタはWS-Securityヘッダーを埋め込んで、アウトバウンド・レスポンス・メッセージの整合性および秘匿性を保証します。サービス・インターセプタの主な目的は、SOAP操作における実行のセキュリティ・コンテキストの確立です。
クライアント・ハンドラは、Webサービスのクライアント側でサービス・ハンドラと同等の役割を果します。クライアント・インターセプタは、SOAPメッセージに対して認証トークンを追加、署名および暗号化するときに、一連の処理手順に従います。
図1-2にクライアント・ハンドラからサービス・ハンドラへのデータの移動を示します。クライアント・ハンドラは最初に認証情報を収集し、それをWS-Securityトークンとして挿入します。次に、署名の生成とメッセージの暗号化を行います。Stubデプロイメント・ディスクリプタに存在する構成によって、整合性/秘匿性の面で保護するメッセージの箇所が判断されます。
Oracle WS-Securityランタイムがクライアントおよびサーバーの両方に組み込まれている場合、セキュリティ・インターセプタはこの両側で使用可能であり、これらのインターセプタは構成ファイルで指定されたセキュリティ・ポリシーをロードします。他のクライアント・タイプ（.NETクライアントなど）のほとんどが、SOAPエンベロープ内のWS-Securityヘッダーを理解し、生成できます。受信側のインターセプタはセキュリティ・ポリシーを実行します。送信側のインターセプタはメッセージをインターセプトして、ターゲットの受信者のセキュリティ要件に基づいてそれを修正します。たとえば、ターゲットの受信者がメッセージへの署名を求める場合、送信者はメッセージに署名します。
Oracle WS-Securityコンポーネントは、J2EEセキュリティ・モデルを基盤とするOracleAS Web Servicesセキュリティ・インフラストラクチャと完全に統合されています。たとえば、リクエスト・メッセージにユーザー名とパスワードが含まれる場合、セキュリティ・ハンドラは基盤となるOracleAS JAAS Providerインフラストラクチャを利用して認証します。認証が成功すると、ユーザーID（JAASサブジェクト）が実行コンテキストで確立され、さらなるリソース・アクセスがこのIDに基づいてコンテナで認証されます。セキュリティ・インターセプタは、操作を認証できるIDの確立に役立つことに注意してください。サーバー側ハンドラはサブジェクトの形成にOracleAS JAAS Providerを利用し、JAAS認証のコミット・フェーズの際に正しいプリンシパル・インスタンス（ユーザーまたはロール、あるいはその両方）を各サブジェクトと関連付けます。これ以降は、サブジェクトに含まれた認定済または認証済のプリンシパル・インスタンスが、J2EEおよびJAAS認証のベースとして使用されます。
OracleAS Web Servicesのアーキテクチャは、開発者の労力を最小限にする宣言的モデルを使用して、安全な通信をサポートするように構築されています。インターセプタ・フレームワークは、メッセージ・ボディの暗号化などの共通セキュリティ・タスクを自動化します。
図1-3にOracleのWebサービスにおけるWS-Securityアーキテクチャの全体的アーキテクチャを示します。
Oracle WS-Securityアーキテクチャの主なコンポーネントはクライアントおよびサービスのセキュリティ・インターセプタです。これらのインターセプタはOracleAS Web Services管理フレームワークに接続し、監査、ロギングおよび信頼性を実装するインターセプタなどの他のインターセプタと連係して動作します。
次の項では、Webサービスのセキュリティ・インターセプタとOracleAS Web Servicesセキュリティ・フレームワークの統合について説明します。
OracleAS Web Servicesでは、J2EEの宣言型セキュリティと完全に統合されるJ2EEアプリケーション用のOracle Application Server Java Authentication and Authorization Service（JAAS）プロバイダの実装が提供されます。これによってJ2EEアプリケーションでは、プリンシパルベース・セキュリティやプラッガブルなログイン・モジュールなどのJAAS構成を利用できます。OracleAS Web Servicesのセキュリティでは独自のJAAS認証ログイン・モジュールが提供され、これによってOracleAS Web Servicesで稼働中のJ2EEアプリケーションがOracle Identity Managementの中心的セキュリティ・サービスを強化します。
JAAS ProviderではJavaアプリケーションへの安全なアクセスおよび実行と、Javaベース・アプリケーションとOracle Application Server Single Sign-Onとの統合が保証されます。
OC4J 10.1.3.1実装は、その他のシングル・サインオン・オプションのように追加で要求されたインフラストラクチャに依存しない軽量Java Single Sign-On（Java SSO）ソリューションを含んでいます。このJava SSOは、OracleAS JAAS ProviderのID管理フレームワークに基づいており、次のデプロイ・シナリオのいずれのWebアプリケーション間でも使用できます。
Webアプリケーションは、同じアプリケーションEARファイルでデプロイされます。
Webアプリケーションは、異なるアプリケーションEARファイルで同じOC4Jインスタンスにデプロイされます。
Webアプリケーションは、アプリケーションEARファイルで、異なるOC4Jインスタンスにデプロイされます。この場合Webアプリケーションは共通セキュリティ・ドメインとCookieドメインを共有します。
Webアプリケーションを含む単一アプリケーションは、OC4Jクラスタにある複数のOC4Jインスタンスにデプロイされます。
|
関連資料: Java SSOの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
Oracle Identity Managementでは、分散したエンタープライズ・アプリケーションを保護するためのエンタープライズ・インフラストラクチャが提供されます。Oracle Identity ManagementはOracle Internet Directory（OID）、LDAPサーバー、シングル・サインオン、セキュリティおよびユーザー管理機能の統合パッケージです。
OracleAS Web ServicesのセキュリティはOracle Identity Managementと統合されます。この統合で次のサービスの実行が可能になります。
Webサービスの保護とOIDサーバーに対する認証。
Oracle Single Sign-Onサーバーで認証済のユーザーIDを、SAMLトークンをベースとした標準を使用してリモートWebサービスに伝播すること。
詳細レベルのJAAS認証のWebサービスに対する実装。この場合、JAAS認証ポリシーはOIDサーバーに格納されています。
|
関連資料: Oracle Internet Directoryを構成するコンポーネントの詳細は、『Oracle Identity Managementインフラストラクチャ管理者ガイド』を参照してください。 |
OracleAS Web ServicesのWebサービス・セキュリティは、Active Directoryなどの外部（Oracle以外）LDAPサーバーと統合されます。この統合で次のサービスの実行が可能になります。
Webサービスの保護とLDAPサーバーに対する認証。
詳細レベルのJAAS認証のWebサービスに対する実装。この場合、JAAS認証ポリシーはsystem-jazn-data.xmlというXMLファイルに格納されています。
外部LDAPサーバーの統合は、HTTP Basic、ユーザー名トークン、X.509トークンおよびSAMLトークンなどのWebサービス認証メカニズムをサポートします。
Oracle Application Server Web Servicesセキュリティの現在のリリースは、次のリリースの外部LDAPサーバーと統合できます。
10g（10.1.3.1.0）のOracle Application Server Web Servicesセキュリティは、Windows 2000およびWindows 2003のActive Directoryと統合されます。
10g（10.1.3.1.0）のApplication Server Web Servicesセキュリティは、Sun Java System Application Server（一般的にはiPlanetと呼ばれている）と統合されます。
|
関連資料: Oracle Identity ManagementとOC4Jセキュリティの統合の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
Oracle Access Managerは、ユーザーIDおよびプロファイルの管理、シングル・サインオンおよびアクセス制御のための完全なソリューションです。Oracle Access ManagerをOC4Jと統合することで、単一のOracle Access Managerインスタンスによって1つ以上のOC4Jインスタンスの認証と認可を一元化できます。この単一インスタンスによってシングル・サインオンにアクセスし、監査を一元化し、より強力な認証オプションを提供できます。
OC4Jに対するOracle Access Managerセキュリティ・プロバイダを使用すると、Webベースのアプリケーションおよびシングル・サインオンの認証と認可を構成できます。また、EJB認証や、ユーザー名トークン、X.509トークンおよびSAMLトークンなどのWebサービス認証メカニズムの構成にも使用できます。
|
関連資料: Oracle Access Managerの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
この項では、Oracle JDeveloperおよびApplication Server Controlのツールで設定可能なWebサービス・セキュリティ構成の概要について説明します。
この項の内容は次のとおりです。
|
関連資料: Application Server ControlおよびOracle JDeveloperのオンライン・ヘルプ。オンライン・ヘルプでは、これらのツールで制御可能な個々のセキュリティ・オプションの詳細が提供されています。 |
Application Server Controlは、デプロイされたWebサービスのセキュリティ構成の読取りおよび変更ができます。構成値が一度変更されて適用されると、Webサービスは再起動して新しい値で実行されます。Application Server Controlは、ポートおよび操作レベルのWebサービス・セキュリティ・オプションの設定にも使用できます。
グローバル・レベルでは、Application Server Controlを使用してキーストア構成と署名および暗号の鍵を設定できます。セキュリティ構成と同様に、キーストア、署名または暗号の値を変更した場合は、新しい値を有効にするためアプリケーションを再起動する必要があります。
|
関連資料: Application Server Controlを使用して、デプロイされたWebサービスの構成を読取りおよび変更する方法は、このツールのオンライン・ヘルプを参照してください。 |
グローバル・キーストアを使用するか、Webサービス・ポートに対するアプリケーション固有のキーストアを使用するかを選択できます。グローバル・キーストアを選択した場合、これは対象のOC4Jインスタンスでデプロイされたすべてのアプリケーションに適用されます。ポート固有キーストアを選択した場合、これはユーザーのアプリケーションでデプロイされます。グローバル・キーストアについては、キーストアの名前、パスおよびパスワードを選択します。また、メッセージの署名および暗号化のためのID証明書も選択します。
アプリケーション固有キーストアを選択した場合、このWebサービス・ポートで公開されたすべての操作で使用される署名および暗号化のためのID証明書も指定する必要があります。
|
注意: 双方のサーバーおよび信頼できる証明書は同じキーストアに格納されます。これは、Secure Sockets Layer（SSL）やOracle Remote Method Invocation（ORMI）がOC4Jで使用される場合とは異なります。キーストアとしてOracle WalletまたはJava Key Store（JKS）のどちらかを使用できます。これらのキーストアの使用方法については、「キーストアの使用方法」を参照してください。 |
|
関連項目:
|
インバウンドおよびアウトバウンドのSOAPメッセージに対するセキュリティ構成は、ポート・レベルおよび操作レベルで設定できます。同じセキュリティ操作（キーストア設定を除く）が操作レベルでも可能です。
ポート・レベル設定はWebサービス・アプリケーションに適用されます。ポート・レベル・セキュリティ構成は、Webサービス・ポートで公開されるすべての操作で使用されます。操作レベル設定はWebサービス・アプリケーションの特定の操作に適用されます。操作レベルで行われた構成設定は、ポート・レベルの設定を上書きします。
ポート・レベルでは、Webサービス上のすべての操作に適用されるキーストアとID証明書も選択します。これらの値は、操作レベルで上書きすることはできません。
ポート・レベルと操作レベルは、インバウンドSOAPメッセージに対する同じセキュリティ・オプションを共有します。この項ではApplication Server Controlで設定可能なオプションの概要を説明します。
インバウンド・メッセージに対する認証: ユーザー名/パスワード（Nonceまたはタイムスタンプがある場合、もしくはない場合）、X.509証明書、またはSAMLトークンを使用して、メッセージをWebサービスで認証するかどうか指定できます。Application Server Controlで設定可能な認証要素の詳細は、「インバウンド・メッセージに対するセキュリティ要素」を参照してください。
インバウンド・メッセージに対する署名検証: メッセージ・ボディの署名を必要とするかどうか、タイムスタンプが存在するかどうか、および一連の受入れ可能な署名アルゴリズムを指定できます。Application Server Controlで設定可能な検証要素の詳細は、「インバウンド・メッセージに対する署名検証要素」を参照してください。
インバウンド・メッセージに対する復号化: メッセージ・ボディを復号化するかどうか、および一連の受入れ可能な暗号化アルゴリズムを指定できます。Application Server Controlで設定可能な復号化要素の詳細は、「インバウンド・メッセージに対する復号化要素」を参照してください。
ポート・レベルと操作レベルは、アウトバウンド・メッセージに対する同じセキュリティ・オプションを共有します。この項ではApplication Server Controlで設定可能なオプションの概要を説明します。
アウトバウンド・メッセージに対する署名: メッセージを署名するかどうか、タイムスタンプを追加するかどうか、および受入れ可能な署名アルゴリズムを指定します。Application Server Controlで設定可能な署名要素の詳細は、「アウトバウンド・メッセージに対する署名要素」を参照してください。
アウトバウンド・メッセージに対する暗号化: 別名を指定することで、リクエスト証明書または公開鍵のどちらかを使用して、アウトバウンドSOAPメッセージのボディ要素を暗号化します。Application Server Controlで設定可能な検証要素の詳細は、「アウトバウンド・メッセージに対する暗号化要素」を参照してください。
Webサービス・エージェントを使用すると、Oracle Web Services Manager（WSM）で管理できるようにWebサービスを構成できます。Oracle WSMおよびOracle Web Services Manager Agentは、Webサービスに対してセキュリティ・ポリシーを適用する別の手段を提供します。Oracle Web Services Managerで宣言型のポリシーを作成し、それらをファイルにエクスポートすることができます。Webサービス・エージェントをApplication Server Controlで構成する場合、ポリシーはWebサービスに適用されます。異なるセキュリティ・アルゴリズムをサポートし、Oracle Access ManagerおよびSiteMinderとの統合を提供できるという点で、エージェントはWeb Services Securityよりも機能が優れています。
Oracle JDeveloperを使用して、OracleAS Web ServicesおよびクライアントのWebサービス管理構成ファイルを開発できます。これらのファイルの初期作成時や、既存ファイルへの管理構成の追加にOracle JDeveloperを使用できます。
Oracle JDeveloperのウィザードを使用して、インバウンドおよびアウトバウンドのSOAPメッセージに対するポート・レベルおよび操作レベルのセキュリティを構成できます。グローバル・レベルのセキュリティ設定には使用できません。
ポート・レベルと操作レベルは、インバウンドおよびアウトバウンド・メッセージに対する同じセキュリティ・オプションを共有します。この項ではOracle JDeveloperウィザードで設定可能なオプションの概要を説明します。
Webサービス認証: ユーザー名およびパスワード、X.509証明書またはSAMLトークンを使用してWebサービスがアクセスされるかどうか指定します。
インバウンド・メッセージに対する署名検証: インバウンド・メッセージが署名されているべきかどうか、および署名アルゴリズムを指定します。
インバウンド・メッセージに対する復号化: インバウンド・メッセージを復号化すること、および復号化アルゴリズムを指定します。
アウトバウンド・メッセージの署名: アウトバウンド・メッセージに署名とタイムスタンプを追加するかどうか、および署名アルゴリズムを指定します。
アウトバウンド・メッセージに対する暗号化: 公開鍵を使用するか、または事前に送信された署名済メッセージからクライアント提供の証明書を使用するか、および暗号化アルゴリズムを指定します。
キーストア・パス: 選択されたセキュリティ・ポリシーの実装に必要な、各種の鍵の資格証明を保存する場所を指定します。ポート・レベルのみ設定できます。
署名鍵: メッセージの署名に必要な鍵にアクセスするための別名およびパスワードを指定します。ポート・レベルのみ設定できます。
暗号鍵: メッセージの復号化に必要な鍵にアクセスするための別名およびパスワードを指定します。ポート・レベルのみ設定できます。
|
関連資料: JDeveloperウィザードにおけるセキュリティ・オプションの詳細は、Oracle JDeveloperのオンライン・ヘルプを参照してください。 |
Oracle Web Services Manager（WSM）は、Webサービスの本番環境へのデプロイに必要な可視性および制御を提供する、Webサービスのセキュリティおよび管理ソリューションです。Oracle WSMによって、組織はすべてのWebサービス・アプリケーションに対して共通のセキュリティ・インフラストラクチャを使用できます。これによって、既存または新規のサービス全体にベスト・プラクティスのセキュリティ・ポリシーおよび監視を配置できます。
Oracle WSMでは、管理者はブラウザベースのツールを使用してセキュリティ・ポリシーおよび管理ポリシーを作成します。通常のWebサービス・セキュリティ・ポリシーには次の項目が含まれています。
受信したXMLメッセージの復号化
ユーザーの資格証明の抽出
このユーザーに対する認証の実行
このユーザーおよびこのWebサービスに対する認証チェックの実行
認証チェック情報を含むログ・レコードの書込み
すべてのステップが成功した場合の、メッセージの対象Webサービスへの受渡し
すべてのステップが成功しなかった場合の、エラーのリターンと例外レコードの書込み
セキュリティ・ポリシーを適用するため、Oracle WSMはWebサービスへのすべての受信リクエストをインターセプトし、リストにあるポリシー項目のいずれか1つを適用します。ポリシーの実行に伴い、Oracle WSMはその操作に関する統計を収集し、それを監視サーバーに送信します。モニターにはエラー、サービス可用性データなどが表示されます。この結果、サービス開発者が余分なロジックをコーディングしなくても、エンタープライズ・ネットワークの各Webサービスは自動的にセキュリティと管理制御を得ることができます。
|
関連資料:
|
次の項でOracle WSMを使用する利点について説明します。
Webサービスのアクセス制御とシングル・サインオン
Oracle WSMは、Webサービスに対する認証、認可および監査を含む、シングル・サインオンをサポートします。たとえば、ブラウザベースのシングル・サインオンCookieを、Webサービスにおける認証と認可に使用できます。Oracle WSMはSiteminderやOracle Access Managerなどの製品と緊密に統合して、エンタープライズ・シングル・サインオン・ソリューションをサポートします。また、Microsoft Active Directoryによる認証および認可や、LDAPもサポートします。
実施のローカライズによる一元的セキュリティ・ポリシー管理
Oracle WSMを使用することで一元的なセキュリティ・インフラストラクチャが強化されるため、組織は、各サービスへのセキュリティの構築に必要なコピー回数を最小限にできます。OracleAS Web Servicesの管理ソリューションでは、Webサービスのコードを再生成しなくても、既存のWebサービスにベスト・プラクティス・セキュリティを追加することができます。
開発者ではなくセキュリティ専門家が担当するセキュリティ・ポリシー
企業はセキュリティ・ポリシーの管理に苦慮しています。企業の目標は、中心地点からセキュリティ・ポリシーを変更、開発および管理することです。これによってコストが削減され、企業が迅速にアプリケーション全体のセキュリティ・ポリシーを決定することが可能になります。
Oracle WSMとOracleAS Web Servicesセキュリティは両方ともWebサービスの保護機能を提供します。OracleAS Web Services内におけるWS-Securityの実装は、Webサービスを使用する全ユーザーがそのWebサービスを保護できるようにするため、開発されました。OracleAS Web ServicesセキュリティはOracle10gリリース3（10.1.3.1.0）のOracle Application Serverにバンドルされ、WS-Security 1.0仕様をサポートします。これは、WebサービスがOC4Jインスタンス内にデプロイされ、セキュリティがOC4Jでローカルに実行されるデプロイ環境には理想的です。
多数のWebサービスの一元的な管理および保護が必要とされる、大規模なデプロイまたはエンタープライズ全体でのデプロイの場合は、Oracle WSMをお薦めします。
