Webサービス・セキュリティの概念の理解

2.1 Webサービスのセキュリティについて

Webサービスには疎結合の接続という特性があり、HTTPのようなオープン・アクセスが使用されるため、セキュリティに関する一連の新しい要件が追加されます。

Webサービスには疎結合の接続という特性があり、またオープン・アクセス(主にHTTP)が使用されるため、Webサービスによって実装されるSOAでは、次に示す一連の新たなセキュリティ要件が追加されます。

Webサービス・セキュリティの主要なコンポーネントは次のとおりです。

認証: ユーザーが表明しているとおりのユーザーであるかを検証します。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。資格証明には次のものがあります。
1. ユーザーが所有しているもの。たとえばパスポート(実世界)やスマート・カード(ITの世界)など、信頼できる機関が発行した資格証明。
2. ユーザーが知っているもの。たとえばパスワードなどの共有の秘密鍵。
3. ユーザーの特性。たとえばバイオメトリック情報。
複数のタイプの資格情報を組み合せて使用することは、強い認証と呼ばれます。たとえば、ATMカード(ユーザーが持っているもの)とPINやパスワード(ユーザーが知っていること)を使用する場合などです。詳細は、「認証の理解」を参照してください。
認可(またはアクセス制御): 認証されたユーザーの権限に基づいて、特定のリソースへのアクセスを許可します。権限は1つ以上の属性によって定義されます。属性とはユーザーのプロパティまたは特性のことです。たとえば、「Marc」はユーザーで、「会議の発言者」は属性です。詳細は、「認可の理解」を参照してください。
機密保護、プライバシ: 情報の機密性を保ちます。Webサービス・リクエストや電子メールなどのメッセージと、送信ユーザーおよび受信ユーザーのアイデンティティに、機密を保つ方法でアクセスします。メッセージのコンテンツを暗号化し、送信ユーザーおよび受信ユーザーのアイデンティティを不明瞭化することで機密保護とプライバシが実現されます。詳細は、「メッセージ保護の概要」を参照してください。
整合性、否認防止: 送信ユーザーがメッセージにデジタルで署名することによって、メッセージが転送中に変更されないようにします。デジタル署名を使用することによって、署名が検証され、否認防止が実現されます。署名内のタイムスタンプにより、このメッセージが有効期限後にリプレイされることを防ぎます。詳細は、「メッセージ保護の概要」を参照してください。

Webサービス・セキュリティの要件には、資格証明の仲介(信頼できる環境でのセキュリティ・トークンの交換)およびサービスの機能と制約(Webサービスがどの環境で何を実行できるかを定義する)も含まれます。

多くの場合、OWSMのようなWebサービス・セキュリティ・ツールは、公開キー・インフラストラクチャ(PKI)環境に依存します。PKIでは、暗号キー(データの暗号化または復号化に使用される数学関数)を使用します。キーは秘密キー、公開キーのいずれかになります。非対称暗号モデルでは、受信ユーザーの公開キーを使用してプレーン・テキストが暗号化され、受信ユーザーの対応する秘密キーを使用して暗号文が復号化されます。また、メッセージに署名することによって秘密キーがデジタル署名の作成に使用され、公開キーが署名の検証に使用されます。公開キー証明書(または略して証明書)は、公開キーの整合性を保証するために使用されます。

Webサービス・セキュリティ要件は、トランスポート・レベル(Secure Socket Layer)およびXMLフレームワークに依存するアプリケーション・レベルの両方で、業界標準によってサポートされています。

Webサービスでサポートされている仕様および標準の詳細は、「Webサービス・セキュリティ標準」を参照してください。

注意:

オラクル社は新しい標準、特にOASIS Web Services Secure Exchange技術委員会が主導する仕様の普及に貢献しています。

Oracle Web Services Manager (OWSM)は、異種の環境においてWebサービスのセキュリティを定義して実装できるように設計されています。たとえば、認証、認可、メッセージの暗号化と復号化、署名の生成と検証、および複数のWebサービス間のアイデンティティ伝播などを使用して、1つのトランザクションが完成します。

Webサービス・セキュリティ要件をまとめると次のようになります。

トランスポート・セキュリティの使用。Webサービス・コンシューマとWebサービス・プロバイダ間の通信チャネルを保護します。
メッセージ・レベルのセキュリティの使用。メッセージ部分のデジタル暗号化によって機密性を確保し、デジタル署名によって整合性を確保します。また、ユーザー名、X.509またはSAMLトークンを要求して認証を実行します。

2.2 トランスポート・レベルおよびアプリケーション・レベルのセキュリティの理解

セキュリティの概念は、トランスポート・レベルのセキュリティとアプリケーション・レベルのセキュリティに分けることができます。トランスポート・レベルのセキュリティでは、アプリケーション間の通信チャネルが保護されます。

トランスポート・レベルのセキュリティ・プロトコルの例として、Secure Socket Layer (SSL)があります。このプロトコルは、Transport Layer Security (TLS)と呼ばれることもあります。TLSは、Internet Engineering Task Force (IETF)によって公式に標準化されたSSLバージョンです。最も広く使用されている、このトラスポート・レベルのデータ通信プロトコルでは、次の機能が提供されます。

認証(通信は信頼できる2つのパーティ間に確立されます)。
機密保護(交換されるデータは暗号化されます)。
メッセージ整合性(データが破損しているかどうか確認されます)。
クライアントおよびサーバー間での安全なキーの交換。

SSLでは、通信チャネルは保護されますが、転送中でないデータは保護されません。このため、マルチステップ・トランザクション中の攻撃に対して環境が脆弱になります。(SSLでは、エンドツーエンドではなくポイントツーポイントのセキュリティが提供されます。)

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

認証なし: クライアントもサーバーもお互いに認証しません。証明書も送信または交換されません。この場合は、機密保護(暗号化/復号化)のみが使用されます。
一方向認証(またはサーバー認証): サーバーのみがクライアントに対して自身を認証します。サーバーは、自身が信頼できることを検証する証明書をクライアントに送信します。この方法は、オンライン・バンキングなどのインターネット・トランザクションで使用されます。
双方向認証(または相互認証): クライアントとサーバーの両方が、相互に証明書を送信することでお互いに認証します。この方法は、プロキシとWebサービス・エンドポイント間での攻撃の防止に必要です。

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

アプリケーション・レベルのセキュリティはトランスポート・レベルのセキュリティを補完します。アプリケーション・レベルのセキュリティでは、XMLフレームワークに基づいて、メッセージの機密保持、整合性、信頼性(メッセージ保護とも呼ばれる)、メッセージ構造、信頼の管理およびフェデレーションが定義されます。アプリケーション・レベルのセキュリティのこれらのコンポーネントについては、「メッセージ保護の概要」、「認証の理解」および「認可の理解」の各項で詳しく説明します。

2.3 認証の理解

認証とは、ユーザーが表明しているとおりのユーザーであることを資格証明に基づいて検証することです。

ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。資格証明には次のものがあります。

ユーザーが所有するもの。たとえば、信頼できる機関によって発行された資格証明(デジタル証明書など)、標準のSecurity Assertion Markup Language (SAML)トークン、Kerberosトークン。
ユーザーが知っているもの。たとえばパスワードなどの共有の秘密鍵。
ユーザーの特性。たとえばバイオメトリック情報。

複数のタイプの資格情報を組み合せて使用することは、強い認証と呼ばれます。たとえば、ATMカード(ユーザーが持っているもの)とPINやパスワード(ユーザーが知っていること)を使用する場合などです。

SAMLは非常に興味深いセキュリティ・トークンであり、認証と認可の両方がサポートされています。SAMLは、XMLドキュメントを使用してインターネット上でセキュリティ情報を共有するオープン・フレームワークです。SAMLには次の3つの部分が含まれます。

SAMLアサーション: 認証および認可情報を定義する方法。
SAMLプロトコル: 必要なアサーションを要求(SAMLリクエスト)し、取得(SAMLレスポンス)する方法。
SAMLバインディングおよびSAMLプロファイル: SAMLアサーションを業界標準のトランスポートおよびメッセージングのフレームワークに組み込む方法。

SAMLの完全仕様は、ブラウザベースのフェデレーションにおいて使用されます。それに対し、OWSMのようなWebサービス・セキュリティ・システムでは、SAMLアサーションのみが使用されます。プロトコルおよびバインディングは、WS-Securityおよびトランスポート・プロトコル(HTTPなど)により提供されます。

SAMLアサーションおよびアサーション識別子への参照はWS-Securityヘッダー要素に含まれ、SOAPエンベロープのヘッダー要素に含まれることになります(WS-Security SAMLのトークン・プロファイルに記述されます)。SAMLセキュリティ・トークンは、特にアイデンティティ伝播が必須である場合に関連します。

2.3.1 Digest認証について

OWSMは、ユーザー名トークン認証ポリシーでDigestベースの認証をサポートしています。Digest認証は、WebアプリケーションがサーバーにDigest (パスワード、nonceおよびタイムスタンプの暗号ハッシュ)を送ることによって、Webサービスに対して自身を認証する認証メカニズムです。

Digest認証の使用時には、次の処理が行われます。

クライアントがWebサービスに対して未認証リクエストを実行します。サーバーは、Digest認証をサポートしていることを示すDigest認証チャレンジ付きのレスポンスを送信します。
クライアントはnonceを生成し、それをタイムスタンプ、Digestおよびユーザー名とともにサービスに送信します。ダイジェストは、パスワード、nonce、およびタイムスタンプの暗号ハッシュです。
サーバー自身も、パスワード(サービス・ストアから取得)、nonceおよび(メッセージの)タイムスタンプからハッシュを生成します。サーバーが生成したハッシュがリクエスト内のハッシュと一致すると、リクエストが許可されます。

ダイジェスト認証の利点は、リプレイ攻撃に対する抵抗力です。ダイジェスト認証を実装すると、使用されたnonce/タイムスタンプのキャッシュが、指定した期間保持されます。指定したタイムスタンプより古いタイムスタンプのリクエストはすべて拒否されます。また、キャッシュに保持されている最新のタイムスタンプ/nonceペアと同じタイムスタンプ/nonceペアを使用するリクエストもすべて拒否されます。WebLogic Serverでは、このキャッシュはデータベースに格納されます。

2.4 認可の理解

認証は、ユーザーにWebサービスへのアクセスを許可するかどうかを決定する最初のステップとなります。ユーザーが認証されたら、2番目のステップは、ユーザーがWebサービスへのアクセスを認可されていることを検証することです。

認可(アクセス制御とも呼ばれる)とは、認証されたユーザーの資格に基づいて特定のリソースへのアクセス権を付与することです。権限は1つ以上の属性によって定義されます。属性とはユーザーのプロパティまたは特性のことです。たとえば、「Marc」はユーザーで、「会議の発言者」は属性です。

認可によって、認証されたクライアントがアクセスできる操作を決定できます。認可には次の3つの基本アプローチがあります。

ロール・ベース: ロール・ベースのセキュリティの基盤となる概念は、プリンシパルと呼ばれるアイデンティティのセットをロールにグループ化し、各ロールにポリシーを割り当てることができる、というものです。
アイデンティティ・ベース: アイデンティティ・モデルでは、クライアントの認可のために、クレームとポリシーを管理できます。このアプローチでは、認証されたユーザーの資格証明に含まれているクレームを検証できます。これらのクレームは、Windows Communication Foundation (WCF)サービスのための認証ポリシーのセットと比較できます。クライアントが提供するクレームに応じて、サービスは操作またはリソースへのアクセス権を付与するか、アクセスを拒否します。アイデンティティ・モデルは、ファイングレイン認可に役立ち、発行トークン認証の使用時に最も有効です。
リソース・ベース: Windowsアクセス制御リスト(ACL)を使用して、個別リソースが保護されます。

2.5 メッセージ保護の概要

メッセージ保護は、データの暗号化、メッセージの機密保持およびメッセージの署名のプロセスに関する機能です。

次の各トピックでは、メッセージ保護について詳しく説明します。

2.5.1 メッセージ保護の理解

メッセージ保護には、データの機密性を維持するメッセージ機密保護と、メッセージをデジタルで認可するメッセージ整合性の2つの概念があります。

メッセージの機密保護には、送信ユーザーおよび受信ユーザーのアイデンティティのみでなく、データの機密性も関係します。メッセージのコンテンツを暗号化し、送信ユーザーおよび受信ユーザーのアイデンティティを不明瞭化することで機密保護が実現されます。送信者は、受信者の公開キーを使用してメッセージを暗号化します。メッセージは受信者の秘密キーでのみ正常に復号化できるため、送信中に第三者によってメッセージが読み取られることはありません。Webサービス・クライアントが使用できるように、Webサービスのbase64エンコード形式の公開証明書がWSDLで発行されます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のサービス・アイデンティティ証明書拡張の使用に関する項を参照してください。

メッセージ整合性は、認証局がメッセージにデジタルで署名することにより実現します。デジタル署名は、SOAPメッセージの送信者を認証したり、SOAPメッセージの整合性(SOAPメッセージが送信中に変更されていないこと)を保証したりするために使用されます。

デジタル署名がSOAPメッセージに適用されると、メッセージから一意のハッシュが生成されます。このハッシュは送信者の秘密キーで暗号化されます。メッセージを受信すると、受信者は送信者の公開キーを使用してハッシュを復号化します。

注意:

通常、証明書を検証するために受信者のキーストアに送信者の公開キーを格納しておく必要はありません。キーストアにルート証明書があれば、証明書チェーンを検証できます。ただし、ThumbprintやSerialIssuerメカニズムなど、メッセージに送信者の公開キーが存在しない場合は、送信者の公開キーを受信者のキーストアに格納する必要があります。

送信者のみが秘密キーを使用してハッシュを暗号化できるため、これで送信者を認証できます。受信者はメッセージとともに送信されるハッシュと、受信者側で生成するハッシュを比較できるため、SOAPメッセージが送信中に改ざんされていないことを確認できます。

次の内容を実行することで、メッセージ保護アサーション・テンプレートおよび事前定義済ポリシーを、リクエストやレスポンス・メッセージの保護に使用できます。

メッセージの署名
メッセージの暗号化
メッセージの署名および暗号化
メッセージの復号化
署名の検証
メッセージの復号化と署名の検証

2.5.2 メッセージの暗号化について

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

XML暗号化では、具体的に次のことが定義されています。

デジタル・コンテンツが暗号化および復号化される仕組み。
暗号化キーの情報が受信者に渡される仕組み。
暗号化を簡略化するために暗号化されたデータが識別される仕組み。

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

次の例では、XMLで表現したクレジット・カード・データについて説明します。

  <PaymentInfo xmlns="http://www.example.com/payment">
    <CreditCard>
      <Name>John Smith</Name>
      <CreditCardNumber>4012 8888 8888 1881</CreditCardNumber>
      <Limit>5000</Limit>
      <Issuer>Example Bank</Issuer>
      <Expiration>04/02</Expiration>
    </CreditCard>
  </PaymentInfo>

次の例では、同じ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>

2.5.3 メッセージの署名(XML署名)について

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

署名の検証は、非対称キーまたは対称キーを使用して行われます。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>

2.6 セキュリティおよび認証でのキーおよび証明書のロールの概要

Webサービスを構成する前に、必要な秘密キーおよび証明書のタイプ、キーおよびキーストアの名前を決定する必要があります。それから、それらに従って環境を設定できます。

SSLセキュリティ・ポリシーによるメッセージ保護および認証、またはメッセージ保護セキュリティ・ポリシーを使用するには、キーストアおよびトラストストアを設定する必要があります。認証のみのセキュリティ・ポリシーではキーは不要であることに注意してください。認証ポリシーの詳細は、「OWSMポリシー・フレームワークの理解」を参照してください。

