| Oracle® Fusion Middleware Oracle Service Bus開発者ガイド 11gリリース1 (11.1.1.6.2) B61435-05 |
|
 前 |
 次 |
この章では、Oracle Service Bus (OSB)のカスタム・トランスポート・レベルおよびメッセージ・レベルの認証を構成する方法について説明します。
Oracle Service Busは、トランスポートとメッセージの両レベルのプロキシ・サービス・リクエストについて、クライアントで指定されたカスタム認証の資格証明をサポートしています。カスタム認証の資格証明はトークンの形であったり、ユーザー名とパスワード・トークンの組合せということもあります。
Oracle Service Busは、HTTPヘッダーやSOAPヘッダー(SOAPベースのプロキシ・サービスの場合)、またはペイロード(非SOAPプロキシ・サービスの場合)でプロキシ・サービスに渡されるカスタム・トークンを受け入れて、認証しようとします。プロキシ・サービス構成ウィザードを使用して、トークンが渡されるメカニズムとトークン・タイプによりプロキシ・サービスを構成します。
また、Oracle Service Busは、SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)またはペイロード(非SOAPプロキシ・サービスの場合)で渡されるユーザー名とパスワード・トークンを受け入れて認証しようとします。プロキシ・サービス構成ウィザードを使用して、ユーザー名とパスワードが渡されるメカニズムによって、プロキシ・サービスを構成します。
|
注意: カスタム認証のメカニズムは、単独またはWebサービスのメッセージ・レベルのセキュリティとともに機能します。これについては、第52章「Webサービスのメッセージ・レベルでのセキュリティの構成」で説明しています。両方のタイプのセキュリティの使用については、54.9項「WS-Securityおよびカスタム・ユーザー名/パスワードとトークンの組合せ」を参照してください。 |
以下のカスタム認証メカニズムがサポートされています。
トランスポート・レベルのセキュリティ
HTTPヘッダーのカスタム・トークン
メッセージ・レベルのセキュリティ
SOAPベースのプロキシ・サービスの場合
SOAPヘッダーのカスタム・トークン
SOAPヘッダーのユーザー名/パスワード
非SOAPベースのプロキシ・サービスの場合
任意のXMLベースのプロキシ・サービスのペイロードに含まれるカスタム・トークン
任意のXMLベースのプロキシ・サービスのペイロードに含まれるユーザー名/パスワード
この章の内容は以下のとおりです。
認証トークンは、文字列やXMLで表される何らかのデータで、X509クライアント証明書などのエンティティ(ユーザーまたはプロセス)を識別します。認証トークンは通常、特定のセキュリティ・プロトコル内で使用されることを意図しています。暗号により保護されている認証トークンもあれば、そうでないものもあります。一部の認証トークンは、重要なキー・マテリアルを持っています。
Oracle Service Busの文脈では、カスタム認証トークンはユーザー名/パスワードであったり、リクエスト内のユーザー定義の場所にある不透明なIDアサーション・トークンであることもあります。ユーザー名/パスワード・トークンは、SOAPヘッダー(SOAPベースのサービスの場合)または非SOAPプロキシ・サービスのペイロードで使用されます。IDアサーション・トークンは、HTTPヘッダーやSOAPヘッダー(SOAPベースのサービスの場合)、あるいは非SOAPプロキシ・サービスのペイロード内で使用可能です。Oracle Service Busドメインには、トークン・タイプをサポートするIDアサーション・プロバイダを含める必要があります。
Oracle Service Busは、認証されたユーザーを使用して、クライアントのセキュリティ・コンテキストを確立します。カスタム・トークンやユーザー名/パスワードを認証することで確立されたセキュリティ・コンテキストは、アウトバウンド資格証明のマッピングおよびアクセス制御の基礎として使用できます。
認証のためにトークンを提供するクライアントの認証と認可を行うには、クライアントの資格証明をOracle Service BusユーザーにマップするIDアサーション・プロバイダを構成する必要があります。Oracle Service Busはこのユーザー名を使用して、クライアントのセキュリティ・コンテキストを確立します。
Oracle Service Busであらたにカスタム認証トークンがサポートされることにより、2つの顧客ニーズに対応します。1番目のシナリオでは、プロキシ・サービスのリクエストのメッセージ・ペイロードのどこか(SOAPヘッダーなど)にユーザー名/パスワードがある場合です。Oracle Service Busは、このユーザー名/パスワードを取得して、ユーザーを認証する必要があります。
2番目のシナリオでは、メッセージにsecure-token-xyzトークンなど何らかの認証トークン(ユーザー名/パスワード以外)が含まれている場合です。トークンは、HTTPヘッダーまたはメッセージのペイロード内にある場合があります。Oracle Service Busは、このトークンを取得して認証する必要があります。どちらの場合でも、認証に成功するとセキュリティ・コンテキストが確立されます。
セキュリティ関連の構成の多くは通常、デプロイメントのときに行われ、カスタム認証はそのモデルに適合します。デプロイメントのときに本番環境で直接構成できます。または、ステージングの際に認証を構成して、それを本番環境にインポートすることもできます。
カスタム認証(ユーザー名/パスワード・トークンとカスタム・トークンを含む)は、プロキシ・サービスの定義の中核です。プロキシ・サービスがエクスポートされるとき、カスタム・トークンのすべての構成がjarファイルに含まれます。新しいバージョンのプロキシ・サービスがインポートされる場合、前の構成はこのjarファイルに含まれる構成にオーバーライドされます。
IntegrationDeployerロールまたはIntegrationAdministratorロールのユーザーのみが、カスタム・トークンの認証を構成できます。IntegrationOperatorロールまたはIntegrationMonitorロールのユーザーは、この構成に対して読取り専用のアクセス権限を持っています。
カスタム認証トークンを使用して、トランスポートレベルでクライアントのリクエストを認証できます。カスタム・トークンは、HTTPヘッダーで指定します。サービス定義ウィザードのHTTP(およびHTTPS)構成ページを使用すると、クライアントの認証を構成できます。HTTPおよびHTTPSプロキシ・サービスのオプションは以下のとおりです。
なし
基本
カスタム認証
クライアント証明書(HTTPSのみ)
これらのオプションは同時に複数選択することはできません。
カスタム認証を選択した場合、トークンを送信するHTTPヘッダー名とトークン・タイプも指定する必要があります。
トランスポート・レベルのカスタム資格証明を構成する手順については、2.3項「プロキシ・サービスの操作」で説明しています。
カスタム認証のトークンには、任意のアクティブなトークン・タイプで、以前にIDアサーション・プロバイダ用に構成され、HTTPヘッダーで送信されたものを使用できます。
使用する予定のトークン・タイプを処理するIDアサーション・プロバイダを、構成あるいは作成して構成する必要があります。54.5項「カスタム・トークン用IDアサーション・プロバイダの構成」を参照してください。
トランスポート・レベルのカスタム資格証明を構成し終わったら、さらにメッセージ・レベルのセキュリティ構成を構成することができます。この方法については、第52章「Webサービスのメッセージ・レベルでのセキュリティの構成」を参照してください。
トランスポート・レベルのカスタム認証トークンは、UDDIにパブリッシュされます。client-authプロパティは、認証の構成時にHTTPまたはHTTPSトランスポート属性のinstanceParmsにあります。『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「トランスポート属性」にあるように、client-authの有効な値はBASIC、CLIENT-CERTおよびCUSTOM-TOKENです。値がCUSTOM-TOKENの場合は、さらにtoken-headerとtoken-typeという2つのプロパティが必ず存在します。
|
注意: Oracle Service Busビジネス・サービス定義は、カスタム・トークン認証をサポートしていません。client-authがCUSTOM-TOKENであるUDDIからサービスをインポートする場合、認証の構成が何もないかのようにサービスがインポートされます。 |
Oracle Service Busは、プロキシ・サービスのメッセージ・レベルのリクエストについて、クライアントで指定されたカスタム認証の資格証明をサポートしています。カスタム認証の資格証明は、カスタム・トークン、またはユーザー名とパスワードの形式になります。
Oracle Service Busは、SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)、またはペイロード(非SOAPプロキシ・サービスの場合)でプロキシ・サービスに渡されるカスタム・トークンを受け入れて、認証しようとします。プロキシ・サービス構成ウィザードを使用して、トークンが渡されるメカニズムとトークン・タイプによりプロキシ・サービスを構成します。
また、Oracle Service Busは、SOAPヘッダー(SOAPベースのプロキシ・サービスの場合)またはペイロード(非SOAPプロキシ・サービスの場合)で渡されるユーザー名とパスワード・トークンを受け入れて認証しようとします。プロキシ・サービス構成ウィザードを使用して、ユーザー名とパスワードが渡されるメカニズムによって、プロキシ・サービスを構成します。
現在サポートされているプロキシ・サービスのメッセージ・レベルの認証メカニズムは以下のとおりです。
SOAPベースのプロキシ・サービスの場合
SOAPヘッダーのカスタム・トークン
SOAPヘッダーのユーザー名/パスワード
非SOAPベースのプロキシ・サービスの場合
任意のXMLベースのプロキシ・サービスのペイロードに含まれるカスタム・トークン
任意のXMLベースのプロキシ・サービスのペイロードに含まれるユーザー名/パスワード
メッセージ・レベルのカスタム・トークン、およびメッセージ・レベルのユーザー名とパスワードが、以下のバインディング・タイプのプロキシ・サービスでサポートされます。
WSDL-SOAP
WSDL-XML
抽象SOAP
抽象XML
混合 - XML(リクエスト内)
混合 - MFL(リクエスト内)
カスタム・ユーザー名/パスワードとカスタム・トークンの構成は、ほぼ同じです。どちらの場合も、Oracle Service Busで必要な情報を検索できるようにするためのXPath式を指定します。これらのXPath式のルートは以下のとおりです。
サービスのバインドがanySOAPまたはWSDL-SOAPの場合は、soap-env:Envelope/soap-env:Headerを使用します。
サービスのバインドがSOAPベースでない場合は、soap-env:Body(具体的には、$body変数の内容)を使用します。
|
注意: すべてのXPath式は有効なXPath 2.0形式である必要があります。使用するネームスペースをXPath式で宣言するには、次のようなXPathの"declare namespace"構文を使用します。 declare namespace ns='http://webservices.mycompany.com/MyExampleService'; 例: declare namespace y="http://foo";./y:my-custom-token/text() |
IDアサーション・プロバイダは特定の形式の認証プロバイダで、ユーザーやシステム・プロセスが自らのトークンを使用してIDをアサートできるようにします。クライアントのIDは、クライアントから提供されるトークンを使用することにより確立されます。IDアサーション・プロバイダは、トークンを検証します。トークンが正常に検証されると、IDアサーション・プロバイダはトークンをOracle Service Busのユーザー名にマップし、ユーザー名を戻します。トークンがユーザー名にマップされることを、IDが「アサート」されたといいます。Oracle Service Busは、このユーザー名を使用してクライアントのセキュリティ・コンテキストを確立します。
プロキシ・サービスでカスタム・トークンを消費するには、提供されたOracle WebLogic ServerのIDアサーション・プロバイダをチェックして、ニーズに合うかを確認してください。Oracle WebLogic Serverには、以下のような幅広いIDアサーション・プロバイダが含まれています。
WebLogic IDアサーション・プロバイダは、X.509およびIIOP-CSIv2トークンを検証します。必要に応じてユーザー名マッパーを使用し、そのトークンをユーザーにマップできます。
SAML IDアサーション・プロバイダは、SAMLセキュリティ・アサーションのコンシューマとして機能します。
Oracle Service Busプロキシ・サービスで、secure-token-xyzトークンなど、バンドルされたIDアサーション・プロバイダにより処理されないカスタム・トークンを消費する場合、ユーザー(またはサードパーティ)は最初にトークン・タイプをサポートするOracle WebLogic Server IDアサーション・プロバイダを記述し、Oracle WebLogic Server管理コンソールを使用して、そのプロバイダをセキュリティ・レルムに追加する必要があります。
IDアサーション・プロバイダを開発して、ユーザーのIDをアサートするときに使用する特定のタイプのカスタム・トークンをサポートします。複数のトークン・タイプをサポートするために、IDアサーション・プロバイダを開発することができます。1つのセキュリティ・レルムに、同じトークン・タイプを検証する機能を備えた複数のIDアサーション・プロバイダを持つことはできますが、この検証を実際に実行できるのは、1つのIDアサーション・プロバイダだけです。
IDアサーションのプロセスを図54-1に示します。プロセスは以下のようになります。
プロキシ・サービスがインバウンド・リクエストから認証トークンを取得します。
そのタイプのトークンの検証を担当し、「アクティブ」として構成されているIDアサーション・プロバイダにトークンが渡されます。
IDアサーション・プロバイダは、トークンを検証します。
トークンが正常に検証されると、IDアサーション・プロバイダはトークンをユーザー名にマップし、ユーザー名を戻します。
それからOracle Service Busは、このユーザー名を使用して認証プロセスを続け、成功した場合は認証されたサブジェクトを取得します。
Oracle Service Busは、セキュリティ・コンテキストを作成します。カスタム・トークンやユーザー名/パスワードを認証することで確立されたセキュリティ・コンテキストは、アウトバウンド資格証明のマッピングおよびアクセス制御の基礎として使用できます。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のIDアサーションおよびトークンに関する項を参照してください。
トランスポート・レベルのIDアサーションの場合、ヘッダーの値はjava.lang.StringとしてIDアサーション・プロバイダに渡されます。メッセージ・レベルのIDアサーションの場合は、XPath式が次のように評価されます。
XPath式が複数のノードを戻す場合、エラーが発生してIDアサーションは呼び出されません。
XPath式が空の結果を戻す場合、nullの引数を持つIDアサーションが呼び出されます。
XPath式がタイプTEXTまたはATTRの単一のトークンを戻す場合(http://xmlbeans.apache.org/docs/2.0.0/reference/org/apache/xmlbeans/XmlCursor.TokenType.htmlにあるXmlCursor.TokenTypeを参照)、テキスト・ノードの文字列の値または属性が渡されます(XmlCursor.getStringValue()によって戻される場合と同じように)。それ以外の場合は、単一のXmlObjectが渡されます。
これらのタスクを完了するために必要な手順は、以下のOracle WebLogic Serverのドキュメントで詳しく説明されています。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項では、IDアサーション・プロバイダにカスタムのトークン・タイプを作成する方法について説明しています。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』では、Oracle WebLogic Server管理コンソールでのIDアサーション・プロバイダの構成方法について説明しています。
参考までに、IDアサーション・プロバイダ用のカスタム・トークン・タイプを作成する手順と、そのプロバイダをOracle WebLogic Server管理コンソールで構成する手順について、ここで簡単にふれています。ただし、実際にこのタスクを完了するには、Oracle WebLogic Serverのドキュメントに目を通す必要があります。
カスタムのIDアサーション・プロバイダは、以下の手順によって開発できます。
新しいトークン・タイプを作成します。『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の適切なSSPIを使用したランタイム・クラスの作成に関する項。この項では、SampleIdentityAsserterProviderImpl.javaクラスについて説明しています。これは、サンプルのIDアサーション・プロバイダのランタイム・クラスです。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』のWebLogic MBeanMakerによるMBeanタイプのタイプの作成に関する項。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の管理コンソールによるカスタムIDアサーション・プロバイダの構成に関する項。
アクティブなトークン・タイプを定義します。このタスクについては、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のIDアサーション・プロバイダの構成に関する項と、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダの構成用に新しいトークン・タイプを使用可能にする方法に関する項を参照してください。
カスタムのIDアサーション・プロバイダを構成するときは、「サポートされている種類」フィールドにIDアサーション・プロバイダがサポートしているトークン・タイプのリストが表示されます。「アクティブな種類」フィールドにゼロまたはそれ以上のサポートされているタイプを入力します。
「サポートされている種類」フィールドの内容は、カスタムIDアサーション・プロバイダのMBeanタイプを生成するために使用するMBean定義ファイル(MDF)のSupportedTypes属性から取得されます。サンプルIDアサーション・プロバイダの例を例54-1に示します。MDFおよびMBeanタイプの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』のWebLogic MBeanMakerによるMBeanタイプの生成に関する項を参照してください。
例54-1 SampleIdentityAsserter MDF : SupportedTypes属性
<MBeanType>
...
<MBeanAttribute
Name = "SupportedTypes"
Type = "java.lang.String[]"
Writeable = "false"
Default = "new String[] {"SamplePerimeterAtnToken"}"
/>
...
</MBeanType>
同様に、「アクティブな種類」フィールドの内容は、MBean定義ファイル(MDF)のActiveTypes属性から取得されます。MDFファイルのActiveTypes属性をデフォルトに設定すると、Oracle WebLogic Server管理コンソールで手動設定する必要がなくなります。サンプルIDアサーション・プロバイダの例を例54-2に示します。
例54-2 SampleIdentityAsserter MDF: Defaultを使用したActiveTypes属性
<MBeanAttribute
Name= "ActiveTypes"
Type= "java.lang.String[]"
Default = "new String[] { "SamplePerimeterAtnToken" }"
/>
ActiveTypes属性のデフォルト化は便利ですが、他のIDアサーション・プロバイダがそのトークン・タイプを検証することがない場合にのみ行うようにします。その場合以外は、無効なセキュリティ・レルムが構成されることになるおそれがあります(複数のIDアサーション・プロバイダが同じトークン・タイプを検証しようとします)。一番良いのは、IDアサーション・プロバイダのすべてのMDFがデフォルトでそのトークン・タイプをオフにすることです。その場合、そのトークン・タイプを検証するIDアサーション・プロバイダを構成して手作業でアクティブにすることができます。
結局のところ、カスタム認証はトランスポート・レベルのセキュリティのために構成します。ただし、プロセスのこの段階に行き着く前に、まず使用を予定するトークン・タイプを認識するIDアサーション・プロバイダを構成、あるいは作成して構成する必要があります。
これらのタスクを完了するために必要な手順は、以下のOracle WebLogic Serverのドキュメントで詳しく説明されています。
バンドルされたIDアサーション・プロバイダのいずれかがニーズに合う場合、このIDアサーション・プロバイダをOracle WebLogic Server管理コンソールで構成する手順については、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のIDアサーション・プロバイダの構成に関する項を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』では、IDアサーション・プロバイダ用のカスタム・トークン・タイプの作成方法について説明しています。
『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のIDアサーション・プロバイダの構成に関する項では、Oracle WebLogic Server管理コンソールでIDアサーション・プロバイダを構成する方法について説明しています。
カスタム認証によるトランスポート・レベルのセキュリティの構成手順は、以下のとおりです。
使用するカスタム・トークンの形式を決定します。
既存のプロバイダがニーズに合うかどうかを判断します。このタスクの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの選択に関する項を参照してください。
トークンの形式をサポートするIDアサーション・プロバイダを、構成あるいは作成してから構成してください。
IDアサーション・プロバイダは、トークンをユーザー名にマップします。クライアントのユーザー名をOracle Service Busの「セキュリティ構成」モジュールに追加してください。
プロトコル依存のトランスポート構成ページで、Oracle Service Busがトークンと認証トークン・タイプを検索する認証ヘッダーを指定します。構成されたIDアサーション・プロバイダに対してアクティブなトークン・タイプのみが表示されます。
最終的には、カスタム認証によるメッセージ・レベルのセキュリティを構成します。ただし、プロセスのこの段階に行き着く前に、まず使用を予定するトークン・タイプを認識する認証プロバイダまたはIDアサーション・プロバイダを構成、あるいは作成して構成する必要があります。
これらのタスクを完了するために必要な手順は、以下のOracle WebLogic Serverのドキュメントで詳しく説明されています。
バンドルされた認証プロバイダまたはIDアサーション・プロバイダのいずれかがニーズに合う場合、この認証プロバイダをOracle WebLogic Server管理コンソールで構成する手順については、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項では、IDアサーション・プロバイダにカスタムのトークン・タイプを作成する方法について説明しています。
『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のIDアサーション・プロバイダの構成に関する項では、Oracle WebLogic Server管理コンソールでIDアサーション・プロバイダを構成する方法について説明しています。
カスタム認証によるメッセージ・レベルのセキュリティの構成手順は、以下のとおりです。
使用するカスタムのユーザー名/パスワードまたはトークンの形式を決定します。
既存のプロバイダがニーズに合うかどうかを判断します。このタスクの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの選択に関する項を参照してください。
いずれかの コンテキスト・プロパティ を指定した場合、プロバイダは処理するプロパティ名を知っておく必要があるため、おそらく独自のプロバイダを作成する必要があります。
ユーザー名/パスワードまたはトークンの形式をそれぞれサポートする認証プロバイダあるいはIDアサーション・プロバイダを、構成または作成してから構成します。また、このプロバイダは、提供するすべての コンテキスト・プロパティ を認識する必要があります。
クライアントのユーザー名をOracle Service Busの「セキュリティ構成」モジュールに追加します。
「セキュリティ」ページで、必要に応じて、「ユーザー名XPath」、「ユーザー・パスワードXPath」、「トークン・タイプ」およびトークン・パスに新規または既存のプロキシ・サービスを構成します。
入力するすべてのコンテキスト・プロパティの「プロパティ名」と「値セレクタ」を指定します。
カスタムのトークンまたはカスタムのユーザー名/パスワードにより確立されるセキュリティ・コンテキストは、決して一意ではなく、それを資格証明のマッピングに使用できます。トランスポート・レベルの認証とメッセージ・レベルの認証を両方とも実装する場合、メッセージ・レベルのセキュリティ・コンテキストは、常に資格証明のマッピングとIDの伝播に使用されます。
たとえば、プロキシ・サービスがSOAPヘッダーのsecure-token-xyzトークンによってクライアントを認証する場合、マップされたすべてのサービス・アカウントのルックアップ中に、認証されたサブジェクトが使用されます。サブジェクトはアウトバウンド・メッセージ上でSAMLトークンが生成されるときにも使用されます。また、カスタム・トークンまたはカスタムのユーザー名/パスワードに関連する認証コンテキストの下で、Javaコールアウトが実行可能です。
カスタムのユーザー名/パスワードを使用する場合、パススルー・サービス・アカウントが使用されるときは、カスタム・トークン内のユーザー名/パスワードをアウトバウンドHTTP BASICまたはアウトバウンドWS-Securityユーザー名トークンの認証に使用できます。
Oracle Service Busプロキシ・サービスは、トランスポート・レベルのセキュリティ(HTTPSなど)とメッセージ・レベルのセキュリティ(WS-Securityやカスタム・トークンなど)のどちらか、あるいは両方の組合せを使用して保護できます。つまり、Oracle Service Busプロキシ・サービスは、トランスポート・レベルの認証とメッセージ・レベルの認証の両方を使用して構成できます。
たとえば、クライアントのリクエストをHTTPヘッダーのカスタム・トークンを使用してトランスポート・レベルで認証したり、Webサービスのセキュリティ・ヘッダーを除く、WSSセキュリティ・トークンやカスタム・トークン、ユーザー名/パスワードを使用して、メッセージ・レベルで認証したりできます。
ただし、以下の制限に注意してください。WS-Securityとメッセージ・レベルのカスタム・トークンを組み合せることは可能ですが、WS-SecurityポリシーはWS-Securityトークンに基づいてプロキシ・サービス認証を要求することは できません 。メッセージ・レベルのカスタム・トークンとWS-Securityプロキシ・サービス認証は、同時に両方を選択することはできません。
以下の相違点について考察します。
SOAPヘッダー<foo:MyToken>にタイプがMyTokenのカスタム・トークンを想定し、何らかのメッセージ部分(<foo:MyToken>ヘッダーおよびSOAP本体など)の署名や暗号化を要求するWS-Securityポリシーを持つプロキシ・サービスを構成することは可能です。
ヘッダー<foo:MyToken>にカスタム・トークンを要求し、SAMLトークンや他の形式の認証を要求するWS-Securityポリシーも持っているプロキシ・サービスを構成することはできません。
