A Webサービス・セキュリティ標準

注意: この付録には、Oracle Infrastructure Webサービスのセキュリティ標準がまとめられています。サポートされるバージョンと仕様へのリンクの完全なリストについては、『Oracle Infrastructure Webサービス開発者ガイド』のサポートされる標準に関する項を参照してください。 WebLogic Webサービスの標準の詳細は、『Oracle WebLogic Server WebLogic Webサービスの紹介』のWebLogic Webサービスでサポートされる機能と標準に関する項を参照してください。

セキュリティ標準は、トランスポート・レベルのXML以外のフレームと、アプリケーション・レベルのXMLフレームワークに実装されています。

次の項では、トランスポート・レベルおよびアプリケーション・レベルの両方で、安全かつ管理可能なSOA環境を提供するための鍵となる標準について説明します。

• Webサービスの相互運用性組織: Basic Security Profile

• Transport Layer Security - SSL

• XML暗号化(機密保護)

• XML署名(整合性、認証性)

• WS-Security

• WS-Securityトークン

• WS-Policy

• WS-SecurityPolicy

• Webサービス・アドレス(WS-Addressing)

• WS-Trust

• WS-ReliableMessaging

関連項目: Oracle WebLogic Webサービスでサポートされる標準の完全なリストについては、『Oracle WebLogic Server WebLogic Webサービスの紹介』のWebLogic Webサービスでサポートされる機能と標準に関する項を参照してください。

Webサービスの相互運用性組織: Basic Security Profile

オラクル社は、Webサービス・プラットフォームの相互運用性は、可能なあらゆるケースのWebサービス仕様に対してサポートを提供するよりも重要であると考えます。当社はWebサービスの相互運用性組織による次の仕様を遵守しており、これをWebサービスの相互運用性に対するベースラインとしています。

• Basic Security Profile 1.0: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html

Transport Layer Security - SSL

Transport Layer Security(TLS)とも呼ばれるSecure Sockets Layer(SSL)は、最も広く使用されているトランスポート・レイヤー・データ通信プロトコルです。SSLでは、次のことが可能です。

• 認証: 通信は信頼できる2つのパーティ間に確立されます。

• メッセージ機密保護: 交換されるデータは暗号化されます。

• メッセージ整合性: データが破損しているかどうか確認されます。

• クライアントおよびサーバー間での安全な鍵の交換

SSLは次の3つのモードで使用できます。

• 認証なし: クライアントもサーバーもお互いに認証しません。証明書も送信または交換されません。この場合は、機密保護(暗号化/復号化)のみが使用されます。

• 一方向認証(またはサーバー認証): サーバーのみがクライアントに対して自身を認証します。サーバーは、自身が信頼できることを検証する証明書をクライアントに送信します。この方法は、オンライン・バンキングなどのインターネット・トランザクションで使用されます。

• 双方向認証(または相互認証): クライアントとサーバーの両方が、相互に証明書を送信することでお互いに認証します。この方法は、プロキシとWebサービス・エンドポイント間での攻撃の防止に必要です。

SSLでは、秘密鍵および公開鍵暗号化を組み合せて通信を保護します。SSLトラフィックでは、暗号化と復号化に秘密鍵が使用され、通信に関わるパーティの相互認証で公開鍵の交換が行われます。

XML暗号化(機密保護)

XML暗号化の仕様には、データを暗号化し、その結果をXMLで表すためのプロセスが記述されています。XML暗号化では、具体的に次のことが定義されています。

• デジタル・コンテンツが暗号化および復号化される仕組み。

• 暗号化キーの情報が受信者に渡される仕組み。

• 暗号化を簡略化するために暗号化されたデータが識別される仕組み。

XMLドキュメントは、全体または一部を暗号化できます。

例A-1はXMLで表示されたクレジット・カード・データを示します。

例A-1 クレジット・カード・データのXML表現

  <PaymentInfo xmlns="http://www.example.com/payment">
    <CreditCard>
      <Name>John Smith</Name>
      <CreditCardNumber>4019 2445 0277 5567</NCreditCardNumber>
      <Limit>5000</Limit>
      <Issuer>Example Bank</Issuer>
      <Expiration>04/02</Expiration>
    </CreditCard>
  </PaymentInfo>

例A-2は、同じXMLスニペットを、クレジット・カード番号を暗号化し、暗号値で表したものを示しています。