キーストアには、エンティティ秘密キーおよびその秘密キーに関連付けられた証明書が含まれます。トラストストアには、認証局(CA)からの証明書、またはこのエンティティが信頼する他のエンティティからの証明書が含まれます。キーストアとトラストストアは、たとえばOracle Web Services Manager (OWSM)などを使用して、共通のストアで一緒に管理できます。

詳細は、次のトピックを参照してください。

2.6.1 秘密キーと証明書について

サーバーのIDと信頼は、秘密キー、デジタル証明書、および信頼性のある認証局によって確立され、検証されます。

SSLでは、認証用に公開キー暗号化技術を使用します。公開キー暗号化では、サーバーの公開キーと秘密キーが生成されます。公開キーで暗号化されたデータは対応する秘密キーでのみ復号化でき、公開キーで検証されたデータは対応する秘密キーでのみ署名できます。秘密キーは注意深く保護されているので、そのオーナーだけが公開キーで暗号化されたメッセージを復号化できます。

公開キーは、公開キーの所有者を示す他の情報(名前、住所および電子メール・アドレスなど)とともにデジタル証明書に埋め込まれています。秘密キーおよびデジタル証明書は、サーバーのアイデンティティを提供します。

デジタル証明書に組み込まれたデータは認証局によって検証され、その認証局のデジタル証明書でデジタル署名されます。十分に認知された認証局には、VerisignやEntrust.netなどがあります。信頼できる認証局(CA)の証明書により、証明書の信頼性が確立されます。

SSL接続に参加するアプリケーションは、そのアプリケーションのデジタル署名を評価および承認するときに認証を受けます。Webブラウザ、サーバー、およびその他のSSL対応アプリケーションは、信頼性のある認証局によって署名され、他の点でも有効なデジタル証明書を真正として承認します。たとえば、デジタル証明書が期限切れの場合や、署名に使用された認証局のデジタル証明書が期限切れの場合、デジタル証明書は無効になります。サーバーの証明書は、サーバーのデジタル証明書内のホスト名がクライアントによって指定されたURLと一致しない場合は無効になります。

それぞれの環境で使用可能な様々なタイプの信頼できる証明書と、その長所および短所は次のとおりです。

自己署名証明書 — 自己署名証明書は、作成元のエンティティによって署名される証明書です。

長所:
- JKSキーストアのkeytoolコマンドなどを使用して自分で生成できるため、容易に生成できます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の秘密キーの生成とJavaキーストアの作成に関する項を参照してください。
- 自身で生成した新しい証明書のみを使用するかぎり、本番で使用できます。
短所:
- 相互に通信する必要がある多数のクライアントおよびサービスが存在する場合に、自己署名証明書は短期間で管理が難くなることがあります。たとえば、2つのサービスと通信する3つのクライアントが存在する場合に、両サービスについて秘密キーおよび自己署名証明書を生成し、3つのクライアントすべてのトラストストアにその2つの証明書をインポートする必要があります。
デモ用認証局(CA)署名証明書— WebLogic Serverには、開発専用のデモ用秘密キー、デジタル証明書および信頼できる認証局のセットが含まれています。

長所:
- 開発環境内のデフォルトのWebLogic Serverインストールで使用可能であり、そのために構成されているので、簡単に使用できます。
短所:
- 本番環境では決して使用できません。デモ用証明書CAの秘密キーは、WebLogic Serverのすべてのインストールで使用可能です。したがって、各インストールで同じキーを使用してデモ用CA署名証明書を生成できます。したがって、こうした証明書は信頼できません。
内部CA署名証明書 — 内部CA署名証明書は、イントラネット用に設定可能な内部CAを使用して自身で発行する証明書です。このタイプの証明書は、サービスがほとんど内部専用である場合に使用できます。

長所:
- 証明書を自身で作成するので、証明書の発行プロセスを完全に制御できます。証明書の発行先、証明書の有効期間などを制御できます。たとえば、パートナに証明書を発行する場合に、優良なパートナに発行先を限定できます。
短所:
- すべてのクライアントでトラストストアに内部CAルート証明書がインポートされていることを確認する必要があります。
外部CA署名証明書 — 外部CA署名証明書は、VerisignやEntrust.netなどの信頼できるCAによって発行された証明書です。このタイプの証明書は、サービスが外部向けである場合に使用すべきです。

長所:
- ほとんどの場合、クライアントはこうした外部CAを信頼するようにすでに設定されています。したがって、このようなクライアントでトラストストアを変更する必要はありません。
短所:
- 証明書発行プロセスを制御することはできません。

2.6.2 様々なセキュリティ・ポリシーでの秘密キーおよび証明書の使用方法の理解

秘密キーの使用を必要とするOWSMセキュリティ・ポリシーは、メッセージ保護および認証の2つの側面に対応します。

メッセージ保護には、メッセージ機密保護とメッセージ整合性の2つの概念があります。メッセージの機密保持では、データの機密性を維持します。そのために、メッセージのコンテンツは暗号化されます。メッセージ整合性では、送信ユーザーがメッセージにデジタル署名することによって、転送中にメッセージが変更されないことを確認します。
認証では、ユーザーが表明しているとおりのユーザーであることを検証します。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。

インストールに含まれている事前定義済のOWSMポリシーでは、メッセージ保護および認証の様々なオプションをサポートしています。これらのオプションについては、次に示す項で説明します。

注意:

OWSMポリシーで使用される命名規則により、使用オプションのタイプが識別されます。たとえば、ポリシーoracle/wss10_username_token_with_message_protection_service_policyは、wss10 Webサービス標準を使用し、認証のためにusername_tokenを必要とするメッセージ保護サービス・ポリシーです。ポリシーの命名規則の詳細は、「WSMリポジトリで作成されたドキュメントの推奨命名規則について」を参照してください。

詳細は、次のトピックを参照してください。

2.6.2.1 メッセージ保護ポリシー・タイプの概要

SSL、wss11およびwss10メッセージ保護ポリシーは、Oracle Web Service Managerでサポートされています。

2.6.2.1.1 SSLポリシーについて

oracle/wss_saml_or_username_token_over_ssl_service_policyなど、SSLオプションを含むポリシーでは、メッセージ保護のために一方向SSLを使用します。

このタイプのポリシーを使用する場合、次のことを実行する必要があります。

サービス側では、「SSLポリシー用の秘密キーおよび証明書について」の説明に従って、SSL終端ポイントで秘密キーを設定します。
クライアント側では、サービスのキーを信頼するようにトラストストアを設定します。

秘密キーは、クライアントとサービスが共有セッション・キーについて同意したときに、SSLハンドシェイクのためのメッセージ保護に使用されます。SSLハンドシェイクの後は、秘密キーは使用されず、クライアント間のトラフィックおよびサービスはすべて共有セッション・キーを使用して署名および暗号化されます。

SSLの構成方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のトランスポート・レベルのセキュリティ(SSL)の構成に関する項を参照してください。

2.6.2.1.2 wss11ポリシーについて

このタイプのポリシーでは、メッセージ保護にWS-Security 1.1を使用します。

wss11ポリシーを使用する場合、次のことを実行する必要があります。

サービス側では、OWSMの「キーストアの構成」画面で、秘密キーを設定し、「暗号化キーの別名」として定義します。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したOWSMキーストアの構成に関する項を参照してください。
クライアント側では、次のいずれかの方法でサーバー証明書を取得することにより、クライアント側の信頼を構成する必要があります。
- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のサービス・アイデンティティ証明書拡張の使用に関する項の説明に従って、サービス・アイデンティティ証明書拡張を使用して、WSDLで発行されたサービスの公開証明書を使用します。また、サーバー証明書を発行したCAから、サーバー証明書自体またはルート証明書のいずれかをクライアントのトラストストアにインポートする必要があります。サーバー証明書について、任意の別名を選択できます。
- 選択した任意の別名を使用してクライアントのキーストアにサーバー証明書をインポートします。別名は、ポリシーのアタッチ時に構成オーバーライドを使用して、keystore.recipient.aliasプロパティにより指定します。この方法では、実際のサーバー証明書をインポートする必要があります。CAルート証明書をインポートすることはできません。

各リクエストに関して、次のことが実行されます。

クライアントは対称キーを作成し、暗号化キーの別名により構成されたサービスの公開キーでこの対称キーを暗号化した後、対称キーによりメッセージ全体の暗号化および署名を行います。
サービスがこのメッセージを受信すると、まず暗号化されたキーを復号化し、次にメッセージ全体を復号化して検証します。
次にWebサービスは、クライアントに返信するレスポンスの暗号化および署名のために、同じ対称キーを使用します。

2.6.2.1.3 wss10ポリシーについて

このタイプのポリシーでは、メッセージ保護にWS-Security 1.0を使用します。

wss10ポリシーを使用する場合、次のことを実行する必要があります。

クライアント側およびサービス側の両方で秘密キーを設定します。クライアント側で署名キーの別名を設定し、サービス側で暗号化キーの別名および署名キーの別名の両方を設定する必要があります。通常は、両方で同じキーを使用できます。
クライアント側では、次のいずれかの方法でサーバー証明書を取得することにより、クライアント側の信頼を構成する必要があります。
- 『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のサービス・アイデンティティ証明書拡張の使用に関する項の説明に従って、サービス・アイデンティティ証明書拡張を使用して、WSDLで発行されたサービスの公開証明書を使用します。また、サーバー証明書を発行したCAから、サーバー証明書自体またはルート証明書のいずれかをクライアントのトラストストアにインポートする必要があります。サーバー証明書について、任意の別名を選択できます。
- 選択した任意の別名を使用してクライアントのキーストアにサーバー証明書をインポートします。別名は、ポリシーのアタッチ時に構成オーバーライドを使用して、keystore.recipient.aliasプロパティにより指定します。この方法では、実際のサーバー証明書をインポートする必要があります。CAルート証明書をインポートすることはできません。
サービス側では、こうした証明書を直接インポートするか、こうした証明書を発行したCAをインポートすることにより、クライアントを信頼するようにサービスを構成する必要があります。

wss11オプションの場合と同様に、クライアントは対称キーを作成した後、サービスの公開キーにより対称キーを暗号化します。ただし、メッセージの暗号化のためにのみこの対称キーを使用する点が異なり、メッセージの署名のためにはこの対称キーは使用しません。そのかわりに、クライアントは、署名キーの別名によって定義された独自の秘密署名キーによりリクエスト・メッセージに署名し、サービスはその秘密署名キーによりレスポンスに署名します。

2.6.2.2 認証トークン・ポリシー・タイプの概要

認証でサポートされるトークンは、ユーザー名、Kerberos、X.509証明書、SAML送信者保証、STSからのSAMLベアラーおよびSAML HOKトークンです。

認証の構成方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の認証の構成に関する項を参照してください。

注意:

次の各項において、「署名キーの別名」という用語は、コンテキストに応じて意味が異なります。

SAML送信者保証ポリシーでは、署名キーの別名はSAMLアサーションの署名に使用されるキーです。これにより、SAMLアサーションの認証性が証明されます。またSAMLログイン・モジュールは、SAMLアサーションで指定されたユーザーをアサートします。
wss10ポリシーでは、署名キーの別名は、リクエストおよびレスポンス・メッセージの署名に使用されるキーで、それらがオンライン上で改ざんされることを防ぎます。
X.509認証ポリシーでは、署名キーの別名は特定のエンド・ユーザーの認証に使用されるキーです。

詳細は、次のトピックを参照してください。

2.6.2.2.1 ユーザー名トークンについて

ユーザー名トークンは、ユーザー名やパスワードなどのBasic認証情報を伝達します。ユーザー名トークンが認証のみのポリシーとともに使用される場合、秘密キーは使用されません。認証およびメッセージ保護を含むポリシーで使用された場合、メッセージ保護に必要なキーが要求されます。

2.6.2.2.2 Kerberosトークンについて

Kerberosトークンは、バイナリ認証およびセッション・トークンから構成されます。Kerberosトークンが認証のみのポリシーとともに使用される場合、秘密キーは使用されません。認証およびメッセージ保護を含むポリシーで使用された場合、メッセージ保護に必要なキーが要求されます。

2.6.2.2.3 X.509証明書トークンについて

リクエスト・メッセージは、エンド・ユーザーの署名キーにより署名されます。クライアント側では、エンド・ユーザーの署名キーにより署名キーの別名を構成する必要があります。

2.6.2.2.4 SAML送信者保証トークンについて

SAML送信者保証では、クライアントは自身の秘密署名キーによりSAMLトークンに署名します。

SAML送信者保証トークンは、各メッセージ保護オプションとともに次のように使用します。

SSLを使用: SAML送信者保証では双方向SSLが必要です。したがって、クライアント側でSSL秘密キーおよびサービス側で対応する信頼証明書を設定する必要があります。SSLがOracle HTTP Serverやロード・バランサなど、WebLogic Serverの前で終端する場合、WebLogic Serverに至るまでクライアント証明書が伝播するようにこうしたレイヤーを構成する必要があります。
wss11を使用: 通常、wss11ではクライアント側の署名キーは不要です。しかし、SAMLでwss11を使用する場合は、クライアント側で署名キーを設定し、署名キーの別名を使用して署名キーを構成する必要があります。また、このクライアント証明書またはその発行者をサービスのトラストストアに追加する必要があります。
wss10を使用: SAMLを使用するための追加設定は必要ありません。リクエストの署名のために使用される通常のクライアント署名キーがSAMLトークンの署名にも使用されます。

注意:

SAML署名キーを使用する場合には細心の注意が必要です。これは非常に強力なキーであり、クライアント側で任意のユーザーを偽装できます。信頼できるDNリストを設定することにより、許容されるSAML署名者の数を制限するサーバー側の構成を検討してください。信頼できるDNの設定の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したSAMLの信頼できる発行者およびDNリストの構成に関する項を参照してください。

2.6.2.2.5 STSからのSAMLベアラーおよびSAML HOKトークンについて

これらのオプションでは、クライアントはSAMLトークンを作成しません。そのかわりに、SAMLトークンの作成および署名を行うのはSTSです。

STSからトークンを使用する場合、サービスのトラストストアにSTSの証明書またはその発行者を追加する必要があります。必要に応じて、信頼できるDNリストでSTSを構成できます。

2.6.3 OWSMでのJKSキーストア用のキーストアおよびキー・パスワードの特定の仕組み

OWSMは、JKSキーストアおよびキー・パスワードが資格証明ストア・フレームワーク(CSF)に含まれていることを前提とします。

JKSキーストアとキー・パスワードのしくみを次に示します。

注意:

OPSSキーストア・サービスの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスを使用したキーと証明書の管理に関する項を参照してください。

JKSキーストア・ファイルは、キーストアのパスワードによって保護されています。
キーストア・ファイルは、0個以上の秘密キーおよび0個以上の信頼できる証明書から構成されます。各秘密キーは、独自のパスワードを持ちます(ただし、キーのパスワードとキーストアのパスワードが同じであることが一般的です)。OWSMは、キーストアとキー・パスワードの両方を認識する必要があります。
CSFは、それぞれが個別の名前を持つ多数のマップから構成されます。OWSMは、マップoracle.wsm.securityのみを使用します。
各マップ内部で、複数のcsf-keyエントリから対応する資格証明にマッピングされています。csf-keyは、簡単な名前ではあっても、様々なタイプの資格証明が考えられます。最も一般的なタイプの資格証明は、主にユーザー名とパスワードで構成されるパスワード資格証明です。

