| Oracle Application Server Web Servicesセキュリティ・ガイド 10gリリース3（10.1.3） B31870-01 |
|
 戻る |
 次へ |
この章では、Webサービス・セキュリティを使用する場合の一般的な例について説明します。最も単純な使用例から始めて、より複雑な使用例を段階的に説明していきます。この章の最初の項ではセキュリティ機能のない使用例を説明します。これらは後で、セキュリティ機能を追加するように変更されます。この章は次の項で構成されています。
この項ではWebサービス・セキュリティを使用しない単純な使用例を説明します。これらの使用例はセキュリティ機能の追加をデモンストレーションする際のベースとなります。
|
関連資料: 保護されていないWebサービスの実装方法の詳細は、『Oracle Application Server Web Services開発者ガイド』を参照してください。 |
図5-1に、Webサービス・クライアントがWebサービスを起動する、基本Webサービスの使用例を示します。
このWebサービスはクライアントにリアルタイムの株価を提供します。Webサービス・クライアントはORCLなどの銘柄コードを指定して、現在の株価をレスポンスとして要求します。
図5-2に、ユーザーが自動車ローンを申込みできる銀行のWebサービスである複合ワークフローを示します。
銀行WebサービスはWebサービス・クライアントから申込人の申込書を受け取り、信用調査機関への問合せを行うためWebサービスを起動します。銀行Webサービスには、信用調査機関のWebサービスを起動するWebサービス・クライアントが含まれています。この機関は銀行Webサービスにレスポンスを送り返します。このレスポンスは、承認または非承認という文字列と申込人の信用履歴である可能性があります。
図5-3に、Webサービス・クライアントとWebサービスを分離する中間点を示します。この中間点は外部公証サービス、XMLファイアウォール、BPELプロセス・マネージャ、またはサービス品質（QOS）エージェントである場合があります。
一般的な中間点はSOAPボディのコンテンツを変更しませんが、SOAPヘッダーの追加または変更は行います。たとえば、XMLファイアウォールはコンテンツを検証し、ユーザーを認証して認可しますが、SOAPボディは処理しません。これは、中間点がWebサービスの最終目的地ではないからです。
フェデレーテッド使用例は基本Webサービスと似ていますが、セキュリティ境界まで及ぶ点のみが異なります。図5-4に、顧客がWebサービスによって注文書を送信できる会社の例を示します。Webサービスを公開している会社がWebサービス・クライアントを所有または制御していないことに注意してください。
HTTP経由で送信されるSOAPメッセージなどのデータを保護する従来の方法は、Secure Sockets LayerとHTTP認証の使用です。
Secure Sockets Layer（SSL）は、クライアントとサーバー間で送信されるメッセージを中間アプリケーションが読み取ることを防止します。SSLは公開鍵暗号化を使用してクライアントとサーバー間でセッション鍵を交換します。このセッション鍵は、HTTPのリクエストおよびレスポンス・トラフィックの暗号化に使用されます。SSLは最も一般的に使用されるHTTPベースのセキュリティ・ソリューションです。図5-5にSSL暗号化を使用する際のデータ・フローを示します。
|
関連資料: SSL構成の手順については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
|
注意: Oracle Application Server Web ServicesはTLS暗号化もサポートしています。この詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。 |
ビジネスではしばしば、Webサービスへのアクセスが認証されたユーザーに対してのみ制限される場合があります。次の項では最も一般的な2つのアプローチについて説明します。
|
関連資料: Basic認証とDigest認証の実装方法の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
Basic認証を使用する際、Webサービス・クライアントは、Base64でエンコードされたユーザー名およびパスワードをHTTP認可ヘッダーで送信することによって、そのクライアントをサービスに対して認証します。Basic認証では、デコードが容易なBase64エンコーディングを使用して資格証明が送信されるため、セキュリティ面は脆弱です。Base64エンコーディングによる資格証明の送信は、クリアテキストで送信するのと同じくらい安全性に欠けています。図5-6にBasic認証を使用する際のデータ・フローを示します。
Webサービスが認証リクエストを検証するときは、資格証明ストアに対して実行する必要があります。OracleAS Web Servicesアプリケーションでは、認証リクエストはLDAPセキュリティ・プロバイダを通して検証されます。たとえば、WebサービスはLDAPプロバイダを使用するように構成できます。
Oracleには、WS-Securityのメッセージ・レベル・セキュリティを提供するための、インターセプタと呼ばれるビルド済のJAX-RPCハンドラが用意されています。アウトバウンド・メッセージについて、これらのインターセプタはWS-Security認証、XML暗号化およびXMLデジタル署名の操作をサポートするために必要なWS-Securityヘッダーを追加します。インバウンド・メッセージについては、インターセプタは対応するヘッダー情報を処理します。
|
注意: アプリケーションはSSLのみまたはWS-Securityのみ、あるいはその両方を一緒に使用できます。 |
WS-Security認証は、Basic認証またはDigest認証よりもはるかにフレキシブルです。WS-Securityには、Webサービスに対する認証を行うための3つの認証プロファイルがあります。
これらのプロファイルはそれぞれ、WS-Security仕様内での各トークン・タイプの使用方法を定義します。Oracleには、すべてのWS-Securityトークン・プロファイルに対するビルド済のインターセプタが用意されています。
ユーザー名トークン・プロファイルはHTTPのBasic認証およびDigest認証と似ています。アプリケーションは3つの資格証明タイプでユーザー名トークンを構成できます。
パスワードのないユーザー名
パスワード付きのユーザー名
暗号化されたパスワード付きのユーザー名
ユーザー名トークン・インターセプタはトークンをSOAPエンベロープに追加します。
OracleAS Web Servicesでホスティングされている場合、受信側のWebサービスにもユーザー名トークン・インターセプタがあります。インターセプタはユーザー名トークンを処理し、その中に含まれる資格証明を、Oracle Internet Directory LDAPベース・プロバイダなどのWebサービスの構成済セキュリティ・プロバイダに対して検証します。
ユーザー名トークン使用例は、OracleAS Portalとその他のWebベース・アプリケーションにおける共通の使用例です。この利点は、すべての資格証明チェックが中心的ユーザー・リポジトリに対して行われることです。
X.509プロファイルはX.509証明書を使用して、受信側のWebサービスに対する認証を行います。Oracleには、アウトバウンド・メッセージにWS-Security X.509認証を追加するビルド済のインターセプタが用意されています。送信されるSOAPエンベロープのWS-Securityヘッダーに証明書トークンが追加されます。証明書はOracle WalletまたはJava Key Storeなどの資格証明ストアから読み取られます。
OracleAS Web Servicesの下で、受信側WebサービスのインターセプタがX.509証明書の署名を検証してから、ユーザーがディレクトリに存在するかどうかをチェックします。証明書の識別名に一致する名前がディレクトリに存在する必要があります。受信側Webサービスが外部J2EEコンテナまたは.NET Webサービスである場合は、その各Webサービス固有の、WS-Security X.509証明書を検証する手段が用意されています。
SAMLトークンは、ユーザー名およびX.509トークンとは異なり、SAMLユーザーまたはサブジェクトがすでに認証済であると保証します。SAMLセキュリティ・トークンは、ユーザーに関する1つ以上の文を含むアサーションで構成されています。SAMLアサーションは、アサーション要素をヘッダー内に配置することで、WS-Securityを使用してSOAPメッセージにアタッチされます。Oracleはsender-vouchesおよびholder-of-keyの2つのSAML使用例をサポートします。
sender-vouches使用例では、アサーションのサブジェクトの検証について送信者が保証します。送信者の秘密鍵がアサーションおよびメッセージ・ボディ両方の署名に使用されます。送信者がSAML認証局からアサーションを取得する場合は、SAML認証局がメッセージに署名する可能性もあります。この例ではアサーションの二重署名が起こります。
XML署名はSOAPメッセージに対してメッセージ整合性を保証します。XML署名を使用する際、アウトバウンド・メッセージ・ボディは送信者の秘密鍵でデジタル署名されます。受信者は送信者の公開鍵を使用して署名を検証します。
Oracleではメッセージ・レスポンスの整合性保護もサポートされています。メッセージ・ボディ、メッセージ・ヘッダー、またはどちらかのパーツに署名するためのXML署名の使用例は多数あります。たとえば、送信者を公的に認定するため、アプリケーションはメッセージ・ボディ全体に署名できます。別のアプリケーションは、発生元が異なる要素で、別々の署名者による署名で識別されるような、ボディのいくつかの要素に署名できます。また、転送中または保存中における改ざんを検知することで、署名はコンテンツ整合性の検証にも使用できます。
XML暗号では、SOAPボディ、SOAPヘッダーまたはこれらの構造内のXML要素などの、XML要素を暗号化できます。インターセプタは元のXMLデータを暗号化された要素に置き換えます。受信者はその要素を復号化する必要があります。
XML暗号は目標とされた暗号化に使用されます。アプリケーションはメッセージ・ボディ全体、またはメッセージ・ボディ内の下位要素のみを暗号化できます。XML暗号はSSLにかわるものではありませんが、この2つは同時または別々に使用できます。たとえば、SOAPペイロードには、クレジット・カード・アカウント番号を含む要素のみにXML暗号を使用するクレジット・チェックが含まれる場合があります。この情報は、マルチステップ・プロセスで最終目的地に到達するまで暗号化されない可能性もあります。このため、転送中も保護するためにメッセージ全体がSSL経由で送信されます。
暗号化をサポートするため、インターセプタはJava Key StoreまたはOracle Walletにアクセスできる必要があります。XML暗号に対して、Webサービス・クライアントはWebサービスの公開鍵を使用します。Webサービスはその秘密鍵を使用することで、クライアントによって送信されたXML暗号化要素を復号化します。
一部のアプリケーションでは、J2EEコンテナ内にセキュリティを適用するかわりに、ゲートウェイ（一元的なポリシー実施ポイント）を使用してメッセージ・セキュリティを実装します。ゲートウェイは、すべてのWebサービスが外部Webサービスにアクセスする前に通過しなければならないチェックポイントとしての役割を果します。たとえば、企業のWebサービス・クライアントと外部Webサービスを分離するゲートウェイが存在する場合があります。このゲートウェイはすべてのアウトバウンドWebサービスでWS-Securityポリシーを実施します。
図5-16で示されたゲートウェイではすべてのアウトバウンド・メッセージが必ず署名されます。
Webサービスはしばしば、Identity Managementインフラストラクチャに対して認証および認可を行います。OracleAS Web Servicesでは、インターセプタはIdentity Managementセキュリティ・プロバイダ構成を使用して認証箇所を決定します。たとえば、プロバイダがLDAPプロバイダである場合は、LDAPディレクトリに対して認証されます。
多くのビジネス環境では、たとえばOracle Webサービス・クライアントが.NET Webサービスと相互運用されるような、混合ベンダー環境が必要とされます。
Webサービスと関連する、ベンダー間の相互運用性では多くの使用例があります。ベンダー間の相互運用性については、Basic Security Profile（BSP）仕様を参照してください。この仕様はWeb Services Interoperability（WS-I）Organization（http://www.ws-i.org/）から入手できます。