例A-2 暗号化されたクレジット・カード・データのXML表現

  <PaymentInfo xmlns='http://www.example.com/payment">
    <CreditCard>
      <Name>John Smith</Name>
      <CreditcardNumber>
        <EncryptedData xmlns="http://www..." Type="http://www...">
          <CipherData>
            <CipherValue>A23B4...5C56</CipherValue>
          </CipherData>
        </EncryptedData>
      <Limit>5000</Limit>
      <Issuer>Example Bank</Issuer>
      <Expiration>04/02</Expiration>
    </CreditCard>
  </PaymentInfo>

関連項目: XML暗号化の詳細は、次のサイトの「XML Encryption Syntax and Processing」仕様を参照してください。 http://www.w3.org/TR/xmlenc-core

XML署名(整合性、認証性)

XML署名の仕様には、署名の処理ルールと構文が記述されています。XML署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは、送信者の秘密鍵を使用して署名され、署名は送信者の公開鍵を使用して検証されます。

署名の検証は、非対称鍵または対称鍵を使用して行われます。XML署名は、署名エンティティの否認防止も保証し、署名後にメッセージが変更されていないことを証明します。

次の例に示すように、署名はドキュメント全体にも、ドキュメントの一部のみにも適用できます。

例A-3 署名されたデータのXML表現

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<!-- The signedInfo element allows us to sign any portion of a
 document -->
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www..."/>
    <SignatureMethod Algorithm="http://www..."/>
    <Reference URI="#Body">
      <DigestMethod Algorithm="http://www..."/>
      <DigestValue>o+jtqlieRtF6DrUb...X8O9M/CmySg</DigestValue>
    </Reference>
  </SignedInfo>
  <!-- Following is the result of running the algorithm over the
  document. If changes are made to the document, the SignatureValue is
  changed. The security application verifies the SignatureValue,
  extracts the X.509 cert and uses it to authenticate the user -->
  <SignatureValue>oa+ttbsvSFi...EtRD2oNC5</SignatureValue>
  <KeyInfo>
    <KeyValue>
      <!-- Following is the public key that matches the private key
      that signs the document -->
      <RSAKeyValue>
        <Modulus>5TT/oolzTiP++Ls6GLQUM8xoFFrAlZQ...</Modulus>
        <Exponent>EQ==</Exponent>
      </RSAKeyValue>
    </KeyValue>
    <!-- Following is the certificate -->
    <X509Data>
      <X509Certificate>wDCCAXqgAwIBAgI...</X509Certificate>
    </X509Data>
  </KeyInfo>
</Signature>

関連項目: XML署名の詳細は、次のサイトの「XML Signature Syntax and Processing」仕様を参照してください。 http://www.w3.org/TR/xmldsig-core

WS-Security

Web Services Security(WS-Security)は、XML暗号化により機密保護を、XML署名によりデータ整合性を実現するSOAPセキュリティ拡張機能を指定します。WS-Securityには、タイプの異なるバイナリとXMLセキュリティ・トークンを、認証および認可の目的でWS-Securityヘッダーに挿入する方法を指定するプロファイルも含まれています。WS-Securityトークン・プロファイルは、次の項で説明されています。

関連項目: WS-Securityおよびその仕様の詳細は、次のサイトを参照してください。 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

WS-Securityトークン

Webサービス・セキュリティは、次のセキュリティ・トークンをサポートします。

• ユーザー名: Webサービス・コンシューマが、認証の資格証明としてユーザー名を指定する方法を定義します。詳細は、「ユーザー名」を参照してください。

• X.509証明書: 受信パーティに公開鍵を送信するために設計された署名付きデータ構造。詳細は、「X.509証明書」を参照してください。

• Kerberosチケット: バイナリ認証およびセッション・トークン。詳細は、「Kerberosトークン」を参照してください。

• Security Assertion Markup Language(SAML)アサーション: XMLドキュメントを使用して、インターネット上でセキュリティ情報を共有します。詳細は、「SAMLトークン」を参照してください。

ユーザー名

ユーザー名トークンはBasic認証情報を伝達します。username-token要素は、メッセージを認証するためにユーザー名とパスワードの情報を伝播します。

関連項目: ユーザー名トークン・プロファイルの詳細は、次のサイトを参照してください。 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf

X.509証明書

X.509デジタル証明書は、受信パーティに公開鍵を送信するために設計された署名付きデータ構造です。証明書には、証明書ID、発行者の識別名(DN)、有効期間、所有者のDN、所有者の公開鍵などの標準フィールドが含まれています。