OWSMは、oracle.wsm.securityマップ内でJKSキーストアの次のcsf-keyを参照します。
- keystore-csf-key - このキーには、キーストアのパスワードを含める必要があります。ユーザー名は無視されます。
- enc-csf-key - このキーには、ユーザー名として暗号化キーの別名、および対応するキーのパスワードを含める必要があります。
- sign-csf-key - このキーには、ユーザー名として署名キーの別名、および対応するキーのパスワードを含める必要があります。
これらのcsf-keyに加えて、OWSMで新しい秘密キーを使用するたびに(構成オーバーライドで署名キーおよび暗号化キーを指定する場合など)、対応するcsf-keyエントリを追加する必要があります。

図2-1に、OPSSのJKSキーストア構成、資格証明ストアのoracle.wsm.securityマップおよびOWSM Javaキーストアの関係を示します。

図2-1 メッセージ保護のためのOWSMキーストア構成

「図2-1 メッセージ保護のためのOWSMキーストア構成」の説明

図を見ると次のことがわかります。

keystore.csf.mapプロパティは、CSF別名を含む資格証明ストア内のOWSMマップを指します。この場合、keystore.csf.mapはお薦めの名前であるoracle.wsm.securityとして定義されていますが、任意の値でかまいません。
keystore.pass.csf.keyプロパティは、JKSキーストアのユーザー名およびパスワードにマップされたCSF別名keystore-csf-keyを指します。パスワードのみが使用されます。キーストアの場合、ユーザー名は冗長です。
keystore.sig.csf.keyプロパティは、JKSキーストアで署名に使用される秘密キーのユーザー名およびパスワードにマップされたCSF別名sign-csf-keyを指します。
keystore.enc.csf.keyプロパティは、JKSキーストアで復号化に使用される秘密キーのユーザー名およびパスワードにマップされたCSF別名enc-csf-keyを指します。

2.6.4 SSLポリシー用の秘密キーおよび証明書について

クライアント側とサービス側でSSLポリシーを使用するようにキーおよび信頼を構成できます。

サービス側の構成: SSLセキュリティ・ポリシー用に、SSL終端ポイントで秘密キーを設定する必要があります。こうした終端ポイントは一般的に、次のいずれかから構成されます。
- WebLogic ServerなどのJava EEコンテナ。構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のSSLのキーストアの構成に関する項を参照してください。
- Oracle HTTP Server(クライアントとWebLogic Server間のWebプロキシとして構成している場合)。構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のOracle HTTP ServerでのSSLの構成に関する項を参照してください。
- ロード・バランサ(WebLogic ServerまたはOracle HTTP Serverの前にロード・バランサを配置している場合)。
注意:

SSLでは、サーバーごとに1つの秘密キーのみを持つことができます。したがって、同じサーバー上で実行する複数のWebサービスが存在する場合は、そのすべてで同じ秘密キーを使用します。このSSL秘密キーは、ホスト名と同じDNで生成する必要があります。ただし、テスト目的のために、このホスト名の検証機能はクライアント側でオフにできます。

基本構成例: WebLogic Serverに含まれるデモ用のデジタル証明書、秘密キーおよび信頼できるCA証明書を使用します。これらのキーおよび証明書は、開発用にのみ提供されています。本番環境では使用しないでください。

詳細構成: 本番環境では、内部CAまたは外部CAを使用します。
クライアント側の構成: クライアント側では、クライアントのトラストストアにサーバー証明書をインポートする必要があります。サーバー側で自己署名証明書を使用している場合は、その自己署名証明書を直接含める必要があります。サーバー側でCAを使用して署名された証明書を使用している場合は、クライアント・トラストストアにそのCAルート証明書をインポートします。各タイプのWebサービス・クライアントでそのクライアント・トラストストアは異なることに注意してください。
- Java EE (WebLogic) Webサービスでは、WebLogic Serverトラストストアにキーをインポートする必要があります。デモ用CA証明書は、WebLogic Serverトラストストアにすでに含まれています。
- Oracle Infrastructure Webサービスでは、javax.net.ssl*システム・プロパティを使用してトラストストアを指定するか、または接続でトラストストアを指定する必要があります。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のWebサービス・クライアントのSSLの構成に関する項を参照してください。
- SOAコンポジット・アプリケーションでは、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の双方向SSL通信用のSOAコンポジット・アプリケーションの構成に関する項の説明に従って、javax.net.ssl*プロパティを使用してトラストストアを指定する必要があります。
- 非同期Webサービスでは、『Oracle Infrastructure Webサービスの開発』の非同期Webサービス用のSSLの構成に関する項の説明に従ってトラストストアを構成する必要があります。

2.6.5 メッセージ保護ポリシー用の秘密キーおよび証明書の設定について

OWSMメッセージ保護セキュリティ・ポリシーでは、OWSMキーストアで秘密キーを設定する必要があります。

ドメインごとに単一のOWSMキーストアが存在し、ドメイン内で実行するすべてのWebサービスおよびクライアントによってそのキーストアが共有されます。このキーストアには、秘密キーおよび信頼証明書の両方が含まれます。JDK cacertsファイルは、OWSMでは使用されません。

次の各項では、OWSMキーストアの基本構成と詳細な構成について説明します。

2.6.5.1 Sample Basic構成の理解

OWSMキーストアを設定する最も簡単な方法は、自己署名秘密キーを1つ作成し、それをドメイン全体で使用することです。秘密キーおよびキーストアを作成する際には、キーストアの名前とパスワードを指定します(たとえば、JKSキーストアを使用する場合、キーストア名としてdefault-keystore.jks、このキーストアのパスワードとしてPasswordを指定します)。また、秘密キーを参照する場合に使用する別名とパスワードも指定します(たとえば、別名としてorakey、キーのパスワードとしてPasswordなど)。署名キーの別名と暗号化キーの別名の両方で同じキーおよび別名を使用し、キーストアと別名の両方で同じパスワードを使用できます。秘密キーに関連付けた証明書は、自動的に信頼できるものと見なされるので、信頼できる証明書を追加する必要はありません。

キーおよびキーストアを作成したら、キーストアのパスワードと、別名およびパスワードをOWSMに指定する必要があります。この指定には、Fusion Middleware ControlまたはWLSTのいずれかを使用できます。

Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の秘密キーの生成とJavaキーストアの作成に関する項とFusion Middleware Controlを使用したOWSMキーストアの構成に関する項の手順では、この例で指定しているユーザー名とパスワードを使用してJKSキーストアの基本構成を設定する方法について説明しています。それぞれの環境では、構成に対して適切な名前およびパスワードを使用する必要があります。

クライアントとサーバーが同じドメインにあるかぎり、この設定はほとんどのポリシーで問題なく使用できます。つまり、SAMLの有無を問わず、任意のwss10またはwss11のポリシーを使用できます。

共通のJPSルートを共有する複数の関連ドメインが存在する場合は、すべてのドメインにこのキーストア・ファイルをコピーできます。これによって、関連するすべてのドメインがすべての暗号化および署名についてこの単一のキーを共有します。

2.6.5.2 詳細な設定に関する考慮事項について

メッセージ保護セキュリティを設定する最も簡単な方法は、ドメイン内のすべてのWebサービスについて単一の秘密キーを用意することです。

より機密性の高いWebサービスを得るには、独自の秘密暗号化キーを使用するように各Webサービスを構成する必要があります。これらの秘密キーはOWSMキーストアに存在する必要があります。それぞれが異なる別名(たとえばServiceAおよびServiceB)を使用し、その別名を資格証明ストアに追加していることを確認します。サービスにポリシーをアタッチした場合、Webサービスが必要とする特定の別名を示すために構成オーバーライドを使用する必要があります。そうしない場合、ドメインに対して構成したデフォルトの別名が使用されます。

Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の資格証明ストアへのキーおよびユーザー資格証明の追加に関する項の手順では、これらの別名サンプルを資格証明ストアに追加する方法について説明しています。

また、信頼できるCA証明書を管理する方が格段に容易であるために、自己署名証明書ではなく内部CAまたは外部CAによって発行された信頼できる証明書を使用すべきです。ただし、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したSAMLの信頼できる発行者およびDNリストの構成に関する項の説明に従って、SAML署名者の信頼できるDNリストを必ず設定してくださいこれは、OWSMキーストアに外部CA証明書をインポートした場合に特に重要です。この設定を行わないと、証明書を持つユーザーなら誰でも、SAMLトークンに署名することによって、任意のユーザーになりすますことが可能になります。

2.7 OWSMでの資格証明ストアの使用の仕組みの理解

資格証明ストア・フレームワーク(CSF)は、Webサービスや他のアプリケーションの資格証明を格納、取得および削除する手段を提供します。

OWSMでは、次の情報を取得することにより、CSFを使用して保護された形式で資格証明を管理できます。

Javaキーストア内のキーの別名およびパスワード

OWSMでの資格証明ストアを使用した別名およびパスワードの検索の仕組みの詳細は、「OWSMでのJKSキーストア用のキーストアおよびキー・パスワードの特定の仕組み」を参照してください。
認証に使用されるユーザー名およびパスワード

たとえば、認証のためにユーザー名トークンを受け入れるWebサービスがあるとします。このWebサービスと対話するWebサービス・クライアントを作成した場合、Webサービスに送信できるユーザー名およびパスワードでWebサービス・クライアントを構成する必要があります。(Fusion Middleware ControlまたはWLSTのいずれかを使用して)資格証明ストアにこのユーザー名とパスワードを格納し、それにCSFキーを割り当てます。

たとえば、oracle/wss_username_token_client_policyポリシーにはcsf-keyプロパティが含まれており、そのデフォルト値はbasic.credentialsです。wss_username_token_client_policyを使用するには、資格証明名basic.credentialsと、クライアントが接続時に使用する必要があるユーザー名およびパスワードを使用して、CSF内に新しいパスワード資格証明を作成します。この同じクライアント・ポリシーを使用する2つのWebサービス・クライアントが存在する場合、これらのクライアントで同じパスワード資格証明(デフォルト値はbasic.credentials)を共有することもできますし、それぞれが独自の資格証明を持つこともできます。後者の場合は、クライアント1およびクライアント2についてそれぞれ、CSF内に2つのパスワード資格証明(たとえばApp1.credentials、App2.credentials)を作成する必要があります。クライアント1ではcsf-key構成オーバーライドにApp1.credentialsを設定し、クライアント2ではcsf-keyプロパティにApp2.credentialsを設定します。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のポリシー構成プロパティのオーバーライドに関する項を参照してください。いずれの場合も、ユーザー名およびパスワードがOPSSアイデンティティ・ストア内の有効なユーザーを表す必要があることに注意してください。

OPSS CSFには、ユーザー名とパスワードを格納できます。汎用的な資格証明はどのような資格証明オブジェクトも保存できます。

OPSS CSF構成は、domain-home/config/fmwconfigディレクトリのjps-config.xmlファイル内で維持されます。

Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したOWSMキーストアの構成に関する項の説明に従って、Fusion Middleware Controlを使用してOWSMキーストアを構成すると、指定した別名およびパスワードが資格証明ストアに安全に格納されます。しかし、キーストアに他の別名を追加する場合や、クライアントの認証資格証明を追加する必要がある場合は、資格証明ストアでそれらを構成して格納する必要があります。

2.8 セキュリティ・ポリシーの理解

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技術協議会のいくつかの実用セキュリティ・シナリオに貢献しています(OWSM 12cには、これらのシナリオのサブセットが付属しています)。各セキュリティ・シナリオは、WS-SecurityPolicyのポリシー表記を示します。

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

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

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

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

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

<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope xmlns:soap="...">
  <soap:Header>
    <wsse:Security soap:mustUnderstand="1" xmlns:wsse="...">
      <wsse:UsernameToken>
        <wsse:Username>Smith</wsse:Username>
        <wsse:Password Type="http://docs.oasis open.org...>
           Password
        </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は、ランダムに生成される(固有の)数字です。タイムスタンプは、セキュリティ・トークンの有効期間の定義に使用できます。

2.9 セキュリティ・トークンの概要

Web Services Security (WS-Security)は、XML暗号化により機密保護を、XML署名によりデータ整合性を実現するSOAPセキュリティ拡張機能を指定します。

WS-Securityには、タイプの異なるバイナリとXMLセキュリティ・トークンを、認証および認可の目的でWS-Securityヘッダーに挿入する方法を指定するプロファイルも含まれています。

2.9.1 セキュリティ・トークンの理解

次の項では、様々なWebサービス・セキュリティ・トークンについて説明します。

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

ユーザー名: Webサービス・コンシューマが、認証の資格証明としてユーザー名を指定する方法を定義します。詳細は、「ユーザー名トークンについて」を参照してください。
X.509証明書: 受信パーティに公開キーを送信するために設計された署名付きデータ構造。詳細は、「X.509証明書について」を参照してください。
Kerberosチケット: バイナリ認証およびセッション・トークン。詳細は、「Kerberosトークンについて」を参照してください。
Security Assertion Markup Language (SAML)アサーション: XMLドキュメントを使用して、インターネット上でセキュリティ情報を共有します。詳細は、「SAMLトークンについて」を参照してください。

2.9.2 ユーザー名トークンについて

ユーザー名トークンはBasic認証情報を伝達します。

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

2.9.3 X.509証明書について

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

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

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

2.9.4 Kerberosトークンについて

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

Kerberosでは次の用語が使用されます。

プリンシパルはユーザーのアイデンティティ(ユーザーにプリンシパルが割り当てられるということ)、またはKerberosサービスを提供するアプリケーションのアイデンティティです。
レルムはKerberosサーバー環境です。Kerberosレルムは、EXAMPLE.COM(表記規則により大文字で表現)などのドメイン名にすることもできます。

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

2.9.5 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は、標準のWebサービス・セキュリティ・フレームワーク(WS-Securityなど)で使用できる、標準のセキュリティ・トークン(SAMLアサーション)を備えています。これは、特にWebサービス・セキュリティに関連するSAMLの使用方法であり、OWSMで完全にサポートされています。
アイデンティティ伝播: SAMLには、ビジネス・プロセスまたはトランザクションの複数のステップで、ブラウザからポータル、Webサービスのネットワークへと渡すことができるセキュリティ・トークンを表現する標準の方法が用意されています。この機能もOWSMでサポートされています。

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によるリソースR(ファイル、アプリケーション、Webサービスなど)に対するアクションA(読取り、書込みなど)を証拠Eに基づいて許可するかどうかを決定する認証局によって発行されます。

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

2.10 セキュア・アタッチメントの理解

OWSMポリシーでは、添付ファイルを保護するための2つのメカニズムとして、添付ファイル付きのSOAPメッセージのパッケージ化(SwA)とメッセージ転送最適化メカニズム(MTOM)をサポートしています。

SOAPエンベロープ内に配置できないデータをアタッチメント(SwA)とともにSOAPメッセージをパッケージングすることは、標準的なことになってきています。プライマリSOAPメッセージでは、アタッチメントまたはMIMEヘッダー付きのアタッチメントとして追加のエンティティを参照できます。詳細は、Oracle Web Services ManagerによるWebサービスの保護およびポリシーの管理のSwAの添付ファイルの保護に関する項を参照してください

MTOMを使用すると、バイナリ・コンテンツをMIME添付ファイルとして送信できるため、ワイヤ書式の送信サイズを小さくできます。バイナリ・コンテンツは意味的にXMLドキュメントの一部です。MTOMポリシーをアタッチすると、メッセージはWebサービスやクライアントに送信される前にMIME添付ファイルに変換されます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のMTOMアタッチメント・ポリシーに関する項を参照してください。

2.11 セキュア通信の概要

OWSMはWeb Services Trust (WS-Trust 1.3)およびWeb Services Secure Conversation (WS-SecureConversation 1.3)仕様を実装します。これらはともにWebサービスとそのクライアント間のセキュアな通信を提供します。

次の各トピックでは、セキュア通信について説明します。

