| Oracle® Fusion Middleware Oracle Web Services Managerの理解 12c(12.1.2) E47995-01 |
|
 前 |
 次 |
この章では、Webサービス・セキュリティの概念について説明します。Webサービス・セキュリティには、認証、認可、メッセージ保護など、いくつかの要件が含まれます。
この章の構成は、次のとおりです。
|
注意: OWSM認証および認可ポリシーのサブセットがRESTful Webサービスに対してサポートされています。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のRESTful Webサービスに対してサポートされているOWSMポリシーに関する項を参照してください。 この項では主に、SOAPを使用したWebサービスについて説明します。 |
Webサービスには疎結合の接続という特性があり、またオープン・アクセス(主にHTTP)が使用されるため、Webサービスによって実装されるSOAでは、次に示す一連の新たなセキュリティ要件が追加されます。
認証: ユーザーが表明しているとおりのユーザーであるかを検証します。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。資格証明には次のものがあります。
ユーザーが所有しているもの。たとえばパスポート(実世界)やスマート・カード(ITの世界)など、信頼できる機関が発行した資格証明。
ユーザーが知っているもの。たとえばパスワードなどの共有の秘密鍵。
ユーザーの特性。たとえばバイオメトリック情報。
複数のタイプの資格情報を組み合せて使用することは、強い認証と呼ばれます。たとえば、ATMカード(ユーザーが持っているもの)とPINやパスワード(ユーザーが知っていること)を使用する場合などです。詳細は、「認証の理解」を参照してください。
認可(またはアクセス制御): 認証されたユーザーの権限に基づいて、特定のリソースへのアクセスを許可します。権限は1つ以上の属性によって定義されます。属性とはユーザーのプロパティまたは特性のことです。たとえば、「Marc」はユーザーで、「会議の発言者」は属性です。詳細は、「認可の理解」を参照してください。
機密保護、プライバシ: 情報の機密性を保ちます。Webサービス・リクエストや電子メールなどのメッセージと、送信ユーザーおよび受信ユーザーのアイデンティティに、機密を保つ方法でアクセスします。メッセージのコンテンツを暗号化し、送信ユーザーおよび受信ユーザーのアイデンティティを不明瞭化することで機密保護とプライバシが実現されます。詳細は、「メッセージ保護の理解」を参照してください。
整合性、否認防止: 送信ユーザーがメッセージにデジタルで署名することによって、メッセージが転送中に変更されないようにします。デジタル署名を使用することによって、署名が検証され、否認防止が実現されます。署名内のタイムスタンプにより、このメッセージが有効期限後にリプレイされることを防ぎます。詳細は、「メッセージ保護の理解」を参照してください。
Webサービス・セキュリティの要件には、資格証明の仲介(信頼できる環境間でのセキュリティ・トークンの交換)およびサービスの機能と制約(Webサービスがどの環境で何を実行できるかを定義する)も含まれます。
多くの場合、OWSMのようなWebサービス・セキュリティ・ツールは、公開鍵インフラストラクチャ(PKI)環境に依存します。PKIでは、暗号鍵(データの暗号化または復号化に使用される数学関数)を使用します。鍵は秘密鍵、公開鍵のいずれかになります。非対称暗号モデルでは、受信ユーザーの公開鍵を使用してプレーン・テキストが暗号化され、受信ユーザーの対応する秘密鍵を使用して暗号文が復号化されます。また、メッセージに署名することによって秘密鍵がデジタル署名の作成に使用され、公開鍵が署名の検証に使用されます。公開鍵証明書(または略して証明書)は、公開鍵の整合性を保証するために使用されます。
Webサービス・セキュリティ要件は、トランスポート・レベル(Secure Socket Layer)およびXMLフレームワークに依存するアプリケーション・レベルの両方で、業界標準によってサポートされています。
Webサービスでサポートされている仕様および標準の詳細は、付録A「Webサービス・セキュリティ標準」を参照してください。
|
注意: オラクル社は新しい標準、特にOASIS Web Services Secure Exchange技術委員会が主導する仕様の普及に貢献しています。 |
Webサービス・セキュリティ要件を次にまとめます。
トランスポート・セキュリティの使用。Webサービス・コンシューマとWebサービス・プロバイダ間の通信チャネルを保護します。
メッセージ・レベルのセキュリティの使用。メッセージ部分のデジタル暗号化によって機密性を確保し、デジタル署名によって整合性を確保します。また、ユーザー名、X.509またはSAMLトークンを要求して認証を実行します。
Oracle Web Services Manager (WSM)は、異機種間環境でWebサービス・セキュリティを定義、実装するために設計され、単一トランザクションを完了するために使用される複数のWebサービスにわたる認証、認可、メッセージの暗号化および復号化、署名の生成および検証、およびアイデンティティ伝播が含まれます。
セキュリティの概念は、トランスポート・レベルに関連する概念とアプリケーション・レベルに関連する概念に分けることができます。トランスポート・レベルのセキュリティでは、アプリケーション間の通信チャネルが保護されます。トランスポート・レベルのセキュリティ・プロトコルの例として、Secure Socket Layer (SSL)があります。このプロトコルは、Transport Layer Security (TLS)と呼ばれることもあります。TLSは、Internet Engineering Task Force (IETF)によって公式に標準化されたSSLバージョンです。最も広く使用されている、このトラスポート・レベルのデータ通信プロトコルでは、次の機能が提供されます。
認証(通信は信頼できる2つのパーティ間に確立されます)。
機密保護(交換されるデータは暗号化されます)。
メッセージ整合性(データが破損しているかどうか確認されます)。
クライアントおよびサーバー間での安全な鍵の交換。
SSLでは、通信チャネルは保護されますが、転送中でないデータは保護されません。このため、マルチステップ・トランザクション中の攻撃に対して環境が脆弱になります。(SSLでは、エンドツーエンドではなくポイントツーポイントのセキュリティが提供されます。)
SSLは次の3つのモードで使用できます。
認証なし: クライアントもサーバーもお互いに認証しません。証明書も送信または交換されません。この場合は、機密保護(暗号化/復号化)のみが使用されます。
一方向認証(またはサーバー認証): サーバーのみがクライアントに対して自身を認証します。サーバーは、自身が信頼できることを検証する証明書をクライアントに送信します。この方法は、オンライン・バンキングなどのインターネット・トランザクションで使用されます。
双方向認証(または相互認証): クライアントとサーバーの両方が、相互に証明書を送信することでお互いに認証します。この方法は、プロキシとWebサービス・エンドポイント間での攻撃の防止に必要です。
SSLでは、秘密鍵および公開鍵暗号化を組み合せて通信を保護します。SSLトラフィックでは、暗号化と復号化に秘密鍵が使用され、通信に関わるパーティの相互認証で公開鍵の交換が行われます。
アプリケーション・レベルのセキュリティはトランスポート・レベルのセキュリティを補完します。アプリケーション・レベルのセキュリティでは、XMLフレームワークに基づいて、メッセージの機密保持、整合性、信頼性(メッセージ保護とも呼ばれる)、メッセージ構造、信頼の管理およびフェデレーションが定義されます。アプリケーション・レベルのセキュリティのこれらのコンポーネントについては、「メッセージ保護の理解」、「認証の理解」および「認可の理解」の各項で詳しく説明します。
認証とは、ユーザーが表明しているとおりのユーザーであることを検証することです。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。資格証明には次のものがあります。
ユーザーが所有するもの。たとえば、信頼できる機関によって発行された資格証明(デジタル証明書など)、標準の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セキュリティ・トークンは、特にアイデンティティ伝播が必須である場合に関連します。
OWSMは、ユーザー名トークン認証ポリシーでDigestベースの認証をサポートしています。
Digest認証は、WebアプリケーションがサーバーにDigest(パスワード、nonceおよびタイムスタンプの暗号ハッシュ)を送ることによって、Webサービスに対して自身を認証する認証メカニズムです。
Digest認証の使用時には、次の処理が行われます。
クライアントがWebサービスに対して未認証リクエストを実行します。サーバーは、Digest認証をサポートしていることを示すDigest認証チャレンジ付きのレスポンスを送信します。
クライアントはnonceを生成し、それをタイムスタンプ、Digestおよびユーザー名とともにサービスに送信します。Digestは、パスワード、nonceおよびタイムスタンプの暗号ハッシュです。
サーバー自身も、パスワード(サービス・ストアから取得)、nonceおよび(メッセージの)タイムスタンプからハッシュを生成します。サーバーが生成したハッシュがリクエスト内のハッシュと一致すると、リクエストが許可されます。
Digest認証の利点は、リプレイ攻撃に対する耐性があることです。実装では、使用済nonce/タイムスタンプのキャッシュが、指定された期間中保持されます。指定されたタイムスタンプよりも前のタイムスタンプを持つリクエストは、すべて拒否されます。また、キャッシュに維持されている最新のタイムスタンプ/nonceペアを使用しているリクエストも拒否されます。WebLogic Serverはこのキャッシュをデータベースに格納します。
多くの場合、ユーザーにWebサービスへのアクセスを許可するかどうかを決定する最初の手順は認証です。ユーザーが認証されたら、2番目の手順は、ユーザーがWebサービスへのアクセスを認可されていることを検証することです。
認可(アクセス制御とも呼ばれる)とは、認証されたユーザーの資格に基づいて特定のリソースへのアクセス権を付与することです。権限は1つ以上の属性によって定義されます。属性とはユーザーのプロパティまたは特性のことです。たとえば、「Marc」はユーザーで、「会議の発言者」は属性です。
認可によって、認証されたクライアントがアクセスできる操作を決定できます。認可には次の3つの基本アプローチがあります。
ロール・ベース: ロール・ベースのセキュリティの基盤となる概念は、プリンシパルと呼ばれるアイデンティティのセットをロールにグループ化し、各ロールにポリシーを割り当てることができる、というものです。
アイデンティティ・ベース: アイデンティティ・モデルでは、クライアントの認可のために、クレームとポリシーを管理できます。このアプローチでは、認証されたユーザーの資格証明に含まれているクレームを検証できます。このクレームをWCFサービスの認可ポリシー・セットと比較できます。クライアントが提供するクレームに応じて、サービスは操作またはリソースへのアクセス権を付与するか、アクセスを拒否します。アイデンティティ・モデルは、ファイングレイン認可に役立ち、発行トークン認証の使用時に最も有効です。
リソース・ベース: Windowsアクセス制御リスト(ACL)を使用して、個別リソースが保護されます。
メッセージ保護には、メッセージ機密保護とメッセージ整合性の2つの概念があります。
メッセージの機密保護には、送信ユーザーおよび受信ユーザーのアイデンティティのみでなく、データの機密性も関係します。メッセージのコンテンツを暗号化し、送信ユーザーおよび受信ユーザーのアイデンティティを不明瞭化することで機密保護が実現されます。送信者は受信者の公開鍵を使用してメッセージを暗号化します。メッセージは受信者の秘密鍵でのみ正常に復号化できるため、送信中に第三者によってメッセージが読み取られることはありません。Webサービス・クライアントが使用できるように、Webサービスのbase64エンコード形式の公開証明書がWSDLで発行されます。詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のサービス・アイデンティティ証明書拡張の使用に関する項を参照してください。
メッセージ整合性は、認証局がメッセージにデジタルで署名することにより実現します。デジタル署名は、SOAPメッセージの送信者を認証したり、SOAPメッセージの整合性(SOAPメッセージが送信中に変更されていないこと)を保証したりするために使用されます。
デジタル署名がSOAPメッセージに適用されると、メッセージから一意のハッシュが生成されます。このハッシュは送信者の秘密鍵で暗号化されます。メッセージを受信すると、受信者は送信者の公開鍵を使用してハッシュを復号化します。
|
注意: 通常、証明書を検証するために受信者のキーストアに送信者の公開鍵を格納しておく必要はありません。キーストアにルート証明書があれば、証明書チェーンを検証できます。ただし、ThumbprintやSerialIssuerメカニズムなど、メッセージに送信者の公開鍵が存在しない場合は、送信者の公開鍵を受信者のキーストアに格納する必要があります。 |
送信者のみが秘密鍵を使用してハッシュを暗号化できるため、これで送信者を認証できます。受信者はメッセージとともに送信されるハッシュと、受信者側で生成するハッシュを比較できるため、SOAPメッセージが送信中に改ざんされていないことを確認できます。
次の内容を実行することで、メッセージ保護アサーション・テンプレートおよび事前定義済ポリシーを、リクエストやレスポンス・メッセージの保護に使用できます。
メッセージの署名
メッセージの暗号化
メッセージの署名および暗号化
メッセージの復号化
署名の検証
メッセージの復号化と署名の検証
XML暗号化の仕様には、データを暗号化し、その結果をXMLで表すためのプロセスが記述されています。XML暗号化では、具体的に次のことが定義されています。
デジタル・コンテンツが暗号化および復号化される仕組み。
暗号化キーの情報が受信者に渡される仕組み。
暗号化を簡略化するために暗号化されたデータが識別される仕組み。
XMLドキュメントは、全体または一部を暗号化できます。
例3-1は、クレジット・カード・データをXMLで表現したものです。
例3-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>
例3-2は同じXMLスニペットを示していますが、ここではクレジット・カード番号を暗号化し、番号を暗号値で表現しています。
例3-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署名は、送信者のアイデンティティ(または署名エンティティ)をXMLドキュメントにバインドします。ドキュメントは、送信者の秘密鍵を使用して署名され、署名は送信者の公開鍵を使用して検証されます。
署名の検証は、非対称鍵または対称鍵を使用して行われます。XML署名は、署名エンティティの否認防止も保証し、署名後にメッセージが変更されていないことを証明します。
次の例に示すように、署名はドキュメント全体にも、ドキュメントの一部のみにも適用できます。
例3-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>
SSLセキュリティ・ポリシーによるメッセージ保護および認証、またはメッセージ保護セキュリティ・ポリシーを使用するには、キーストアおよびトラストストアを設定する必要があります。(認証のみのセキュリティ・ポリシーでは鍵は不要です)。
キーストアには、エンティティ秘密鍵およびその秘密鍵に関連付けられた証明書が含まれます。トラストストアには、認証局(CA)からの証明書、またはこのエンティティが信頼する他のエンティティからの証明書が含まれます。キーストアとトラストストアは、Oracle Web Services Manager (OWSM)などを使用して、共通のストアで一緒に管理できます。
Webサービスを構成する前に、必要な秘密鍵および証明書のタイプ、鍵およびキーストアの名前を決定し、それに応じて環境を設定する必要があります。
秘密鍵、デジタル証明書および信頼できる認証局(CA)によって、サーバーのアイデンティティと信頼が確立され、検証されます。
SSLでは、認証のために公開鍵暗号化テクノロジを使用します。公開鍵暗号化では、サーバーの公開鍵と秘密鍵が生成されます。公開鍵で暗号化されたデータは対応する秘密鍵でのみ復号化でき、公開鍵で検証されたデータは対応する秘密鍵でのみ署名できます。秘密鍵は、その所有者のみが公開鍵で暗号化されたメッセージを復号化できるように厳重に保護されます。
公開鍵は、公開鍵の所有者を示す他の情報(名前、住所および電子メール・アドレスなど)とともにデジタル証明書に埋め込まれています。秘密鍵およびデジタル証明書は、サーバーのアイデンティティを提供します。
デジタル証明書に埋め込まれたデータは、認証局(CA)によって検証され、その認証局のデジタル証明書を使用して署名されています。十分に認知された認証局には、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を信頼するようにすでに設定されています。したがって、このようなクライアントでトラストストアを変更する必要はありません。
短所:
証明書発行プロセスを制御することはできません。
秘密鍵の使用を必要とするOWSMセキュリティ・ポリシーは、メッセージ保護および認証の2つの側面に対応します。
メッセージ保護には、メッセージ機密保護とメッセージ整合性の2つの概念があります。メッセージの機密保持では、データの機密性を維持します。そのために、メッセージのコンテンツは暗号化されます。メッセージ整合性では、送信ユーザーがメッセージにデジタル署名することによって、転送中にメッセージが変更されないことを確認します。
認証では、ユーザーが表明しているとおりのユーザーであることを検証します。ユーザーのアイデンティティは、ユーザー自身が提供する資格証明に基づいて検証されます。
インストールに含まれている事前定義済のOWSMポリシーでは、メッセージ保護および認証の様々なオプションをサポートしています。これらのオプションについては、次に示す項で説明します。
|
注意: OWSMポリシーで使用されるネーミング規則により、使用オプションのタイプが識別されます。たとえば、ポリシー |
次の項では、メッセージ保護ポリシーのタイプとその動作方法について説明します。
oracle/wss_saml_or_username_token_over_ssl_service_policyなど、SSLオプションを含むポリシーでは、メッセージ保護のために一方向SSLを使用します。
このタイプのポリシーを使用する場合、次のことを実行する必要があります。
サービス側では、「SSLポリシー用の秘密鍵および証明書の設定」の説明に従って、SSL終端ポイントで秘密鍵を設定します。
クライアント側では、サービスの鍵を信頼するようにトラストストアを設定します。
秘密鍵は、クライアントとサービスが共有セッション・キーについて同意したときに、SSLハンドシェイクのためのメッセージ保護に使用されます。SSLハンドシェイクの後は、秘密鍵は使用されず、クライアント間のトラフィックおよびサービスはすべて共有セッション・キーを使用して署名および暗号化されます。
SSLの構成方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のトランスポート・レベルのセキュリティ(SSL)の構成に関する項を参照してください。
このタイプのポリシーでは、メッセージ保護に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サービスは、クライアントに返信するレスポンスの暗号化および署名のために、同じ対称鍵を使用します。
このタイプのポリシーでは、メッセージ保護にWS-Security 1.0を使用します。
wss10ポリシーを使用する場合、次のことを実行する必要があります。
クライアント側およびサービス側の両方で秘密鍵を設定します。クライアント側で署名鍵の別名を設定し、サービス側で暗号化鍵の別名および署名鍵の別名の両方を設定する必要があります。通常は、両方で同じ鍵を使用できます。
クライアント側では、次のいずれかの方法でサーバー証明書を取得することにより、クライアント側の信頼を構成する必要があります。
『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のサービス・アイデンティティ証明書拡張の使用に関する項の説明に従って、サービス・アイデンティティ証明書拡張を使用して、WSDLで発行されたサービスの公開証明書を使用します。また、サーバー証明書を発行したCAから、サーバー証明書自体またはルート証明書のいずれかをクライアントのトラストストアにインポートする必要があります。サーバー証明書について、任意の別名を選択できます。
選択した任意の別名を使用してクライアントのキーストアにサーバー証明書をインポートします。別名は、ポリシーのアタッチ時に構成オーバーライドを使用して、keystore.recipient.aliasプロパティにより指定します。この方法では、実際のサーバー証明書をインポートする必要があります。CAルート証明書をインポートすることはできません。
サービス側では、こうした証明書を直接インポートするか、こうした証明書を発行したCAをインポートすることにより、クライアントを信頼するようにサービスを構成する必要があります。
wss11オプションの場合と同様に、クライアントは対称鍵を作成した後、サービスの公開鍵により対称鍵を暗号化します。ただし、メッセージの暗号化のためにのみこの対称鍵を使用する点が異なり、メッセージの署名のためにはこの対称鍵は使用しません。そのかわりに、クライアントは、署名鍵の別名によって定義された独自の秘密署名鍵によりリクエスト・メッセージに署名し、サービスはその秘密署名鍵によりレスポンスに署名します。
認証のためにサポートされるトークン、およびこうしたポリシー・タイプに使用される秘密鍵および証明書については、次の項で説明します。認証の構成方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の認証の構成に関する項を参照してください。
次の各項において、「署名鍵の別名」という用語は、コンテキストに応じて意味が異なる点に注意してください。
SAML送信者保証ポリシーでは、これはSAMLアサーションの署名に使用される鍵です。これにより、SAMLアサーションの認証性が証明されます。またSAMLログイン・モジュールは、SAMLアサーションで指定されたユーザーをアサートします。
wss10ポリシーでは、リクエストおよびレスポンス・メッセージに署名し、伝送中の改ざんを防止するために使用されます。
X.509認証ポリシーでは、特定のエンド・ユーザーを認証するために使用されます。
ユーザー名トークンは、ユーザー名やパスワードなどのBasic認証情報を伝達します。ユーザー名トークンが認証のみのポリシーとともに使用される場合、秘密鍵は使用されません。認証およびメッセージ保護を含むポリシーで使用された場合、メッセージ保護に必要な鍵が要求されます。
Kerberosトークンは、バイナリ認証およびセッション・トークンから構成されます。Kerberosトークンが認証のみのポリシーとともに使用される場合、秘密鍵は使用されません。認証およびメッセージ保護を含むポリシーで使用された場合、メッセージ保護に必要な鍵が要求されます。
リクエスト・メッセージは、エンド・ユーザーの署名鍵により署名されます。クライアント側では、エンド・ユーザーの署名鍵により署名鍵の別名を構成する必要があります。
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リストの構成に関する項を参照してください。 |
OWSMは、JKSキーストアおよびキー・パスワードが資格証明ストア・フレームワーク(CSF)に含まれていることを前提とします。次に、このしくみを示します。
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エントリを追加する必要があります。
図3-1に、OPSSのJKSキーストア構成、資格証明ストアのoracle.wsm.securityマップおよびOWSM Javaキーストアの関係を示します。
図を見ると次のことがわかります。
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を指します。
次に、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サーバーごとに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の構成に関する項を参照してください。
非同期Webサービスでは、Oracle Infrastructure Webサービスの開発の非同期Webサービス用のSSLの構成に関する項の説明に従ってトラストストアを構成する必要があります。
OWSMメッセージ保護セキュリティ・ポリシーでは、OWSMキーストアで秘密鍵を設定する必要があります。
ドメインごとに単一のOWSMキーストアが存在し、ドメイン内で実行されるすべてのWebサービスおよびクライアントによってそのキーストアが共有されます。このキーストアには、秘密鍵および信頼証明書の両方が含まれます。JDK cacertsファイルは、OWSMでは使用されません。
次の各項では、OWSMキーストアの基本構成と詳細な構成について説明します。
基本構成例
OWSMキーストアを設定する最も簡単な方法は、自己署名秘密鍵を1つ作成し、それをドメイン全体で使用することです。秘密鍵およびキーストアを作成する際には、キーストアの名前とパスワードを指定します(たとえば、JKSキーストアを使用する場合、キーストア名としてdefault-keystore.jks、このキーストアのパスワードとしてwelcome1を指定します)。また、秘密鍵を参照する場合に使用する別名とパスワードも指定します(たとえば、別名としてorakey、鍵のパスワードとしてwelcome1など)。署名鍵の別名と暗号化鍵の別名の両方で同じ鍵および別名を使用し、キーストアと別名の両方で同じパスワードを使用できます。秘密鍵に関連付けた証明書は、自動的に信頼できるものと見なされるので、信頼できる証明書を追加する必要はありません。
鍵およびキーストアを作成したら、キーストアのパスワードと、別名およびパスワードをOWSMに指定する必要があります。この指定には、Fusion Middleware ControlまたはWLSTのいずれかを使用できます。
Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の秘密鍵の生成とJavaキーストアの作成に関する項とFusion Middleware Controlを使用したOWSMキーストアの構成に関する項の手順では、この例で指定しているユーザー名とパスワードを使用してJKSキーストアの基本構成を設定する方法について説明しています。それぞれの環境では、構成に対して適切な名前およびパスワードを使用する必要があります。
クライアントとサーバーが同じドメインにあるかぎり、この設定はほとんどのポリシーで問題なく使用できます。つまり、SAMLの有無を問わず、任意のwss10またはwss11のポリシーを使用できます。
共通のJPSルートを共有する複数の関連ドメインが存在する場合は、すべてのドメインにこのキーストア・ファイルをコピーできます。これによって、関連するすべてのドメインがすべての暗号化および署名についてこの単一の鍵を共有します。
詳細な設定に関する考慮事項
「基本構成例」で説明したように、メッセージ保護セキュリティを設定する最も簡単な方法は、ドメイン内のすべてのWebサービスについて単一の秘密鍵を用意することです。
より機密性の高いWebサービスを得るには、独自の秘密暗号化鍵を使用するように各Webサービスを構成する必要があります。これらの秘密鍵はOWSMキーストアに存在する必要があります。それぞれが異なる別名(たとえばServiceAおよびServiceB)を使用し、その別名を資格証明ストアに追加していることを確認します。サービスにポリシーをアタッチした場合、Webサービスが必要とする特定の別名を示すために構成オーバーライドを使用する必要があります。そうしない場合、ドメインに対して構成したデフォルトの別名(たとえばorakey)が使用されます。
Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理の資格証明ストアへの鍵およびユーザー資格証明の追加に関する項の手順では、これらの別名サンプルを資格証明ストアに追加する方法について説明しています。
また、信頼できるCA証明書を管理する方が格段に容易であるために、自己署名証明書ではなく内部CAまたは外部CAによって発行された信頼できる証明書を使用すべきです。ただし、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したSAMLの信頼できる発行者およびDNリストの構成に関する項の説明に従って、SAML署名者の信頼できるDNリストを必ず設定してください。これは、OWSMキーストアに外部CA証明書をインポートした場合に特に重要です。この設定を行わないと、証明書を持つユーザーなら誰でも、SAMLトークンに署名することによって、任意のユーザーになりすますことが可能になります。
資格証明ストア・フレームワーク(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アイデンティティ・ストア内の有効なユーザーを表す必要があることに注意してください。
パスワード資格証明には、ユーザー名とパスワードを格納できます。汎用資格証明には、資格証明オブジェクトを格納できます。
CSF構成は、 domain-home/config/fmwconfigディレクトリのjps-config.xmllファイル内で維持されます。
Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のFusion Middleware Controlを使用したOWSMキーストアの構成に関する項の説明に従って、Fusion Middleware Controlを使用してOWSMキーストアを構成すると、指定した別名およびパスワードが資格証明ストアに安全に格納されます。しかし、キーストアに他の別名を追加する場合や、クライアントの認証資格証明を追加する必要がある場合は、資格証明ストアでそれらを構成して格納する必要があります。
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のデフォルト要件です。
このシナリオは、本番前のテスト環境シナリオでダミーのパスワードを使用する場合など、パスワードの秘匿性が重視されていない状況においてのみ推奨されます。
例3-4 WS-SecurityPolicyの例
<wsp:Policy>
<sp:SupportingTokens>
<wsp:Policy>
<sp:UsernameToken/>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:Policy>
前述のポリシーに準拠するメッセージの例を次に示します。
例3-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 Services Security (WS-Security)は、XML暗号化により機密保護を、XML署名によりデータ整合性を実現するSOAPセキュリティ拡張機能を指定します。WS-Securityには、タイプの異なるバイナリとXMLセキュリティ・トークンを、認証および認可の目的でWS-Securityヘッダーに挿入する方法を指定するプロファイルも含まれています。
Webサービス・セキュリティは、次のセキュリティ・トークンをサポートします。
ユーザー名: Webサービス・コンシューマが、認証の資格証明としてユーザー名を指定する方法を定義します。詳細は、「ユーザー名トークン」を参照してください。
X.509証明書: 受信パーティに公開鍵を送信するために設計された署名付きデータ構造。詳細は、「X.509証明書」を参照してください。
Kerberosチケット: バイナリ認証およびセッション・トークン。詳細は、「Kerberosトークン」を参照してください。
Security Assertion Markup Language (SAML)アサーション: XMLドキュメントを使用して、インターネット上でセキュリティ情報を共有します。詳細は、「SAMLトークン」を参照してください。
ユーザー名トークンはBasic認証情報を伝達します。username-token要素は、メッセージを認証するためにユーザー名とパスワードの情報を伝播します。
X.509デジタル証明書は、受信パーティに公開鍵を送信するために設計された署名付きデータ構造です。証明書には、証明書ID、発行者の識別名(DN)、有効期間、所有者のDN、所有者の公開鍵などの標準フィールドが含まれています。
証明書は、認証局(CA)によって発行されます。CAは、エンティティのアイデンティティを検証して証明書を付与し、CAの秘密鍵で署名します。CAは、公開鍵が含まれる独自の証明書を発行します。
各ネットワーク・エンティティには、信頼するCAの証明書のリストがあります。別のエンティティと通信する前に、指定されたエンティティはこのリストを使用して、別のエンティティの証明書の署名が信頼できるCAのものであることを検証します。
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トークンを使用できます。
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による(ファイル、アプリケーション、Webサービスなどの)リソースRに対する(読取り、書込みなどの)アクションAを証拠Eに基づいて許可するかどうかを決定する認証局によって発行されます。
SAMLアサーションは埋込み可能です(つまり、SAMLアサーションには別のSAMLアサーションを含めることができます)。SAMLアサーションには、(XML署名を使用した)署名または(XML暗号化を使用した)暗号化、あるいはその両方を行うこともできます。
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アタッチメント・ポリシーに関する項を参照してください。
OWSMには、Web Services Trust (WS-Trust 1.3)およびWeb Services Secure Conversation (WS-SecureConversation 1.3)の仕様を実装しています。これらの仕様の組合せによって、Webサービスとそのクライアント間のセキュア通信が実現されます。
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の有効化と構成を可能にする構成設定が含まれています。
この項の内容は次のとおりです。
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サービスが要求する認証メカニズムは変わりません。認証操作の実行頻度のみが変わります。 |
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によるタイムスタンプの署名が格納されます。
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ポリシーにアタッチしてください。
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)とWeb Services Trust Language (WS-Trust)で構築された拡張機能が定義されています。
この仕様は、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が保持されます。
クライアント・セッションは、「参照」という用語で表現されます。これは、メッセージ通信を可能にするクライアント・ポート/バインディングと類似する概念です。
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が保持されます。
次のシナリオでは、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サービスに渡す必要がある場合があります。
すべてのユーザー用に単一のセキュア通信セッションが作成されます。
SAML送信者保証付きID伝播ポリシーの場合にのみ、再認証制御を有効化できます。再認証は、アプリケーション・メッセージごとにユーザーIDが異なる可能性があるときに使用します。この場合、各メッセージでユーザーが認証されます。
クライアント・アイデンティティを使用してブートストラップが実行され、サービスへのすべてのアプリケーション・リクエストでエンド・ユーザー・アイデンティティが渡されます。WS-SecureConversationを使用することによって、主にメッセージ保護における利点が得られます。セッション中にメッセージごとに認証トークンを送信した場合、その分パフォーマンスが犠牲になるからです。
デフォルトでは、WS-SecureConversationでの再認証制御は設定されていません。再認証制御は、WS-SecureConversationが有効化されている場合にのみ有効化できます。
OWSMにおけるWS-SecureConversation実装では、セキュア通信ポリシーには、実際には内部と外部の2種類のポリシーが含まれます。
ブートストラップ(内部)ポリシーは、トークンの取得と、クライアントとWebサービス間のハンドシェイクの確立に使用されます。外部ポリシーは、トークンを使用したリクエストの実行時にアプリケーション・メッセージに対して使用されます。
oracle/wss11_username_with_message_protectionなどの元のOWSM WS-Securityポリシーから、外部ポリシーのメッセージ・セキュリティ設定が取得されます。その後、外部ポリシーから、内部ポリシーのメッセージ・セキュリティ設定が導出されます。
したがって、ほとんどの場合、内部および外部ポリシーはOWSMによって処理されるため、これらのポリシーの詳細を意識する必要はありません。ただし、OWSMのWS-SecureConversation実装には、追加制御のための「詳細」画面(図3-2)があります。
次の「詳細」オプションを使用できます。
クライアント・エントロピ
サーバー・エントロピ
導出キー
ブートストラップ・メッセージ・セキュリティ:
アプリケーション設定から継承
独立した設定を使用:
アルゴリズム・スイート
署名の暗号化
署名確認
タイムスタンプを含める
これらのオプションの設定の詳細は、Oracle Infrastructure Webサービスの開発のセキュア通信: 拡張管理の構成に関する項を参照してください。
この項では、セッションの永続性の管理方法について説明します。
OWSMには、Coherenceクラスタとメモリー内永続性プロバイダをサポートする、デフォルトのドメイン全体の永続性の実装が含まれています。
Coherence永続性プロバイダがWebLogic Serverで実行されている場合は、このプロバイダが、Webサービス・クライアントとWebサービスの両方に対してデフォルトになります。それ以外の場合は、メモリー内プロバイダがデフォルトになります。
セッション・リカバリの永続性粒度レベルは、セッション・オブジェクトです。
この永続性の実装は、デフォルトで有効になっており、構成を行う必要はまったくありません。
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トークンの構成に関する項を参照してください。
クライアントからのリクエストを処理するために、サービスが別のサービスまたはサーバーにアクセスする必要がある場合があります。Kerberosでは、このような接続を確立するために、クライアントのユーザー・アカウントと認可レベルを使用して、2番目のサービスまたはサーバーに対して最初のサービスを認証する必要があります。Kerberosは、この要件を満たすための、資格証明の委任と呼ばれるメカニズムを備えています。
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サービスの保護とポリシーの管理の資格証明の委任の構成に関する項を参照してください。
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-Authentiate: Negotiate 74900a2a....のようになります。
クライアントはこのデータをデコードし、新しいデータをサーバーに返信します。セキュリティ・コンテキストが確立されるまで、このサイクルが続行されます。
SPNEGOでKerberosを使用するためのOWSMの構成の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のSPNEGOネゴシエーションでのKerberosの構成に関する項を参照してください。
Web Services Secure Conversation (WS-SecureConversation)の仕様には、導出キーと呼ばれる機能が含まれています。この機能では、相互に認証済の二者が、共通の秘密を使用して、メッセージの署名や暗号化などの様々な用途で追加のキーを導出できます。また、WS-SecureConversationの仕様では、次の2つのタイプの導出キーが定義されています。
明示的な導出キー: wsc:DerivedKeyToken要素を使用して、トークン情報が格納されます。そして、この情報の参照がds:KeyInfo要素に格納されます。
暗黙的な導出キー: ds:KeyInfo要素にトークン情報が直接格納されます。
WS-SecureConversationのコンテキストでKerberosを使用する場合は、Kerberosに関するOWSMアサーションで「導出キーの使用」オプションを有効化することによって、導入キーを使用するようにOWSMを構成できます。
Web Services Addressing(WS-Addressing)の仕様(http://www.w3.org/TR/ws-addr-core/)は、Webサービスおよびメッセージに対応する、特定のトランスポートに依存しないメカニズムを提供します。特に、仕様では、Webサービス・エンドポイントの識別とメッセージ内のエンドツーエンドのエンドポイント・アイデンティティの保護に使用されるXML要素の数が定義されます。
SOAPには、メッセージの送信先やレスポンスまたはフォルトを返す標準的な方法がありません。WS-Addressingは、Webサービスのエンドポイントを識別し、メッセージにおけるエンド・ツー・エンドのエンドポイント識別を確保するXMLフレームワークを提供します。
Webサービス・エンドポイントは、Webサービスがメッセージを送信するリソース(アプリケーションやプロセッサなど)です。
次の例は、WS-Addressingを使用したものです(wsaはWS-Addressingのネームスペースです)。
例3-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 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の使用を検討したほうがよいシナリオの例を次に示します。
トークンの交換/変換: ある種類のトークンを別のタイプのトークンに交換する必要がある場合を想定してください。たとえば、クライアントが保持しているトークンがKerberosトークンであるときに、WebサービスからはSAMLトークンを要求されている場合があります。STSを使用することで、KerberosトークンをSAMLトークンに交換できます。
フェデレーション: アイデンティティ・フェデレーションを使用して、ユーザーは複数のサービス・プロバイダで構成した多数のローカル・アイデンティティを統合できます。フェデレーテッド・アイデンティティを使用することで、個々のユーザーは1つのサービス・プロバイダ・サイトにログインした後、再認証もアイデンティティの再確立も行うことなく、関連するサービス・プロバイダ・サイトに移動できます。
たとえば、STSを使用して、クライアント・ユーザー名を、Webサービスによって要求されるユーザー名にマップできます。
信頼の集中化: STSはWebサービス・クライアントとWebサービスの両方から信頼されます。この信頼を使用して、相互運用可能なセキュリティ・トークンを提供します。
図3-3に示すトークン交換シナリオについて、考えてみてください。このシナリオでは、カスタマのデスクトップ・アプリケーション(.NET Webサービスなど)が、SAMLトークンを受け入れることができるバックエンドのWebサービスと通信します。
図3-3では、joeというユーザーがデスクトップにログインし、Kerberosチケットが作成されます。ユーザーがデスクトップ・アプリケーションを開いて、操作を実行すると、バックエンドのWebサービスがコールされます。この場合、joeというアイデンティティをバックエンドのアプリケーションに伝播させる必要があります。しかし、クライアント側にあるのはKerberosトークンであり、バックエンドのWebサービスはSAMLトークンしか受け入れません。STSを使用することで、トークンの変換または交換を実行できます。
KerberosプロトコルをサポートするようにOWSMを構成する方法の詳細は、Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理のWS-Trustの構成に関する項を参照してください。
WS-ReliableMessagingによって、信頼性のあるメッセージ交換が行われます。ソフトウェア・コンポーネント、システムまたはネットワークの障害に関係なく、分散アプリケーション間でメッセージの信頼性のある配信が確実に行われる必要があります。順序付き配信が保証されているため、クライアント・アプリケーションごとに、失敗したメッセージの自動再送信をコーディングする必要はありません。
Webサービスで次の問題が発生している場合は、信頼できるメッセージングの使用を検討してください。
ネットワーク障害や接続の切断
メッセージの転送中の消失
メッセージの順不同での宛先への到着
WS-ReliableMessagingでは、メッセージの送信元と宛先はクライアント・サーバー・モデルに依存しないものとみなされます。つまり、クライアントとサーバーはそれぞれ、通信パスでメッセージの送信元および宛先の両方として同時に機能できます。
WS-ReliableMessaging (WS-RM)の詳細は、Oracle Infrastructure Webサービスの開発の Web Services Reliable Messagingの使用に関する項を参照してください。