証明書は、認証局(CA)によって発行されます。CAは、エンティティのアイデンティティを検証して証明書を付与し、CAの秘密鍵で署名します。CAは、公開鍵が含まれる独自の証明書を発行します。

各ネットワーク・エンティティには、信頼するCAの証明書のリストがあります。別のエンティティと通信する前に、指定されたエンティティはこのリストを使用して、別のエンティティの証明書の署名が信頼できるCAのものであることを検証します。

関連項目: X.509証明書トークン・プロファイルの詳細は、次のサイトを参照してください。 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf

Kerberosトークン

Kerberosトークンは、クロス・プラットフォーム認証のシングル・サインオン・システムです。Kerberosプロトコルを使用すると、共有の秘密鍵(対称鍵)に依存する2つのエンティティ間で相互認証を実行できます。Kerberosでは次の用語が使用されます。

• プリンシパルはユーザーのアイデンティティ(ユーザーにプリンシパルが割り当てられるということ)、またはKerberosサービスを提供するアプリケーションのアイデンティティです。

• レルムはKerberosサーバー環境です。Kerberosレルムは、EXAMPLE.COM(表記規則により大文字で表現)などのドメイン名にすることもできます。

  
  

  関連項目: Kerberos Token Profile 1.1の詳細は、次のサイトを参照してください。 http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf

  
  

Kerberosにはクライアントとサーバーに加え、両者を仲介するKey Distribution Center(KDC)と呼ばれる信頼できるパーティが関わっています。各Kerberosレルムには、最低1つのKDCがあります。KDCは、使用する操作プラットフォームによって異なるパッケージが用意されています(たとえば、Microsoft Windowsの場合、KDCはドメイン・サービスです)。WS-SecurityのKerberos Token Profileを使用すると、ビジネス・パートナはサービス指向アーキテクチャでKerberosトークンを使用できます。

SAMLトークン

Security Assertion Markup Language(SAML)は、XMLドキュメントを使用して、インターネット上でセキュリティ情報を共有するためのオープン・フレームワークです。SAMLは次の内容に対応するために設計されました。

• 単一ドメインに対するWebブラウザCookieの制限: SAMLには、複数のインターネット・ドメインにCookieを送信する標準の方法が用意されています。

• 固有のWebシングル・サインオン(SSO): SAMLには、単一ドメインまたは複数ドメインにSSOを実装する標準の方法が用意されています。この機能は、Oracle Identity Federation製品により提供されます。

• フェデレーション: SAMLを使用すると、1人のユーザーが複数のWebサイトで複数のアイデンティティを使用している場合にアカウントをリンクするなど、アイデンティティ管理が簡単になります。この機能も、Oracle Identity Federationでサポートされています。

• Webサービス・セキュリティ: SAMLには標準のセキュリティ・トークン(SAMLアサーション)が備わっており、標準のWebサービス・セキュリティ・フレームワーク(WS-Securityなど)とともに使用できます。これは、特にWebサービス・セキュリティに関連するSAMLの使用方法で、Oracle WSMで完全にサポートされています。

• アイデンティティ伝播: SAMLには、ビジネス・プロセスまたはトランザクションの複数のステップで、ブラウザからポータル、Webサービスのネットワークへと渡すことのできるセキュリティ・トークンを表す標準の方法が用意されています。Oracle WSMでもサポートされている機能です。

SAMLフレームワークは4つの部分に分かれています。

• アサーション: 認証および認可情報を定義する方法。

• プロトコル: 必要なアサーションを要求(SAMLリクエスト)し、取得(SAMLレスポンス)する方法。

• バインディング: SAMLプロトコルを業界標準のトランスポート(HTTPなど)およびメッセージング・フレームワーク(SOAPなど)に組み込む方法。

• プロファイル: 特定のユースケースをサポートするために、SAMLプロトコルおよびバインディングを組み合せる方法。

WS-Securityのコンテキストで使用されるのは、SAMLアサーションのみです。プロトコルおよびバインディングは、WS-Securityフレームワークにより提供されます。SAMLは、ブラウザベースのフェデレーションおよびWebサービス・フローにより有効化されたフェデレーションの両方において、業界で広く採用されています。

SAMLアサーションは、表現が豊富で、中間者攻撃やリプレイ攻撃の防止に役立つため、WS-Securityでは非常に一般的なセキュリティ・トークンです。