2.11.1 セキュア通信について

Web Services Secure Conversation Language (WS-SecureConversation)仕様では、セキュリティ・コンテキストまたは任意の資格証明の確立メカニズムと共有メカニズムや、確立されたセキュリティ・コンテキスト(または任意の共有の秘密)からのキーの導出メカニズムが定義されています。

Web Services Secure Conversation Language (WS-SecureConversation)の仕様(http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.doc)では、Web Services Security (WS-Security) 1.1と1.0、およびWeb Services Trust Language (WS-Trust)で構築された、1つ以上のメッセージでセキュア通信を可能にする拡張機能が定義されています。

OWSMには、WS-SecureConversationがデフォルトで有効なポリシーが含まれています。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のWS-SecureConversationをサポートしているポリシーに関する項を参照してください。事前定義済のWS-SecureConversationポリシーを使用することで、セキュリティ・タスクの概要表示と管理が簡素化される場合があります。

また、WS-SecureConversationをサポートしているポリシーに関する項で説明している各OWSMセキュリティ・ポリシーには、そのポリシーでのWS-SecureConversationの有効化と構成を可能にする構成設定が含まれています。

2.11.2 WS-SecureConversationの使用方法の概要

WS-SecureConversationは、特定のシナリオで使用されます。次の項では、WS-SecureConversationを使用する長所について説明します。

次の各トピックでは、WS-SecureConversationおよびWS-SecureConversationとWS-ReliableMessagingの組合せについて説明します。

2.11.2.1 WS-SecureConversationを使用する状況

WS-SecureConversationを使用する主な理由として、パフォーマンスとセキュリティがあります。

OWSMセキュリティ・ポリシーで採用している標準であるWS-Securityでは、メッセージ保護の基本メカニズムが提供されます。

しかし、WS-SecureConversationを使用しない場合、複数のメッセージをやりとりするOWSMセキュリティ・ポリシー(oracle/wss11_username_with_message_protectionなど)を使用するクライアントは、リクエストごとに繰り返し自身を認証し、キー交換などの負荷の高い非対称操作を実行する必要があります。

通常、複数のメッセージを安全にやりとりするためには、クライアントとWebサービスは、メッセージ交換のためのセキュリティ・コンテキストを必要とします。WS-SecureConversationでは、このようなコンテキストが提供されます。これによってハンドシェイク・プロセスが追加されます。Webサービスとそのクライアントは、このプロセスを通じて相互認証を実行して、共有セキュリティ・コンテキストを確立できるようになります。通信セッションの存続期間中は、このセキュリティ・コンテキストがクライアントとWebサービスによって共有されます。このコンテキストには共有の秘密が格納され、このキーを使用して、クライアントとサービス間の後続のメッセージが保護されます。複数のメッセージを交換する際には、キーを何度も交換しなくてもすむので、パフォーマンスを向上させることができます。

セキュア通信の有効化とは、キーを繰り返し交換したり、毎回認証する必要がないことを意味します。

次の順序を考えてみます。

クライアントが最初のリクエストを送信すると、クライアントとWebサービス間でハンドシェイクが実行されます。
クライアントは、WS-Trustプロトコルを使用したブートストラップ・ポリシーでの定義に従って、サービスに対して自身を認証します。
Webサービスは、セキュア・コンテキスト・トークン(SCT)を返します。SCTにはバイナリの秘密鍵が含まれており、後続のリクエストでこの秘密鍵を使用することで、通信セッション中のメッセージが保護されます。

注意:

Webサービスが要求する認証メカニズムは変わりません。認証操作の実行頻度のみが変わります。

2.11.2.2 WS-SecureConversationの長所

WS-SecureConversationを使用する長所の詳細は、Wss11、Wss10またはSSL OWSMポリシーの比較を参照してください。

WS-SecureConversationによる利点は、Wss11、Wss10またはSSL OWSMポリシーのどれを使用するかに応じて異なります。

Wss11: Wss11シナリオでは、ポリシーに応じて1つまたは2つの非対称暗号化操作がリクエストで実行されます。WS-SecureConversationを使用した場合、認証および非対称暗号化操作はブートストラップ時に1回のみ実行され、後続のアプリケーション・リクエストではSCTを使用してメッセージが保護されます。SCTでは、負荷が比較的かからない対称暗号化操作が使用されます。

たとえば、WS-SecureConversationで「メッセージ保護付きユーザー名」ポリシーが有効になっている場合、ブートストラップ・ポリシーによって、ユーザー名トークンを使用した認証と、Wss11を使用したメッセージ保護が行われます。しかし、後続のメッセージでは、認証はまったく実行されず、メッセージはSCTによって保護されます。
Wss10: Wss10シナリオでは、4つの非対称暗号化操作がリクエスト・メッセージおよびレスポンス・メッセージで実行されます。WS-SecureConversationを使用した場合、認証および非対称暗号化操作はブートストラップ時に1回のみ実行され、後続のアプリケーション・リクエストではSCTを使用してメッセージが保護されます。SCTでは、負荷が比較的かからない対称暗号化操作が使用されます。

たとえば、WS-SecureConversationで「メッセージ保護付きユーザー名」ポリシーが有効になっている場合、ブートストラップ・ポリシーによって、ユーザー名トークンを使用した認証と、Wss10を使用したメッセージ保護が行われます。しかし、後続のメッセージでは、認証はまったく実行されず、メッセージはSCTによって保護されます。
SSL: SSLシナリオでは、セッション期間中、通信はSSLを介して実行されます。ブートストラップ時には認証が実行されます。後続のリクエストでは、SCTを使用してタイムスタンプの署名が行われ、認証トークンはまったく送信されません。SCTに基づくタイムスタンプの署名によって、そのリクエストが認証済クライアントから送信されたものであることが証明されます。

これらのシナリオでは、SSLを使用してメッセージが保護され、SCTによるタイムスタンプの署名を使用して認証が実行されます。

たとえば、「SSLを介したユーザー名」ポリシーに対してWS-SecureConversationが有効になっている場合、ブートストラップ・ポリシーによって、ユーザー名トークンを使用した認証と、SSLを使用したメッセージ保護が行われます。SSLは後続のメッセージでも使用されますが、ユーザー名トークンのかわりに、SCTによるタイムスタンプの署名が格納されます。

2.11.2.3 WS-ReliableMessagingでのWS-SecureConversationの使用について

WS-SecureConversationの特に重要な用途の1つは、WS-ReliableMessaging (WS-RM)ポリシーに対してセキュリティを提供することです。セキュア通信を使用することにより、WS-RMでシーケンス攻撃を防止できるようになります。

WS-ReliableMessagingの仕様(http://docs.oasis-open.org/ws-rx/wsrm/v1.2/wsrm.html)で説明されているように、複数のメッセージ交換を行う場合は信頼できるメッセージ・シーケンスの使用が前提となるため、WS-TrustおよびWS-SecureConversationメカニズムを使用してシーケンスを保護することによって、セキュリティ・コンテキストを確立することをお薦めします。

そのため、WS-SecureConversationが有効になっているセキュリティ・ポリシーをWS-RMポリシーにアタッチしてください。

2.11.3 WS-SecureConversationのアーキテクチャ

WS-SecureConversation仕様は、Web Services Security (WS-Security)およびWeb Services Trust Language (WS-Trust)に基づく拡張を定義します。

仕様(http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.doc)には、WS-SecureConversationアーキテクチャ、特性および機能に関する情報のソースが最も含まれています。

最低でも、次の概念について精通しておく必要があります。

WS-Trust: Oracle WebLogic Server WebLogic Webサービスの理解のWeb Services Trust Language (WS-Trust)に関する項で説明しているように、Web Services Trust Language (WS-Trust)の仕様では、Web Services Security (WS-Security) 1.1と1.0で構築された、セキュリティ・トークンのリクエストおよび発行と、信頼関係の仲介のためのフレームワークを提供する拡張機能が定義されています。
セキュリティ・コンテキスト: セキュリティ・コンテキストは、確立された認証状態とネゴシエートされたキーを指す抽象概念です。セキュリティに関連するその他のプロパティを持つ場合もあります。
セキュリティ・コンテキスト・トークン: セキュリティ・コンテキスト・トークン(SCT)は、セキュリティ・コンテキスト抽象概念の表現です。SCTにより、URIに基づく名前をコンテキストに付けて、WS-Securityで使用できるようになります。コンテキストと秘密の確立(認証)が完了すると、セキュアなコンテキストで各キーを使用するたびに導出キーを計算できます。
導出キー: WS-SecureConversationの仕様(http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.doc)には、次のように記載されています。「セキュリティ・コンテキスト・トークンは、共有の秘密を暗示または含有します。この秘密は、メッセージの署名または暗号化(あるいはその両方)で使用可能ですが、導出キーは、セキュリティ・コンテキストにのみ関連付けられたメッセージの署名と暗号化に使用することをお薦めします。」

さらに、WS-SecureConversationの仕様には、次のように記載されています。「コンテキストと秘密の確立(認証)が完了すると、セキュアなコンテキストでキーが使用されるたびに、導出キーに関する項で説明しているメカニズムを使用して導出キーを計算できます。」

導出キーはメッセージの保護に役立ちます。複数のリクエストで同じSCTを使用するかわりに、リクエストごとに異なるSCT導出キーを使用することで、全体的なセキュリティが強化されます。

ポリシーでWS-SecureConversationを有効にすると、OWSMは、WSS10およびWSS11に対して、デフォルトで導出キーを使用します。(SSLポリシーの場合は、SSLを使用してメッセージが保護されるため、導出キーは不要です。)
セッション管理: OWSMは、計算されたセッションIDに基づいて、クライアントとサーバーのセキュア通信セッション情報を保持します。

Webサーバー側では、Webサービスの使用ポートに基づいてセッションIDが保持されます。

クライアント・セッションは、「参照」という用語で表現されます。これは、メッセージ通信を有効にするクライアント・ポート/バインディングやとSOA参照と類似する概念です。

WS-SecureConversationの実装では、各クライアント参照は個別のWS-SecureConversationセッションになります。Webサービス・クライアント・リクエストの観点では、これを前提として、次のことが導かれます。
- 複数のリクエストが同じ参照に属する場合がある。
- 同じセッションIDを持つリクエストはすべて、同じセッションに属する。
- セッションIDが有効となる状態は、再認証設定に依存する。
OWSMは実行時にメッセージごとにセッションIDを計算し、1つのセッションに1つ以上のリクエストを関連付けます。OWSMは、ユーザーの資格証明、サービス情報、ポリシー・データおよび構成データを使用して、セッションIDを計算します。

セッションIDは、Oracle WS-RMポリシーで使用されたときに特に重要になります。このポリシーでは、セキュリティとパフォーマンス上の理由から、RMセッション内の複数のメッセージが同じセキュア通信セッションで保護されます。
内部ポリシーと外部ポリシー: OWSMにおけるWS-SecureConversation実装では、セキュア通信ポリシーには、実際には内部と外部の2種類のポリシーが含まれます。ブートストラップ(内部)ポリシーは、トークンの取得と、クライアントとWebサービス間のハンドシェイクの確立に使用されます。外部ポリシーは、トークンを使用したリクエストの実行時にアプリケーション・メッセージに対して使用されます。

wss11_username_with_message_protectionなどの元のOWSM WS-Securityポリシーから、外部ポリシーのメッセージ・セキュリティ設定が取得されます。その後、外部ポリシーから、内部ポリシーのメッセージ・セキュリティ設定が導出されます。

ほとんどの場合、内部および外部ポリシーはOWSMによって処理されるため、これらのポリシーの詳細を意識する必要はありません。ただし、OWSMのWS-SecureConversation実装では、追加制御のための詳細設定を指定することもできます。「ブートストラップ・モードの設定について」を参照してください。
再認証: OWSMには、ユーザーごとに個別にセッションを作成するか、複数のユーザーが同じセッションを共有できるようにするかを指定する再認証制御機能があります。再認証がtrueに設定されているかどうかにかかわらず、ユーザーの認証は1回のみ実行されます。

サポートしているユースケースの1つに、SAML送信者保証付きのID伝播があります。これは、アプリケーション・メッセージごとにユーザーIDが異なる場合があるために、WS-SecureConversationセッション中にメッセージごとに認証を実行する必要があるユースケースです。

再認証によって、複数のユーザーが同じセッションを共有できるようになります。この場合、複数のユーザーがセッションを共有するため、リクエストごとに認証トークンが送信されます。ただし、後続のリクエストでは、キーを交換する必要はなく、非対称操作(署名、暗号化)は実行されません。

セッションIDが有効となる状態は、再認証設定に依存します。
- 再認証がfalseに設定されている場合、クライアント側では、特定のユーザーの単一の参照に対してセッションIDが保持されます。
  
  サーバー側では、Webサービスの使用ポートに基づいてセッションIDが保持されます。
- 再認証がtrueに設定されている場合、クライアント側では、単一の参照に対してセッションIDが保持されます。この参照には、複数のユーザーが関係している場合があります。
  
  サーバー側では、Webサービスの使用ポートに基づいてセッションIDが保持されます。

2.11.4 WS-SecureConversationを使用する状況

OWSMでは、WS-SecureConversationは特定のシナリオで使用されます。

次のシナリオでは、WS-SecureConversationの使用を検討してください。

OWSM WS-RMポリシーを使用している。
OWSMセキュリティ・ポリシー(oracle/wss11_username_with_message_protectionなど)を使用してWebサービス・クライアントを保護しており、複数のメッセージが頻繁にやりとりされる。

WS-SecureConversationの有効化が有意義なのは、Webサービス・クライアントまたはサービスがOWSMで保護されており、このクライアントまたはサービスで複数のメッセージ交換が行われることが想定される場合です。WS-SecureConversationを有効化することで、パフォーマンスが向上します。クライアントとサービス間の後続のメッセージがSCTによって保護されるため、認証操作と公開キー暗号化操作を繰り返し実行するオーバーヘッドが発生しないからです。

注意:

ID伝播ユースケースでは、WS-SecureConversationを使用することによって、主にメッセージ保護におけるパフォーマンスが向上します。セッション中にメッセージごとに認証トークンを送信した場合、その分パフォーマンスが犠牲になるからです。

複数のメッセージ交換が行われることがあり、WS-SecureConversationが役立つ可能性がある次のシナリオについて考えてみてください。

1対1: この場合、クライアント・アプリケーションが、単一ユーザーのために、特定のWebサービスを複数回起動します。
re-authenticate=trueを設定した1対1(アイデンティティ伝播): この場合、クライアント・アプリケーションが特定のWebサービスを複数回起動します。ただし、後続のリクエストでは、リクエストごとに異なるアイデンティティをWebサービスに渡す必要がある場合があります。

すべてのユーザー用に単一のセキュア通信セッションが作成されます。

2.11.5 再認証を使用する状況

SAML送信者保証付きID伝播ポリシーの場合にのみ、再認証制御を有効化できます。

再認証は、アプリケーション・メッセージごとにユーザーIDが異なる可能性があるときに使用します。この場合、各メッセージでユーザーが認証されます。

クライアント・アイデンティティを使用してブートストラップが実行され、サービスへのすべてのアプリケーション・リクエストでエンド・ユーザー・アイデンティティが渡されます。WS-SecureConversationを使用することによって、主にメッセージ保護における利点が得られます。セッション中にメッセージごとに認証トークンを送信した場合、その分パフォーマンスが犠牲になるからです。

デフォルトでは、WS-SecureConversationでの再認証制御は設定されていません。再認証制御は、WS-SecureConversationが有効化されている場合にのみ有効化できます。

2.11.6 ブートストラップ・モードの設定について

OWSMにおけるWS-SecureConversation実装では、セキュア通信ポリシーには、実際にはブートストラップ(内部)と外部の2種類のポリシーが含まれます。

ブートストラップ(内部)ポリシーは、トークンの取得と、クライアントとWebサービス間のハンドシェイクの確立に使用されます。外部ポリシーは、トークンを使用したリクエストの実行時にアプリケーション・メッセージに対して使用されます。

外部ポリシーのメッセージ・セキュリティ設定は、oracle/wss11_username_with_message_protectionなどの元のOWSM WS-Securityポリシーから取得されます。その後、外部ポリシーから、内部ポリシーのメッセージ・セキュリティ設定が導出されます。

したがって、ほとんどの場合、内部および外部ポリシーはOWSMによって処理されるため、これらのポリシーの詳細を意識する必要はありません。ただし、OWSM WS-SecureConversationの実装では、追加のコントロールが提供されます。

次の「ブートストラップ・メッセージ・セキュリティ」オプションを使用できます。

アプリケーション設定から継承
独立した設定を使用:
- アルゴリズム・スイート
- タイムスタンプを含める
- 署名の確認
- 署名の暗号化

2.11.7 永続性の概要

次の2つの永続性の実装が使用できます。デフォルトのドメイン全体の永続性およびクライアント固有/Webサービス固有の永続性です。

この項では、前述の次のような永続性の実装について説明します。

2.11.7.1 デフォルトのドメイン全体の永続性の実装について

OWSMには、Coherenceクラスタとメモリー内永続性プロバイダをサポートする、デフォルトのドメイン全体の永続性の実装が含まれています。

Coherence永続性プロバイダがWebLogic Serverで実行されている場合は、このプロバイダが、Webサービス・クライアントとWebサービスの両方に対してデフォルトになります。それ以外の場合は、メモリー内プロバイダがデフォルトになります。

セッション・リカバリの永続性粒度レベルは、セッション・オブジェクトです。

この永続性の実装は、デフォルトで有効になっており、構成を行う必要はまったくありません。

2.11.7.2 クライアント固有およびWebサービス固有の永続性の実装について

各クライアントおよびWebサービスでは、1つ以上(ポートごとに1つ)の永続性プロバイダを指定できます。Coherenceプロバイダまたはメモリー内プロバイダのいずれかの指定が可能です。

この指定を行うには、「永続性の構成」で説明しているいずれかのメカニズムを使用します。

2.12 Kerberosプロトコルの概要

Kerberosは、非セキュア・ネットワークを介して通信するコンピュータ(クライアントおよびサーバー)が、信頼できる第三者を利用して、互いに自身のアイデンティティを安全な方法で証明できるようにする認証プロトコルです。

次の各トピックでは、Kerberosプロトコルについて詳しく説明します。

2.12.1 Kerberosプロトコルの理解

Kerberosでは、この信頼できる第三者は、キー配布センター(KDC)です。KDCには、プリンシパルと呼ばれる、クライアントとサーバーのキー情報が格納されます。

KDCは次の2つのコンポーネントで構成されます。

認証(AS): KDCでプリンシパルを認証します。
チケット認可サービス(TGS): 認証されたプリンシパルに、KDC内の他のプリンシパルにサービスをリクエストするために使用できるチケットを提供します。

OWSMでは、KDCとしてMIT KerberosとMicrosoft Active Directoryをサポートしています。MIT Kerberosの使用の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のMIT Kerberosの使用に関する項を参照してください。Microsoft Active Directoryの使用の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のキー配布センターでのMicrosoft Active Directoryの使用に関する項を参照してください。

クライアント・プリンシパルとサーバー・プリンシパル間のメッセージ・セキュリティにKerberosが使用されているときに実行されるステップの概要は次のとおりです。

AS-REQ(認証サービスへのリクエスト): クライアントが、ASにユーザーIDを送信することによって、認証プロセスを開始します。
AS-REP(認証サービスからの返信): ASはレスポンスとして次のものを返します。
- KDCからのユーザーのパスワードのハッシュを使用して暗号化されたクライアント/TGSセッション・キー
- TGSの秘密キーを使用して暗号化されたチケット認可チケット(TGT)
TGS-REQ(チケット認可サービスへのリクエスト): サービスとの通信を開始するために、クライアントは最初に次のものをTGSに送信します。
- ASから受信したTGT
- リクエストしたサービスのID
- ASからのクライアント/TGSセッション・キーを使用して暗号化されたオーセンティケータ
TGS-REP(チケット認可サービスからの返信): TGSは、秘密キーを使用してTGTを復号化し、そこからクライアント/TGSセッション・キーを抽出します。次に、このセッション・キーを使用して、オーセンティケータを復号化します。その後、レスポンスとして次のものを返します。
- クライアント/TGSセッション・キーを使用して暗号化されたクライアント/サーバー・セッション・キー
- サービスの秘密キーを使用して暗号化されたサービス・チケット(ST)
AP-REQ(アプリケーションへのリクエスト): クライアントは、TGSからの返信を受信すると、次のものを送信して、サービスとの通信を開始します。
- TGSから受信したST
- TGSからのクライアント/サーバー・セッション・キーを使用して暗号化された新しいオーセンティケータ
AP-REP(アプリケーションからの返信): サービスは秘密キーを使用してSTを復号化し、クライアント/サーバー・セッション・キーを抽出します。次に、このセッション・キーを使用してオーセンティケータを復号化します。その後、復号化されたオーセンティケータからタイムスタンプを抽出し、それに新しいタイムスタンプを追加します。そして、クライアント/サーバー・セッション・キーを使用してこの値を暗号化して、クライアントに返送します。
クライアントは確認を復号化し、タイムスタンプが適切に更新されているかどうかをチェックします。更新されている場合、クライアントはサーバーを信頼し、サービス・リクエストの発行を開始できます。

KerberosプロトコルをサポートするようにOWSMを構成する方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のKerberosログイン・モジュールの構成に関する項およびKerberosトークンの構成に関する項を参照してください。

2.12.2 Kerberosでの資格証明の委任の理解

Kerberosは、サービスが別のサービスまたはサーバーにアクセスしてクライアント・リクエストを完了する必要がある場合、資格証明委任のメカニズムを使用します。Kerberosでは、このような接続を確立するために、クライアントのユーザー・アカウントと認可レベルを使用して、2番目のサービスまたはサーバーに対して最初のサービスを認証する必要があります。

Kerberosで資格証明の委任を行う一般的な方法は、KerberosチケットでFORWARDABLEおよびFORWARDEDフラグを使用することです。これは転送されたTGTと呼ばれる方法です。転送されたTGTの使用に関連するステップの概要を次に示します。

ユーザーが、最初のAS-REQで、FORWARDABLEというKDCオプションを設定することによって、forwardableフラグが設定されたTGT(転送可能TGT)をKDCにリクエストします。
クライアントが、この転送可能TGTをTGSに提示することによって、FORWARDEDチケットをリクエストします。クライアントはまた、新しいチケットのサービス・アドレス・セットを提供するとともに、FORWARDEDというKDCオプションをリクエスト(TGS_REQ)に設定します。
ステップ2で取得したFORWARDEDチケットを提供することによって、このようなチケット(FORWARDEDフラグが設定されたチケット)をKDCからさらに取得できます。

次に、より詳細なステップでメッセージの順序を指定します。

ユーザーが、KRB_AS_REQメッセージを送信することによってKDCに対して認証を行い、転送可能TGTをリクエストします。
KDCから、KRB_AS_REPメッセージで転送可能TGTが返されます。
ユーザーは、ステップ2で取得した転送可能TGTに基づいて、転送されたTGTをリクエストします。これはKRB_TGS_REQメッセージで行われます。
KDCから、KRB_TGS_REPメッセージで、転送されたTGTがユーザーに対して返されます。
5. ユーザーは、ステップ2で返されたTGTを使用して、サービス1のサービス・チケットをリクエストします。これはKRB_TGS_REQメッセージで行われます。
チケット認可サービス(TGS)から、KRB_TGS_REPメッセージでサービス・チケットが返されます。
ユーザーは、KRB_AP_REQメッセージを送信し、サービス・チケット、転送されたTGTおよび転送されたTGTのセッション・キーを提示することによって、サービス1に対するリクエストを行います。
ユーザーのリクエストを満たすために、サービス1はサービス2を起動して、ユーザーにかわってなんらかのアクションを実行する必要があります。サービス1は、ユーザーの転送されたTGTを使用し、KRB_TGS_REQメッセージでこのTGTをKDCに送信することによって、ユーザーにかわってサービス2のチケットを要求します。
KDCから、KRB_TGS_REPメッセージで、サービス2のチケットがサービス1に返されます。また、サービス1が使用可能なセッション・キーも一緒に返されます。このチケットでは、サービス1ではなくユーザーがクライアントとして指定されています。
サービス1は、KRB_AP_REQを使用して、ユーザーにかわってサービス2に対するリクエストを行います。
サービス2によってタスクが実行され、レスポンスが返されます。
サービス2から取得したレスポンスが、ユーザーのリクエストへのレスポンスとして、サービス1からユーザーに返されます。

資格証明の委任を使用するためのOWSMの構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の資格証明の委任の構成に関する項を参照してください。

2.12.3 KerberosとSPNEGOの理解

SPNEGO (Simple and Protected GSS-API Negotiation Mechanism)は、クライアントとサービスが認証に使用する方法をネゴシエートすることを可能にする標準です。SPNEGOではネゴシエーションを実行するためにHTTPヘッダーを使用するので、HTTPを使用するSOAPおよびRESTのエンドポイントが一般的であるWebなどのクロス・プラットフォームのコンテキストで特に役立ちます。

SPNEGOネゴシエーションでKerberosが使用される場合、KerberosトークンはHTTPヘッダーのauth-scheme Negotiateの下でラップされます。次のようにして、クライアントとサービス間でSPNEGOトークンの通信のために、WWW-AuthenticateおよびAuthorizationヘッダーが使用されます。

クライアント・リクエストが、Authorizationヘッダーなしで、サーバーの保護されたサービスにアクセスします。
リクエストにはAuthorizationヘッダーがないので、サーバーはレスポンスとして、ステータス・コード401(未認可)と、Negotiateに設定されたWWW-Authenticateヘッダーを返します。
クライアントは、Kerberosトークンを取得するためにユーザー資格証明を使用し、新しいリクエストのAuthorizationヘッダーでサーバーにそのトークンを送信します。たとえば、Authorization: Negotiate a87421000000492aa874209....のようになります。
サーバーはAuthorizationヘッダーのトークンをデコードします。コンテキストが完了していない場合(相互認証の場合など)、サーバーはレスポンスとして、ステータス・コード401と、デコードされたデータを含むWWW-Authenticateヘッダーを返します。たとえば、WWW-Authenticate: Negotiate 74900a2a....のようになります。
クライアントはこのデータをデコードし、新しいデータをサーバーに返信します。セキュリティ・コンテキストが確立されるまで、このサイクルが続行されます。

SPNEGOでKerberosを使用するためのOWSMの構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のSPNEGOネゴシエーションでのKerberosの構成に関する項を参照してください。

2.12.4 KerberosとWS-SecureConversationの導出キーについて

Web Services Secure Conversation (WS-SecureConversation)の仕様には、導出キーと呼ばれる機能が含まれています。この機能では、相互に認証済の二者が、共通の秘密を使用して、メッセージの署名や暗号化などの様々な用途で追加のキーを導出できます。

また、WS-SecureConversationの仕様では、次の2つのタイプの導出キーが定義されています。

明示的な導出キー: wsc:DerivedKeyToken要素を使用して、トークン情報が格納されます。そして、この情報の参照がds:KeyInfo要素に格納されます。
暗黙的な導出キー: ds:KeyInfo要素にトークン情報が直接格納されます。

WS-SecureConversationのコンテキストでKerberosを使用する場合は、Kerberosに関するOWSMアサーションで「導出キーの使用」オプションを有効化することによって、導入キーを使用するようにOWSMを構成できます。

2.13 Web Services Addressingの理解

Web Services Addressing (WS-Addressing)仕様は、Webサービスおよびメッセージのアドレッシングを行うための、トランスポートに依存しないメカニズムを提供します。

特に、この仕様(http://www.w3.org/TR/ws-addr-core/)では、Webサービスのエンドポイントを識別したり、メッセージ内のエンドポイントIDをエンド・ツー・エンドで保護したりするのに使用される多数のXML要素が定義されています。

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

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

次の例は、WS-Addressingを使用したものです(wsaは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-*仕様と組み合せて使用できます。

2.14 Webサービス信頼性の理解

WS-Trust 1.3仕様は、セキュリティ・トークンのリクエストおよび発行を行う際の枠組みを提供するWS-Securityへの拡張機能と、ブローカ・トラスト関係への拡張機能を定義します。WS-Trust拡張機能は、セキュリティ・トークンの発行、更新および検証を行う方法を提供しています。

Webサービス・クライアントとWebサービスとの間の通信を保護するには、両者がセキュリティ資格証明を交換する必要があります。WS-Trust仕様(http://docs.oasis-open.org/ws-sx/ws-trust/v1.3/ws-trust.html)で定義されているように、これらの資格証明は、信頼ブローカとして機能するセキュリティ・トークン・サービス(STS)から取得できます。

STSの使用を検討したほうがよいシナリオの例を次に示します。

トークンの交換/変換: ある種類のトークンを別のタイプのトークンに交換する必要がある場合を想定してください。たとえば、クライアントが保持しているトークンがKerberosトークンであるときに、WebサービスからはSAMLトークンを要求されている場合があります。STSを使用することで、KerberosトークンをSAMLトークンに交換できます。
フェデレーション: アイデンティティ・フェデレーションを使用して、ユーザーは複数のサービス・プロバイダで構成した多数のローカル・アイデンティティを統合できます。フェデレーテッド・アイデンティティを使用することで、個々のユーザーは1つのサービス・プロバイダ・サイトにログインした後、再認証もアイデンティティの再確立も行うことなく、関連するサービス・プロバイダ・サイトに移動できます。

たとえば、STSを使用して、クライアント・ユーザー名を、Webサービスによって要求されるユーザー名にマップできます。
信頼の集中化: STSはWebサービス・クライアントとWebサービスの両方から信頼されます。この信頼を使用して、相互運用可能なセキュリティ・トークンを提供します。

図2-2に示すトークン交換シナリオについて、考えてみてください。このシナリオでは、カスタマのデスクトップ・アプリケーション(.NET Webサービスなど)が、SAMLトークンを受け入れることができるバックエンドのWebサービスと通信します。

図2-2 STSトークンの交換

「図2-2 STSトークンの交換」の説明

図2-2では、joeというユーザーがデスクトップにログインし、Kerberosチケットが作成されます。ユーザーがデスクトップ・アプリケーションを開いて操作を実行すると、バックエンドのWebサービスがコールされます。この場合、joeというアイデンティティをバックエンドのアプリケーションに伝播させる必要があります。しかし、クライアント側にあるのはKerberosトークンであり、バックエンドのWebサービスはSAMLトークンしか受け入れません。STSを使用することで、トークンの変換または交換を実行できます。

KerberosプロトコルをサポートするようにOWSMを構成する方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のWS-Trustの構成に関する項を参照してください。

2.15 Webサービスの信頼性のあるメッセージングの理解

WS-ReliableMessagingによって、信頼性のあるメッセージ交換が行われます。ソフトウェア・コンポーネント、システムまたはネットワークの障害に関係なく、分散アプリケーション間でメッセージの信頼性のある配信が確実に行われる必要があります。順序付き配信が保証されているため、クライアント・アプリケーションごとに、失敗したメッセージの自動再送信をコーディングする必要はありません。

Webサービスで次の問題が発生している場合は、信頼できるメッセージングの使用を検討してください。

ネットワーク障害や接続の切断
メッセージの転送中の消失
メッセージの順不同での宛先への到着

WS-ReliableMessagingでは、メッセージの送信元と宛先はクライアント・サーバー・モデルに依存しないものとみなされます。つまり、クライアントとサーバーはそれぞれ、通信パスでメッセージの送信元および宛先の両方として同時に機能できます。

WS-ReliableMessaging (WS-RM)の詳細は、Oracle Infrastructure Webサービスの開発の Webサービスの信頼性のあるメッセージングの使用に関する項を参照してください。

2.16 Oracle Entitlements Serverを使用したファイングレイン認可の概要

Oracle Entitlements Server (OES)は、エンタープライズ全体のアプリケーションとサービスを保護するために使用できるファイングレイン認可サービスです。これは、複雑なアプリケーション権限の一元化した定義、およびこれらの権限の実行時における分散化された施行をサポートしています。OESを使用すると権限を外部化できるため、アプリケーションからセキュリティ決定の必要性を排除します。

OWSM OES統合はOESを使用した高度な認可のユースケースをサポートしており、次の機能が用意されています。

OES認可をSOAPベースのWebサービスに適用できます。OES認可ポリシーでは、あるサブジェクトが、指定されたリソースに対して特定のアクションを実行するための権限が付与または拒否されます
OESでは、付与/拒否に関する決定がコンテキスト属性に基づいて行われます。コンテキスト属性は、XPath文を使用して抽出したSOAPリクエスト・メッセージからの情報、またはHTTPヘッダーに基づいたものにすることができます。
データ・マスキング。OWSM OESでは、Webサービスのリクエストに対するレスポンスで特定の情報を(任意の文字を使用して)マスクできます。

この項では、Oracle Entitlements Server (OES)をOWSMに統合する方法、およびファイングレイン認可でOESをOWSMと一緒に使用する方法について説明します。

構成については、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のOracle Entitlements Serverを使用したファイングレイン認可の構成に関する項を参照してください。

2.16.1 OESドキュメントへの参照

この項では、多くのOESの概念と機能について言及しています。この項の焦点はOWSMとの統合であり、OESの概念を詳細に説明するものではありません。

OESをまだよく理解していない場合は、まず『Oracle Entitlements Server管理者ガイド』およびきめ細やかな認可: Oracle Entitlements Serverを使用するための技術的洞察を参照する必要があります。

注意:

OWSMは、バージョン11.1.2.2.0以降のOESをサポートしています。

2.16.2 OES統合の概要

OWSMとOESを統合できます。OWSMエージェントは、OESで定義されているポリシーに基づいて保護されているWebサービスの認可を確認し、認証されたサブジェクトおよびその他の属性をOESに渡します。

OWSMとOESを統合する場合は、次の操作を実行します。

OWSM認証ポリシーをWebサービスにアタッチします。
この項の説明に従って、OWSM oracle/binding_oes_authorization_policyポリシーまたはoracle/component_oes_authorization_policyポリシーを単体で、またはoracle/binding_oes_masking_policyポリシーと組み合せてアタッチします。
OESコンソールを使用して認可ポリシーとデータ・マスキング・ポリシーを作成します。通常は「責任」に対して別個のポリシーを設定します。

注意:

OWSMでは、OES関連の構成が公開されていません。そのため、ここではOESコンソールを使用します。

詳細は、次のトピックを参照してください。

2.16.2.1 OES統合: 全体像

OWSMエージェントは、OES内で定義されているポリシーに基づいて、保護されているWebサービスについてSOAPリクエストの認可をチェックします。そのために、OWSMはOESに、認証済サブジェクト、ターゲット・リソース、リクエストされたアクション、および認可リクエストで常に渡される一連の暗黙属性を渡します。

OESポリシーでは、SOAPリクエスト、HTTPヘッダー、メッセージ・コンテキストのプロパティからのコンテキスト属性、またはサブジェクト、ロール、グループなどのアイデンティティ情報に基づいて追加の必須値を定義できます。許可または拒否の決定を行うために、これらのコンテキスト属性がさらに必要なことをOESで構成した場合は、それらのコンテキスト属性もOWSMによって渡されます。　

具体的には、OESに対して認可の決定を問い合せるための2つの方法があります(2ステップの方法と、1ステップの方法)。これらのどちらを選択するかは、oracle/binding_oes_authorization_policyおよびoracle/component_oes_authorization_policy内のuse.single.step属性を指定することによって決定します。

これらのメソッドは、次のように機能します。

2ステップのプロセスでは、OESコンソールでファイングレイン認可に必要な属性を事前に識別している必要があります。その後、OWSMでそれらの属性を使用します。

OWSMはまずOESをコールして必要な属性を割り出し、リクエスト・ペイロードから属性を取得した後、OESを再度コールしてOES認可ポリシーを使用して実際の認可を実行します。これは、実際には2つのOESポリシー(必要な属性を取得するためのポリシーと認可自体のポリシー)を定義していることを意味します。

常に渡される暗黙属性、および時間、日付などのOESの定義済属性も使用できます。

この方法は、「OESのファイングレイン認可および大まかな認可」で説明されているように、ファイングレイン認可に使用されます。
1ステップのプロセスでは、OWSMがOESに1回のみコールして、OES認可ポリシーを使用して認可を実行します。1ステップのプロセスでは、属性を事前に識別しておく必要ありません。2ステップのプロセスと同様に、常に渡される暗黙属性、および時間、日付などのOESの定義済属性も使用できます。

この方法は、「OESのファイングレイン認可および大まかな認可」で説明されているように、大まかな認可に使用できます。

2.16.2.2 データ・マスキング

OWSMをOESと統合すると、Webサービス・コードを変更せずにWebサービスからのレスポンスにある特定の情報を(アスタリスクで)マスクできます。

Webサービスのクライアント・リクエストに対するレスポンスで、機密データがネットワーク経由で渡されないようにすると仮定します。OESコンソールをoracle/binding_oes_masking_policyポリシーとともに使用して、図2-3に示すように、Webサービスからの機密データ(社会保障番号、会計情報など)をアスタリスクに置換します。

図2-3 機密データのマスキング

「図2-3 機密データのマスキング」の説明

機密データのマスキングは、それを求める人、およびリクエストに存在するその他のコンテキスト属性に応じて実行されます。

図2-3に示すWebサービス・レスポンスに対する次のコードの流れについて、考えてみてください。

データ・マスキング・コード・フローの理解

Webサービス・クライアントがリクエストを送信します。
インバウンド・リクエストで、OWSMはリクエスト・ポリシーを施行し、ユーザーBob Doeの適切な認証と認可を実行します。
リクエストが許可されると、OWSMはペイロードをサービス・プロバイダに渡します。サービス・プロバイダはペイロードを操作し、コール元に返信するレスポンスを準備します。
レスポンス処理の際には、OWSMがoracle/binding_oes_masking_policyポリシーを起動してマスキングが必要な機密データがあるかどうかを判断します。

OWSMは、コール元の情報とレスポンス・ペイロードから抽出した任意のユーザー定義の属性を渡します。
OESで定義されたデータ・マスキングのルールは、(トランスポート属性を介した)クライアント情報、現在のサブジェクト、リソース、アクション、およびそのポリシーで構成されている任意のレスポンス属性を考慮します。
各ペイロード属性について、OESは、「XACML責任について」に従い、その属性をそのまま渡すか、マスキングするかを指定します。
OWSMは、OESが返すXACML責任についてを受け付け、OESによって機密データとマークされている属性はマスキングします。

2.16.2.3 XACML責任について

OESでは、XACMLの概念である責任の機能がサポートされています。『Oracle Fusion Middleware Oracle Entitlements Serverの管理』の「ポリシー・モデルの理解」で説明されているように、ポリシーで責任を使用することで、ポリシー施行コンポーネントに対して追加要件を要求することができます。

責任はOESコンソールで構成します。責任とは、コール元(OWSM)に返される任意の属性名/値のペア(またはその他の単純な名前/値のペア)のことです。OWSMとOESの統合の場合、責任になり得るのは、XPath問合せ、HTTPトランスポート・ヘッダー・プロパティまたはメッセージ・コンテキスト・プロパティです。

責任のもう1つの用途はデータ・マスキングです。データ・セキュリティのユースケースなどの一部のアプリケーションでは、「はい」または「いいえ」のような簡単な回答では不十分で、図2-3に示されているように、どのデータをどのような値でマスキングするかを指定する責任がOES認可ポリシーによって返される場合があります。

2.16.2.4 OESのファイングレイン認可および大まかな認可の概要

OWSM OESポリシーを使用して認可を実行するための2つの方法があります(ファイングレイン認可および大まかな認可)。認可タイプについては、次の各トピックで定義します。

2.16.2.4.1 OESファイングレイン(責任)

コンシューマのアイデンティティ、および責任内で指定されているトランスポート・ヘッダーまたはペイロードの特定のコンテンツに基づいてリソースへのアクセスを判断します。　これが一般的なユースケースです。

このユースケースでは、OESアクセス・ポリシーで属性を定義します。OWSMは、この属性をリクエストから抽出し、認可時にはこれをOESに返します。つまり、OESアクセス・ポリシーは、アイデンティティ属性とリクエスト・ペイロードから抽出された属性の組合せに基づいています。

たとえば、「SOAP本文に特定の顧客IDが含まれている場合、および認証済ユーザーがTrustedPartnersグループに属している場合にアクセスを許可する」というOESのアクセス権チェックを実行できます。

図2-4に、ファイングレイン認可のユースケースを示します。

図2-4 ファイングレイン認可

「図2-4 ファイングレイン認可」の説明

図2-4に示すWebサービス・レスポンスに対する次のコードの流れについて、考えてみてください。

Webサービス・クライアントがSOAPリクエストを送信します。
このWebサービスは、OWSM認証ポリシーとOWSM OES認可ポリシーで保護されています。
OWSMが認証を実行し、認可のためにOESを起動します。
OWSMには、サブジェクト、リソース、参照アクション、およびOESに対するすべての定義済プロパティが用意されています。
OESは、保護されたリソースに構成されている参照アクションをコールし、構成済の責任(ある場合)でOWSMに応答します。責任は、アクションに基づいて返される可能性があります。各アクションでは、異なるXPathsなどを定義できます。
OWSMは、責任を評価してSOAP/XMLペイロードでXPathを実行するか、トランスポート・ヘッダーまたはメッセージ・コンテキストからプロパティ値を検出します。
OWSMは、サブジェクト、リソース、アクションのほかに、ステップ6で評価したすべての属性をOESに再提供します。
OESは、サブジェクト、リソース、アクションおよび属性に基づいてアクセスを決定します。
OESは、許可または拒否で応答します。
許可された場合、OWSMがサービス・プロバイダにメッセージを渡します。
拒否された場合、OWSMがリクエストを却下し、認証の失敗が示されます。

2.16.2.4.2 SAMLのファイングレイン

コンシューマのアイデンティティ、およびSAMLトークンで渡された属性に基づいてリソースへのアクセスを決定します。(SAML属性の引渡しについては、Oracle Web Services ManagerによるWebサービスの保護およびポリシーの管理のuser.attributesおよびuser.roles.includeを参照してください。)

OWSMは、SAMLアサーションから属性を渡します。SAML属性は、常に抽出されて(存在する場合)自動的に送信される暗黙属性の一部です。この属性名は、SAMLアサーション内の属性名で、値は文字列のリストです。OESでは、これらのSAML属性に加え、サブジェクト、リソース、アクションに基づいてアクセスを決定できます。

このユースケースには、2つの実装方法があります。最初の方法では、OESカスタム属性リトリーバを作成します。『Oracle Fusion Middleware Oracle Entitlements Server開発者ガイド』のカスタム属性リトリーバの作成に関する項を参照してください。2つ目の方法では、責任をSAML属性値を指すXPathと一緒に使用してOESを応答させます。

OESカスタム属性リトリーバを使用する方法に関する、次のコードの流れについて考えてみてください。

Webサービス・クライアントは、SOAPリクエストに属性文が指定されているSAMLトークンを送信します。
このWebサービスは、oracle/wss10_saml_token_service_policyおよびOWSM OES認可ポリシーで保護されています。
OWSMが認証を実行し、AttributeStatementに対するSAMLアサーションを確認します。属性が存在する場合、その属性を抽出して、アクセス・リクエスト用にOESを起動する際に属性として渡します。
OWSMは、サブジェクト、リソース、アクションをその他の定義済属性とともに提供します。
OESは、SAML属性、サブジェクト、リソースおよびアクションに基づいてアクセスを決定します。OESは、カスタム属性リトリーバを使用して、SAML属性を取得します。
OESは、許可または拒否で応答します。
許可された場合、OWSMがサービス・プロバイダにメッセージを渡します。
拒否された場合、OWSMがアクセス拒否フォルトでリクエストを却下します。

2.16.2.4.3 OESの大まかな認可

コンシューマのアイデンティティ、およびコールされたWebサービス操作に基づいてリソースへのアクセスを決定します。OESアクセス・チェックは、ユーザー名、グループおよびロールに限定されたアイデンティティ属性に基づいています。暗黙属性、および時間、日付などOESの定義済属性も使用できます。

このモードを使用するには、OWSM OESポリシーでuse.single.stepをtrueに設定する必要があります。

図2-5に、大まかな認可のユースケースを示します。このユースケースでは、コンシューマがサービスへのアクセスを許可されているかどうかを判断する認可ポリシーを使用して、サービスを保護することを前提としています。コンシューマのアイデンティティ(認証されたサブジェクト)および起動されたWebサービス操作に基づいてリソースへのアクセスを決定します。たとえば図2-5では、ユーザーBob Doeは顧客の詳細の取得は認可されていますが、顧客レコードの削除は認可されていません。

図2-5 大まかな認可

「図2-5 大まかな認可」の説明

図2-5に示すWebサービス・レスポンスに対する次のコードの流れについて、考えてみてください。

Webサービス・クライアントがSOAPリクエストまたはXMLリクエストを送信します。
このWebサービスは、OWSM認証ポリシーとOWSM OESポリシーで保護されています。
OWSMが認証を実行し、アクセス・リクエストのためにOESを起動します。OWSMは、サブジェクト、リソース、アクション情報をOESに提供します。
OESは、サブジェクト、リソースおよびアクション情報に基づいてアクセスを決定します。
OESは、許可または拒否で応答します。
許可された場合、OWSMがサービス・プロバイダにメッセージを渡します。
拒否された場合、OWSMがアクセス拒否フォルトでリクエストを却下します。

2.16.3 OWSM OESのポリシーについて

OWSMには、次のOES認可ポリシーとマスキング・ポリシーが含まれています。

各ポリシー固有の構成情報については、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の事前定義済ポリシーに関する項を参照してください。

oracle/binding_oes_authorization_policy: このポリシーは、OESで定義されているポリシーに基づいてユーザー認可を実行します。認可は、属性、現在の認証されたサブジェクト、およびクライアントが起動したWebサービスのアクションに基づいています。

このポリシーは、use.single.step属性の設定に応じて、Webサービスの任意の操作における大まかな認可またはファイングレイン認可に使用されます。(「OESのファイングレイン認可および大まかな認可の概要」を参照してください。)

OWSM OESポリシーには認証されたサブジェクトが必要であるため、認証ポリシーをOWSM OES認可ポリシーと一緒に使用する必要があります。

このポリシーでは、リソース、アクションおよび制約のmatch値を定義するためにguard要素(orawsp:guardを参照)も使用されます。これらの値によって、guardの結果がtrueの場合にのみ、アサーション実行が許可されるようになります。アクセスしたリソース名およびアクションが一致した場合にのみ、アサーションの実行が許可されます。デフォルトで、リソース名およびアクションでは、ワイルドカードのアスタリスク(*)が使用され、すべてが許可されます。

このポリシーは、SOAPベースのすべてのエンドポイントにアタッチできます。
oracle/component_oes_authorization_policy: このポリシーは、OESで定義されているポリシーに基づいてユーザー認可を実行します。

このポリシーは、use.single.step属性の設定に応じて、SOAコンポーネントの任意の操作における大まかな認可またはファイングレイン認可に使用されます。(「OESのファイングレイン認可および大まかな認可の概要」を参照してください。)

OWSM OESポリシーには認証されたサブジェクトが必要であるため、認証ポリシーをOWSM OES認可ポリシーと一緒に使用する必要があります。認可は、属性、現在の認証されたサブジェクト、およびクライアントが起動したWebサービスのアクションに基づいています。

このポリシーでは、リソース、アクションおよび制約のmatch値を定義するためにguard要素(orawsp:guardを参照)も使用されます。これらの値によって、guardの結果がtrueの場合にのみ、アサーション実行が許可されるようになります。アクセスしたリソース名およびアクションが一致した場合にのみ、アサーションの実行が許可されます。デフォルトで、リソース名およびアクションでは、ワイルドカードのアスタリスク(*)が使用され、すべてが許可されます。

このポリシーは、SOAコンポーネントのファイングレイン認可に使用されます。
oracle/binding_oes_masking_policy: このポリシーは、OESで定義されているポリシーに基づいてレスポンスのマスキングを実行します。認証ポリシーは、OWSM OESマスキング・ポリシーと一緒に使用できます。(サブジェクトが存在しない場合、マスキング決定時にユーザーが考慮されない。)マスキングは、属性、現在の認証されたサブジェクト、およびクライアントが起動したWebサービスのアクションに基づいています。

このポリシーでは、リソース、アクションおよび制約のmatch値を定義するためにguard要素(orawsp:guardを参照)が使用されます。これらの値によって、guardの結果がtrueの場合にのみ、アサーション実行が許可されるようになります。アクセスしたリソース名およびアクションが一致した場合にのみ、アサーションの実行が許可されます。デフォルトで、リソース名およびアクションでは、ワイルドカードのアスタリスク(*)が使用され、すべてが許可されます。

このポリシーは、Webサービスの任意の操作におけるファイングレイン・マスキングに使用されます。

2.16.4 リソースのマッピングおよび命名の概要

OESリソース名は、OWSMリソース名にマップする必要があります。OWSMから認可コールを実行すると、リソース名がOESに渡されます。この名前はOESポリシーで定義されている名前と正確に一致する必要があります。

この項の内容は、次のとおりです。

2.16.4.1 リソースのマッピングおよび命名

表2-1に、OESポリシーのリソース文字列の構成方法を示します。

命名規則に従う際には、OWSMポリシーにリソース名を設定する必要はありません。OWSMにより、リソース名が導出されます。

注意:

これがデフォルトのマッピングです。このマッピングを変更する必要がある場合には、構成オーバーライドを使用します。Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の構成プロパティと構成オーバーライドに関する項を参照してください。

表2-1 リソース文字列の決定

OESのフィールド	使用する値
アプリケーション	デプロイされているアプリケーション名。 SOAの場合、コンポジット名がアプリケーション名として使用されます。
リソース・タイプ	サブジェクト・タイプに基づいて固定されます。 SOAPの場合、`WS_SERVICE`である必要があります。 SOAコンポーネントの場合、`COMPONENT`である必要があります。
リソース名	SOAPおよびSOA参照の場合、`web-service-name/port/web service operation`の形式である必要があります。 SOAコンポーネントの場合、`SOA component name/web service operation`の形式である必要があります。
アクション	デフォルトでは、次のいずれかになります。 `request.lookup` (認可の責任ポリシー。) `response.lookup` (マスキングの責任ポリシー。) `mask` (実際のマスキング・ポリシー。) `authorize` (実際の認可ポリシー。)

2.16.4.2 OESポリシーの例

SOAコンポジット(SOA1)に2つのサービス・バインディング(Serv1とServ2)があるとします。

Serv1にはport11があります。
Serv2にはport21があります。
port11にはoper11、oper12があります。
port21にはoper21があります。

OESでは、表2-2に示すように、アプリケーション、リソース・タイプ、リソース名およびアクションを定義する必要があります。

表2-2 リソース文字列の例

OESのフィールド	使用する値
アプリケーション	soa1
リソース・タイプ	`WS_SERVICE`
リソース名	`Serv1/port11/oper11`、 `Serv1/port11/oper12`、 `Serv2/port21/oper21`
アクション	次のいずれかです。 `request.lookup` (認可の責任ポリシー。) `response.lookup` (マスキングの責任ポリシー。) `mask` (実際のマスキング・ポリシー。) `authorize` (実際の認可ポリシー。)

表2-2に基づいた認可とマスキングのOESポリシーは、次のとおりです。

返される責任

任意の操作に対して責任を返す1つのポリシー:

GRANT (action: request.lookup; Resource: WS_SERVICE/Serv1/Port11, WS_SERVICE/Serv2/Port21; User: any) Obligation: XPath11

操作固有の責任を返す複数のポリシー:

GRANT (action: request.lookup; Resource: WS_SERVICE/Serv1/Port11/oper11;User:any) Obligation: XPath11
GRANT (action: request.lookup; Resource: WS_SERVICE/Serv1/Port11/oper12;User:any) Obligation: XPath12
GRANT (action: request.lookup; Resource: WS_SERVICE/Serv2/Port21/oper21;User:any) Obligation: XPath21

実際の認可

リソースやアクションとは関係なく同じ認可を実行する１つのポリシー:

GRANT/DENY (action: authorize; Resource: WS_SERVICE/Serv1/Port11, WS_SERVICE/Serv2/Port21; User:<actual user>)

操作固有の認可を実行する複数のポリシー:

GRANT/DENY (action: authorize; Resource: WS_SERVICE/Serv1/Port11/oper11;User:<actual user>)
GRANT/DENY (action: authorize; Resource: WS_SERVICE/Serv1/Port11/oper12;User:<actual user>)

マスキングする責任の戻り値:

GRANT (action: response.lookup; Resource: WS_SERVICE/Serv1/Port11/oper11;User:any) Obligation: XPath11
GRANT (action: response.lookup; Resource: WS_SERVICE/Serv1/Port11/oper12;User:any) Obligation: XPath12
GRANT (action: response.lookup; Resource: WS_SERVICE/Serv2/Port21/oper21;User:any) Obligation: XPath21

実際のマスキング:

GRANT/DENY (action: mask; Resource: WS_SERVICE/Serv1/Port11/oper11;User:<actual user>)
GRANT/DENY (action: mask; Resource: WS_SERVICE/Serv2/Port21/oper21;User:<actual user>)

2.16.5 属性の処理方法

OES管理者は、OESポリシー内の属性を責任として定義します。これは、OWSMによってペイロードから抽出された後、OESに返されます。

具体的には、OESを使用すると、責任をOESコンソールで作成できます。また、複数の属性名/値のペアが提供されます。たとえば、Employeeという名前の責任を作成して、{Name=John, Age=21, SSN=123456}などの複数の属性を指定できます。

属性は、XPath、HTTPヘッダー、メッセージ・コンテキストおよに定数(名前/値)から取得できます。これらの属性は、表2-3で説明されているように、特定の命名規則に従う必要があります。

表2-3 OESポリシーでサポートされる属性タイプ

属性タイプ	説明	必要な形式
XPath問合せ	属性名と値は、OESコンソールでXPath問合せとして指定します。 OWSMはこのXPath問合せをSOAPメッセージで実行し、その値を属性値として使用します。XPath問合せの結果は、単一値であることも複数の値であることもあります。複数の値の場合、すべての値を渡すには文字列のリストを使用します。いずれかのXPath問合せでSOAPメッセージの評価に失敗した場合、その問合せは無視され、警告メッセージがログ内に生成されます。OWSMは、次のXPath問合せの評価を続行します。	`XPath` (大/小文字を区別しない)を責任名として使用し、それがXPathであることを示します。責任は、XPath問合せで使用されているすべてのネームスペースも返します。すべてのネームスペースは`NAMESPACE` (大/小文字を区別しない)という属性名と一緒に返され、その値はカンマ区切りのネームスペースになります。たとえば、認可にSAML発行者名を使用する場合、次の責任形式を使用します。 Name = XPath, values = {saml_issuer=.//saml:Assertion/@Issuer, CC_Name=ns1:sayHello/arg0, NAMESPACE=ns1=http://...,wsse=http://...} 認可フェーズでは、OWSMが属性名`saml_issuer`を渡し、その値はXPath問合せの結果になります。デフォルトのネームスペースは、接頭辞にマップする必要があります。(接頭辞名はアプリケーション内で一意である必要がある。) 次に例を示します。 saml=urn:oasis:names:tc:SAML:1.0:assertion,ns0=http://example.com,myPrefix=http://default_namespace ネームスペースの定義はカンマで区切られています。
HTTPヘッダー	HTTPヘッダー名は、OESコンソールで指定します。この値は、現在のリクエストHTTPヘッダーからフェッチされます。	HTTPヘッダーのプロパティを取得するには、「HTTPHeader」(大/小文字を区別しない)という名前の責任を定義します。これには、複数のHTTPヘッダー名が存在する可能性があります。属性の名前には、値の割当て先の名前を指定する必要があります。つまり、値は実際のHTTPヘッダー名である必要があります。次に例を示します。 Name = HTTPHeader, values = {AuthHeader=Authorization} 認可フェーズでは、OWSMがHTTPヘッダーを取得し、それを属性名で指定されている名前に割り当てます。
メッセージ・コンテキスト・プロパティ	メッセージ・コンテキスト・プロパティ名は、OESコンソールで指定します。この値は、現在のメッセージ・コンテキストからフェッチされます。	「MessageContext」(大/小文字を区別しない)という名前の責任を定義します。これには、複数のメッセージ・コンテキスト・プロパティ名が存在する可能性があります。属性の名前には、値の割当て先の名前を指定する必要があります。つまり、値は実際のメッセージ・コンテキスト・プロパティ名である必要があります。次に例を示します。 Name = MessageContext, values = {authMethod=oracle.wsm.internal.authentication.method, endpoint=oracle.j2ee.ws.runtime.endpoint-url} 認可フェーズでは、OWSMがメッセージ・コンテキスト・プロパティを取得し、それを属性名で指定されている名前に割り当てます。たとえば、前述の例は次のように解決されます。 authMethod=USERNAME_TOKEN & endpoint=http://localhost:7001/myService
定数	定数は、OWSMで認識されないユーザー定義属性であり、そのまま渡されます。	`Employee`という名前の責任は、定数の一例です。
暗黙	OWSMは、すべての認可リクエスト内の暗黙属性を渡します。それらを渡すための構成を行う必要はありません。次の暗黙属性が常に渡されます。 `serviceURL`: WebサービスのURL。 `serviceNS`: Webサービスのネームスペース。 `clientIP`: クライアントのIPアドレス。 `processingStage`: リクエストまたはレスポンスのどちらであるか。使用可能な値は、request、responseおよびfaultです。 `isRequestOverSSL`: ブール値。リクエストが一方向または双方向のSSLの場合はtrue。 `authenticationMethod`: 認証方式。使用可能な値は、`SAML_SV、KERBEROS`、`SAML_HOK`、`X509_TOKEN_AUTHENTICATION`、`SAML_BEARER`および`USERNAME_TOKEN`です。 `requestOrigin`: VIRTUAL_HOST_TYPEトランスポート・ヘッダーから判別される内部または外部のリクエスト元。 `clientSigningCertDN`: 双方向SSLにおけるX509署名用証明書またはクライアント証明書。 `operationName`: ユーザーが起動した操作名。 `samlIssuer`: SAMLアサーションから抽出されたSAML発行者。 `type`: OESへのリクエスト・タイプ。使用可能な値は、request.lookup、response.lookup、authorizeまたはmaskです。この属性は常に送信されます。	不要。これらは常に渡されます。通常、これらの定数をOESコンソールの「条件」で使用します。

2.16.6 ガード要素について

OWSM OES認可ポリシーでは、orawsp:guard要素が使用されます。これにより、ガードの結果がtrueの場合にのみアサーションが実行されるようにできます。つまり、アクセスしたリソース名とアクションが一致した場合にのみ、OES認可エンジンがコールされます。

デフォルトで、リソース名およびアクションでは、ワイルドカードのアスタリスク(*)が使用され、すべてが許可されます。ただし、特定のリソース名、アクションおよび制約を設定した場合は、いずれかの構成プロパティおよびOESポリシーを使用するには、その要件を満たしている必要があります。

ガードのリソース命名規則は、OESの標準命名規則とは異なります。ガードのリソース名は、<Webservice_NS>/<SERVICE_NAME>の形式にする必要があります。

2.17 個人の身元を特定する情報の概要

個人の身元を特定する情報 (PII)は、社会保障番号、住所、銀行の口座番号、およびその他の類似情報を指しています(通常は1人の特定のユーザーに関連付けられており、保護する必要がある)。

OWSMは、セキュリティ・ポリシーの制御範囲外にあるPIIを保護するためのソリューションを提供します。これにより、PIIがログ内、メッセージ内、監査証跡内で非表示になります。

2.17.1 PIIデータの概要

OWSM WS-Securityポリシーには、メッセージ保護を使用して情報を選択的に暗号化する方法が用意されています。ただし、この情報がSOAコンポジット内部で処理されるときなど、セキュリティ・ポリシーの制御範囲外にあって暗号化されないことがあります。

次の各トピックでは、PIIデータについて説明します。

2.17.1.1 PIIデータについて

ビジネス上の慣習で、アプリケーション内での情報(特にPII情報)フローであっても暗号化が必要な場合があります。ご使用の環境がこのケースに当てはまる場合は、各コンポーネントへのメッセージ・フローにおいてPII情報を暗号化したままにしておく必要があります。たとえば、SOAの場合、PIIはSOAコンポジットのエントリ・ポイントで暗号化し、参照バインディングの終了ポイントで復号化する必要があるということです。

oracle/pii_security_policyポリシーは、この目的でデータを暗号化するために提供されています。

文字列ではないデータのアンマーシャル時における追加情報については、「アンマーシャリングに関するその他の考慮事項について」を参照してください。

注意:

OWSM WS-Securityポリシーは、情報暗号化の方法を提供していますが、このメカニズムを使用してPIIデータを暗号化することはできません。アプリケーションが、特定のXML構造を備えた情報を予期していたり、そのような情報に依存している可能性があるためです。OWSMポリシーでは、XML構造にCipherData (http://www.w3.org/TR/xmlenc-core/#sec-CipherData)要素が追加されます。ご使用のアプリケーションがこの要素を予期していない可能性があります。

2.17.1.2 PIIセキュリティ・ポリシーについて

oracle/pii_security_policyには次の設定と、保護するPIIデータを正確に指定する構成プロパティが含まれています。ポリシーをアタッチする際にこれらの属性を設定したり、必要に応じてオーバーライドすることができます。

注意:

ローカルの最適化(OWSMポリシー(SOAコンポジット)でのローカルの最適化の使用に関する項を参照)はデフォルトでオフになっているため、oracle/pii_security_policyポリシーが常に施行されます。SOAコンポジットから移動する前には、PIIが復号化されます。その影響を理解しないまま、oracle/pii_security_policyポリシーに対するローカルの最適化をオンにしないでください。

XPathsを使用してPIIデータを使用する方法については、「PIIポリシーのXPath式について」を参照してください。

encryption-algorithm: データ暗号化アルゴリズム。AES/CBC/PKCS5Paddingにする必要があります。
algorithm: キー導出アルゴリズム。PBKDF2にする必要があります。
Salt: キー導出で使用されるNULL以外の空でないsalt。デフォルト値はpii-securityです。
Iteration: キー導出の反復回数。デフォルト値は1000です。
Keysize: キー導出で使用するキーのサイズ。デフォルト値は128です。
request.xpaths: リクエストのXPathのカンマ区切りのリスト。デフォルト値は空白です。たとえば、//ns2:ShipToLocationIdです。
request.namespaces: リクエストのネームスペースのカンマ区切りのリスト。各ネームスペースの接頭辞とURIは、等号(=)で区切られます。デフォルト値は空白です。
response.xpaths: レスポンスのXPathのカンマ区切りのリスト。デフォルト値は空白です。たとえば、//ns2:ShipToLocationIdです。
response.namespaces: ネームスペースのカンマ区切りのリスト。各ネームスペースの接頭辞とURIは、等号(=)で区切られます。デフォルト値は空白です。
csf.key: oracle/pii_security_policyポリシーは、対称キーを生成する際に指定したパスワードのCSFキー属性を使用します。このキーは、PIIデータの暗号化と復号化に使用されます。デフォルト値はpii-csf-keyです。
reference.priority: ポリシー・アタッチメントの優先度の指定に関する項を参照してください。

注意:

pii-securityアサーションは、ポリシー内の唯一のアサーションである必要があります。pii-securityアサーションは、他のアサーションを持つポリシーに追加しないでください。そうすると、ポリシーが無効になります。

2.17.2 PIIデータを保護する方法の例

PIIがセキュリティ・ポリシーの制御外にある場合は、oracle/pii_security_policyポリシーでPIIを保護することが重要です。これについて、例を使用して説明します。

図2-6に示すOracle Service Busの例について考えます。図2-6で示すように、PII保護の主要な原則は次のとおりです。

サービス側(proxy service)にアタッチされたPIIポリシーは、リクエストの受信後にPIIを暗号化し、レスポンスを送信する前にPIIを復号化する必要があります。
クライアント側(ビジネス・サービス)にアタッチされたPIIポリシーは、リクエストを送信する前にPIIを復号化し、レスポンスを受信した後でPIIを暗号化する必要があります。

PIIデータの暗号化には、入口ポイントと出口ポイントの両方が必要です。PIIデータは入る前に暗号化され、出る前に復号化されます。

図2-6 Oracle Service BusのPII暗号化

「図2-6 Oracle Service BusのPII暗号化」の説明

図2-6のコントロールのフローは、次のとおりです。

OWSM Webサービス・クライアントは、クライアント・リクエストに署名し、クライアント・リクエストを暗号化して、プロキシ・サービスに送信します。
外部Webサービスを仮想化するには、OSBプロキシ・サービスを作成して、ビジネス・サービスに接続するパイプラインとして使用します。つまり、OWSMサービス側のポリシーをプロキシにアタッチします。

OWSMエージェントは、メッセージ保護ポリシーを使用してメッセージを復号化します。
この時、すべてのPII情報は脆弱になる可能性があります。それを防ぐために、PIIポリシーはメッセージでPIIを暗号化します。
Oracle Service Busはメッセージのコントロールを想定し、プロキシ・サービスはリクエストをビジネス・サービスに渡します。
ビジネス・サービスはメッセージ・データにアクセスし、これには暗号化されたばかりのPIIデータが必要に応じ、含まれる場合があります。
OWSMエージェントは再び、PIIポリシーを適用し、PIIフィールドを復号化します。
ビジネス・サービスは、基本的にすべてのクライアント構成で、外部サービスのコールのために必要です。Oracle Service Busは、OWSMクライアント・ポリシーのビジネス・サービスへのアタッチをサポートします。

メッセージ保護ポリシーが適用され(署名され、暗号化されて)、メッセージはWebサービスに送信されます。
プロセスは、レスポンスを繰り返し、Webサービス・クライアントに戻されます。

2.17.3 PIIポリシーのXPath式について

XPath式を使用して、保護するPIIデータを指定します。

より具体的には、XPath式を使用して、保護する要素を正確に指定します。XPathは、XPathテキスト・ノードで終了する必要があります。

XPathの結果がテキスト・ノードである場合、テキスト・ノードのコンテンツは暗号化されます。空の(つまり、すべて空白の)テキスト・ノードは、暗号化も復号化もされません。

XPathで複数のノードが返された場合は、それらのすべてが暗号化されます。何も返されない場合は、無視されます。

指定したXPathsは、env:Bodyの最初の子要素をルート・ノードとして設定して評価されます。

JDeveloperを使用して、次のSOAPメッセージを表示するとします。

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body 
 
 
xmlns:ns1="http://xmlns.example.com/apps/prc/po/editDocument/purchaseOrderService/types/">
<ns1:createPurchaseOrder>
 <ns1:createOrderEntry 
 
 
xmlns:ns2="http://xmlns.example.com/apps/prc/po/editDocument/purchaseOrderService/">
 <ns2:DocumentStyleId>1</ns2:DocumentStyleId> 
 <ns2:ProcurementBuId>204</ns2:ProcurementBuId> 
<ns2:BuyerId>100010026863783</ns2:BuyerId> 
<ns2:RequisitioningBuId>204</ns2:RequisitioningBuId> 
<ns2:SupplierId>559</ns2:SupplierId> 
<ns2:SupplierSiteId>5058</ns2:SupplierSiteId> 
<ns2:SupplierContactId>100000011552368</ns2:SupplierContactId> 
<ns2:ApprovalActionCode>BYPASS</ns2:ApprovalActionCode> 
<ns2:DocumentDescription>DO NOT TOUCH THIS ORDER (V15)</ns2:DocumentDescription> 
<ns2:PurchaseOrderEntryLine>
<ns2:LineTypeId>1</ns2:LineTypeId> 
<ns2:ItemId>199</ns2:ItemId> 
<ns2:Quantity>10</ns2:Quantity> 
<ns2:UnitOfMeasureCode>Ea</ns2:UnitOfMeasureCode> 
<ns2:PurchaseOrderEntrySchedule>
<ns2:ShipToLocationId>207</ns2:ShipToLocationId> 
<ns2:ShipToOrganizationId>207</ns2:ShipToOrganizationId> 
<ns2:NeedByDate>2020-12-31</ns2:NeedByDate> 
<ns2:PurchaseOrderEntryDistribution /> 
</ns2:PurchaseOrderEntrySchedule>
</ns2:PurchaseOrderEntryLine>
</ns1:createOrderEntry>
</ns1:createPurchaseOrder>
</soap:Body>
</soap:Envelope>

次に、XPathの例をいくつか示します。

//ns2:ShipToLocationId

//表記法(子孫または自己の軸)を使用して、ShipToLocationIdsの本体全体を検索することを示します。これらのXPathsでは、ドキュメント全体の検索が必要になるため低速になります。
/ns1:createPurchaseOrder/ns1:createOrderEntry/ns2:BuyerId

このXPathでは、本体の子createPurchaseOrder、次にcreatePurchaseOrderの子createOrderEntry、最後にcreateOrderEntryの子BuyerIdを参照することが明確に指定されています。

PIIポリシーには、リクエスト・メッセージとレスポンス・メッセージの両方にXPathリストが必要です。

2.17.4 PIIポリシーを使用する状況

oracle/pii_security_policyポリシーは、単一のSOAコンポジットおよびPIIがJCAバインディングにあるユースケースでのみ使用できます。

注意:

グローバル・ポリシー・アタッチメントは、oracle/pii_security_policyポリシーでの使用をお薦めしません。

次の各トピックでは、様々なユース・ケースについて説明します。

注意:

Fusion Middleware ControlおよびJDeveloperコントロールでは、サポートされていないサブジェクト・タイプにpii_security_policyポリシーをアタッチすると、実行時の検証エラーが発生します。

WLSTでは、サポートされていないサブジェクト・タイプにポリシーをアタッチすると、検証エラーが発生します。

The web service configuration is invalid in this context because of the following error: WSM-01832 : PII Policy oracle/pii_security_policy is not supported on the Resource, as the PII policy 
is not supported on SubjectType : WS_SERVICE

2.17.4.1 単一のSOAコンポジットのユースケース

pii_security_policyポリシーはSOAコンポジットにのみアタッチ可能で、そのコンポジット内のPIIのみを保護できます。その他のSOAユースケースはサポートされていません。

pii_security_policyポリシーをSOAコンポジットにアタッチした場合、メッセージがSOAコンポジットに入るときにPIIは暗号化され、(SOA参照バインディング・コンポーネントで)そのコンポジットから出るときに復号化されます。具体的には、次のようになります。

サービス側(サービス・バインディング)では、pii_security_policyポリシーが、リクエストの受信後にPIIを暗号化し、レスポンスの送信前にPIIを復号化します。
クライアント側(参照バインディング)では、pii_security_policyポリシーが、リクエストの送信前にPIIを復号化し、レスポンスの受信後にPIIを暗号化します。

注意:

PIIデータには、入口ポイントと出口ポイントの両方が必要です。PIIデータは入る前に暗号化され、出る前に復号化されます。

pii_security_policyポリシーをクライアント側でアタッチした場合、それをサービス側でもアタッチする必要があります。逆の場合も同様です。暗号化/復号化のメカニズムでは、その両方が必要です。

図2-7に示すように、BPEL、Oracle Mediatorなど、コンポジットの様々なコンポーネントを流れるメッセージでは、PIIは暗号化されたままです。

図2-7 単一のSOAコンポジットのユースケース

「図2-7 単一のSOAコンポジットのユースケース」の説明

PIIおよび認可ポリシーの両方がアタッチされている場合の重要な考慮事項の理解

pii_security_policyポリシーと認可ポリシーの両方がSOAコンポジットにアタッチされている場合は、認可ポリシーがPIIポリシーより前に実行されます。そうしないと、pii_security_policyポリシーが、認可で使用するフィールドを暗号化する場合があります。

ただし、認可ポリシーがかわりにSOAコンポーネント・レベルでアタッチされていて、pii_security_policyで暗号化されたフィールドが認可で必要とされる場合、認可に失敗します。これは、サポートされているユースケースではありません。

2.17.4.2 ビジネス・サービス・ユースケースへのOracle Service Busプロキシ・サービス

Oracle Service Busへのoracle/pii_security_policyのアタッチ方法については、Oracle Service Busでのサービスの開発のメッセージ内の個人の身元を特定する情報の非表示に関する項を参照してください。

2.17.4.3 JCAバインディング・ユースケースにおけるPII

PIIポリシーは、SOAとOracle Service Busの両方のJCAアダプタにアタッチできます。

OSBでは、Oracle Service Busへのoracle/pii_security_policyのアタッチ方法については、Oracle Service Busでのサービスの開発のメッセージ内の個人の身元を特定する情報の非表示に関する項を参照してください。

この項の残りの部分では、SOAのユースケースについて説明します。

『Oracle SOA Suiteを使用したSOAアプリケーションの開発』のJCAアダプタに関する項で説明されているように、JCAアダプタを使用すると、SOAのサービスおよび参照をデータベースやファイル・システムなどのテクノロジと統合できます。JCAアダプタは、Oracle Fusion MiddlewareプラットフォームのJCAバインディング・コンポーネントと統合されます。これにより、その他のサービス・エンジンおよびバインディング・コンポーネントとの統合も実現されます。

図2-8に示すJCAアダプタPIIのユースケースについて、考えてみてください。

図2-8 JCAアダプタPIIのユースケース

「図2-8 JCAアダプタPIIのユースケース」の説明

コンポジットには、インバウンド・サービス・バインディング・コンポーネント(インバウンド・アダプタ)、BPELプロセスなどのサービス・コンポーネントおよびアウトバウンド参照バインディング・コンポーネント(アウトバウンド・アダプタ)が含まれます。

注意:

PIIデータには、入口ポイントと出口ポイントの両方が必要です。PIIデータは入る前に暗号化され、出る前に復号化されます。

pii_security_policyポリシーを参照バインディング側でアタッチした場合、それをサービス・バインディング側でもアタッチする必要があります。逆の場合も同様です。暗号化/復号化のメカニズムでは、その両方が必要です。

このユースケースでは、PIIは次のように保護されます。

サービス・バインディング・コンポーネントは、SOAコンポジット・アプリケーションへの外部からのエントリ・ポイントを提供します。

サービス側(JCAバインディング)では、pii_security_policyポリシーが、リクエストの受信後にPIIを暗号化し、レスポンスの送信前にPIIを復号化します。
BPEL、Oracle Mediatorなど、コンポジットの様々なコンポーネントを流れているメッセージでは、PIIは暗号化されたままです。
参照バインディング・コンポーネントは、SOAコンポジット・アプリケーションから外部サービスへのメッセージの送信を可能にします。

クライアント側(JCAバインディング(参照))では、pii_security_policyポリシーが、リクエストの送信前にPIIを復号化し、レスポンスの受信後にPIIを暗号化します。

JCAアダプタとSOA環境の統合方法の詳細は、Oracle SOAコンポジットとアダプタの統合に関する項を参照してください。

2.17.5 PIIに対するアクセス権を持っているのは誰か

管理者は常に、PIIの暗号化で使用するキーへのアクセス権を持っており、PIIの暗号化を再構成することもできます。そのため、PIIポリシーによって、管理者や管理者権限を持つその他のユーザーからデータを保護することはできません。これは、そのような目的での使用を意図されていません。

ただし、管理者は、次のシナリオで暗号化キーとPIIデータが表示されていないことを確認する必要があります。

OWSMメッセージ・ログ、サーバーの診断ログ、SOAメッセージ・ログなどの任意の種類のログ。ログは頻繁にコピーされ、管理者以外のユーザーに対しても公開されます。
管理者以外のユーザーが表示できる任意の画面。

そのようなユーザーに対しては、PII情報が非表示になるはずです。このユーザーはログを参照できますが、ログには暗号化されたPIIデータがあります。このユーザーは復号化に必要なキー情報を表示できません。
オペレータ、モニターなどのロール。これらのロールでは、PII暗号化キーまたはPIIデータにアクセスできません。また、復号化されたPIIデータを含むどのログ・ファイルにもアクセスできません。

2.17.6 アンマーシャリングに関するその他の考慮事項について

アンマーシャリングでは、XMLドキュメントを変換して、Javaプログラム要素やオブジェクトのツリーを作成します。これは、Javaコードでアクセス可能なドキュメントのコンテンツや構成を表しています。コンテンツ・ツリーでは、複合タイプは値クラスにマップされます。属性宣言または単純型を持つ要素は、値クラス内のプロパティまたはフィールドにマップされ、その値にアクセスするにはgetメソッドとsetメソッドを使用します。

アンマーシャリングは、JAXBバインディング・フレームワークによって管理されています。

PIIデータが暗号化されると、メッセージの元のテキストは暗号化された文字列で置き換えられます。ただし、文字列以外のデータ型(整数、日付など)が暗号化された文字列内にある場合、後続のアンマーシャリングが破損することがあります。

pii_security_policyポリシーを実装する前は、アンマーシャリングの影響に注意してください。アンマーシャリングが関係している場合は、文字列データ型のみが動作し、それ以外は破損する可能性があります。

アンマーシャリングは、SOAの次のバインディングで発生することがあります。

EJBアダプタ
レガシーSDO EJBアダプタ
ADFアダプタ
直接バインディング
ルール・エンジン

アンマーシャリングは、次のSOAコンポーネントで発生することがあります。

BPELエンティティ変数
Springサービス・エンジン

アンマーシャリングは、Oracle Service Busの次のポイントで発生することがあります。

SOA直接バインディング
EJBトランスポート