一般的に、SAMLアサーションでは、プリンシパル(ユーザーまたはアプリケーション)に関する記述を行います。すべてのSAMLアサーションには、次の共通の情報が含まれます。

• 発行者のIDおよび発行のタイムスタンプ

• アサーションID

• サブジェクト

• 名前

• オプションのサブジェクト確認(公開鍵など)

• オプションの条件(アサーションが有効な条件)

• オプションのアドバイス(アサーションの作成方法に関するもの)

SAMLアサーションには、次の3つのタイプの文が含まれます。

• 認証文: サブジェクトの認証の成功時、認証局により発行されます。サブジェクトSが手段Mによって時間Tに認証されたことをアサートします。

• 属性文: ポリシーに基づいて属性認証局により発行されます。サブジェクトSが、値a、bなどを持つ属性A、Bなどに関連付けられていることをアサートします。

• 認可決定文(SAML 2.0では非推奨で、現在はXACMLでサポートされています): サブジェクトSによる(ファイル、アプリケーション、Webサービスなどの)リソースRに対する(読取り、書込みなどの)アクションAを証拠Eに基づいて許可するかどうかを決定する認証局によって発行されます。

SAMLアサーションは埋込み可能です(つまり、SAMLアサーションには別のSAMLアサーションを含めることができます)。SAMLアサーションには、(XML署名を使用した)署名または(XML暗号化を使用した)暗号化、あるいはその両方を行うこともできます。

関連項目: SAMLトークン・プロファイルの詳細は、次のサイトを参照してください。 http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf

WS-Policy

WS-Securityとともに、WS-Policyは、Oracle Fusion Middlewareセキュリティのもう1つの主要な業界標準です。

Webサービス・プロバイダは、サービスが提供される条件(またはポリシー)を定義します。WS-Policyフレームワークを使用すると、Oracle WSMなどのWebサービス・アプリケーションによって処理されるポリシー情報の指定が可能になります。

ポリシーは、Webサービスの機能または要件を表す複数のポリシー・アサーションとして表現されます。たとえば、ポリシー・アサーションは、Webサービスへのリクエストが暗号化されることを規定します。同様に、ポリシー・アサーションでは、Webサービスで受信できる最大メッセージ・サイズを定義できます。

WS-Policy表記は、WS-PolicyAttachment仕様を使用して、様々なWebサービス・コンポーネントと関連付けられます。WS-Policy情報はWSDLファイルに埋込み可能なため、UDDIレジストリを介したWebサービス・ポリシーの公開が簡単になります。

WS-SecurityPolicy

WS-SecurityPolicyは、OASISが策定するWeb Services Secure Exchange(WS-SX)の仕様の一部です(WS-SecurityPolicyに加え、WS-SX技術協議会がWS-TrustおよびWS-SecureConversationの2つの仕様一式を定義しています。これらはこの章で後述します)。

WS-SecurityPolicyは、WS-Policyフレームワークのコンテキストで使用する一連のセキュリティ・ポリシー・アサーションを定義します。WS-SecurityPolicyアサーションは、通信パスでメッセージの安全性を確保する方法を示すものです。オラクル社は、OASIS WS-SX技術協議会のいくつかの実用セキュリティ・シナリオ(Oracle WSM 11gにより提供されるサブセット)に貢献しています。各セキュリティ・シナリオは、WS-SecurityPolicyのポリシー表記を示します。

WS-SecurityPolicyのシナリオには、(WS-Security 1.0および1.1の両方をサポートする)WS-Security仕様に記述されている複数のセキュリティ・トークン・タイプについて、WS-SecurityPolicyポリシーを設定する方法の例が記述されています。Oracle WSM 11gでサポートされているWS-SecurityPolicyシナリオのサブセットは、最も一般的な顧客のユースケースを表します。各シナリオは、複数ベンダーのWS-Security環境でテストされています。

WS-SecurityPolicyを説明するため、Oracle WSMのプレーン・テキスト・パスワードを使用するUsernameTokenでサポートされるシナリオを使用します。前述したように、ユーザー名トークンはWS-Securityで指定されるセキュリティ・トークンの1つです。この特定のシナリオでは、リクエスタがユーザー名トークンを検証する権限を持つ受信者に対して、ユーザー名トークンでパスワードを送信する必要があるとするポリシーが使用されます。パスワードは、WS-Securityユーザー名トークン・プロファイル1.1のデフォルト要件です。

このシナリオは、本番前のテスト環境シナリオでダミーのパスワードを使用する場合など、パスワードの秘匿性が重視されていない状況においてのみ推奨されます。

例A-4 WS-SecurityPolicyの例

<wsp:Policy>
  <sp:SupportingTokens>
    <wsp:Policy>
      <sp:UsernameToken/>
    </wsp:Policy>
  </sp:SupportingTokens>
</wsp:Policy>

前述のポリシーに準拠するメッセージの例を次に示します。

例A-5 WS-SecurityPolicyに準拠するメッセージの例

<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope xmlns:soap="...">
  <soap:Header>
    <wsse:Security soap:mustUnderstand="1" xmlns:wsse="...">
      <wsse:UsernameToken>
        <wsse:Username>Marc</wsse:Username>
        <wsse:Password Type="http://docs.oasis open.org...>
           XYZ
        </wsse:Password>
        <wsse:Nonce EncodingType="...#Base64Binary">qB...</wsse:Nonce>
        <wsu:Created>2008-01-02T00:01:03Z</wsu:Created>
      </wsse:UsernameToken>
    </wsse:Security>
  </soap:Header>
  <soap:Body>
    <Oracle xmlns=http://xmlsoap.org/Oracle>
      <text>EchoString</text>
    </Oracle>
  </soap:Body>
</soap:Envelope>

この例には、<Nonce>要素と<Created>タイムスタンプが含まれています。これらはオプション機能ですが、リプレイ攻撃などに対するリクエストのセキュリティを向上するために推奨されています。Nonceは、ランダムに生成される(固有の)数字です。タイムスタンプは、セキュリティ・トークンの有効期間の定義に使用できます。

Webサービス・アドレス(WS-Addressing)

SOAPには、メッセージの送信先やレスポンスまたはフォルトを返す標準的な方法がありません。WS-Addressingは、Webサービスのエンドポイントを識別し、メッセージにおけるエンド・ツー・エンドのエンドポイント識別を確保するXMLフレームワークを提供します。

Webサービス・エンドポイントは、Webサービスがメッセージを送信するリソース(アプリケーションやプロセッサなど)です。

次の例は、WS-Addressingを使用したものです(wsaはWS-Addressingのネームスペースです)。

例A-6 WS-Addressingの例

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
   xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
   <S:Header>
      <wsa:MessageID>http://example.com/xyz-abcd-123</wsa:MessageID>
      <wsa:ReplyTo>
         <wsa:Address>http://example.myClient1</wsa:Address>
      </wsa:ReplyTo>

WS-Addressingは、リクエストはJMSで行い、レスポンスはHTTPで行うといったように、トランスポート層に依存しません。また、WS-Policyなど、その他のWS-*仕様と組み合せて使用できます。

WS-Trust

WS-Trust 1.3仕様(http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.html)は、セキュリティ・トークンのリクエストおよび発行を行うフレームワークを提供するWS-Securityへの拡張機能と、ブローカ信頼関係への拡張機能を定義します。WS-Trust拡張機能は、セキュリティ・トークンの発行、更新および検証を行う方法を提供しています。

Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。WS-Trust仕様で定義されているように、これらの資格証明は、信頼ブローカとして機能する信頼できるSecurityTokenService (STS)から取得できます。つまり、STSが相互運用可能なセキュリティ・トークンを提供するためには、Webサービス・クライアントとWebサービスの両方から信頼される必要があります。

WS-ReliableMessaging

WS-ReliableMessaging(WS-RM)は、Webサービス・エンドポイント間の信頼できるメッセージ配信を確認および管理するフレームワークを定義します。WS-RMはSOAPメッセージング構造(SOAPバインディング)に準拠し、WS-Security、WS-Policy、およびWS-Addressingに依存することで、信頼性の高いメッセージングを提供します。

WS-RMは、信頼できるメッセージング(RM)ソース(メッセージを送信するパーティ)と、RMの宛先(メッセージを受信するパーティ)を定義します。WS-RMは、エンドポイント間の信頼は必ず確立し、メッセージおよびエンドポイントは正式に識別することなどの前提条件が決められています(これは前述の補完的なWS-*仕様を使用することで実現します)。

WS-RMポリシーは、WS-Policyフレームワークを活用するポリシー・アサーションを定義します。これにより、RM宛先とRMソースは指定された順序で要件を示すことができます。