| Oracle® Fusion Middleware Oracle WebLogic Server Web サービス入門 11g リリース 1 (10.3.1) B55566-01 |
|
 戻る |
 次へ |
Oracle は Microsoft とともに、WebLogic Server を使用して作成された Web サービスが Microsoft Windows Communication Foundation (WCF)/.NET 3.0 および 3.5 Framework を使用して作成された Web サービスにアクセスしたり、それを消費したりできるようにするための相互運用性のテストを実施しています。詳細については、http://msdn2.microsoft.com/en-us/netframework/default.aspx を参照してください。
相互運用性テストは、次の表に示す領域に関し、JAX-WS および JAX-RPC Web サービスを使用して実施しました。
表 3-1 実施した相互運用性テスト
| 領域 | 相互運用性ガイドライン |
|---|---|
|
基本データ型と複合データ型 |
|
|
WS-I Basic Profile 1.1 |
Basic Profile 1.1 の相互運用性ガイドライン |
|
Web Services Security (WS-Security) 1.0 および 1.1 |
|
|
Web Services Security Policy (WS-SecurityPolicy) 1.2 |
WS-SecurityPolicy の相互運用性ガイドライン |
|
Web Services Secure Conversation Language (WS-SecureConversation) 1.3 |
WS-SecureConversation の相互運用性ガイドライン |
|
Web Services Policy Framework (WS-Policy) 1.5 |
相互運用性ガイドラインは存在しない |
|
Web Services Addressing (WS-Addressing) 0.9 および 1.0 |
なし |
|
MTOM (メッセージ転送最適化メカニズム) |
なし |
|
Web Services Reliable Messaging (WS-ReliableMessaging) 1.0 および 1.1 |
WS-ReliableMessaging の相互運用性ガイドライン 注意 : JAX-RPC でのみテスト |
|
Web Services Trust (WS-Trust) 1.3 |
注意 : JAX-RPC でのみテスト |
上記に加え、以下のような機能の組み合わせもテストしました。
MTOM と WS-Security
WS-ReliableMessaging と MTOM (JAX-RPC のみ)
WS-ReliableMessaging 1.1 と WS-Addressing 0.9 および 1.0 (JAX-RPC のみ)
WS-ReliableMessaging 1.0 と WS-Addressing 0.9 および 1.0 (JAX-RPC のみ)
WS-ReliableMessaging 1.1 と WS-SecureConversation 1.3 (JAX-RPC のみ)
WS-ReliableMessaging 1.0 と WS-SecureConversation 1.3 (JAX-RPC のみ)
WS-Policy 1.5 と WS-SecurityPolicy 1.2
以下の節では、テストにおいて特定された相互運用上の問題とガイドラインについて説明します。
Microsoft .NET 3.0/3.5 で anyType クラスを使用している場合、どの Java データ型が返されるかは保証されません。特定の Java データ型を返す必要がある場合は、anyType を使用しないようにしてください。
JAX-WS 2.0 では WS-I Basic Profile 1.1 への厳格な準拠が求められます。Microsoft .NET 3.0/3.5 フレームワークでは、Sun Java Web サイト (http://java.sun.com/webservices/reference/tutorials/wsit/doc/DataBinding7.html) に記載の使用事例に関して、Basic Profile 1.1 の厳格なセマンティクスが強制されません。
以下に、WS-Security の相互運用性ガイドラインを示します。
<sp:Strict> レイアウト アサーションの仕様は保証されません。次に例を示します。
<sp:Layout> <wsp:Policy> <sp:Strict/> </wsp:Policy> </sp:Layout>
代わりに、次のように独自のポリシーを定義してください。
<sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout>
以下のアサーションは、Microsoft .NET 3.0/3.5 ではサポートされません。
UsernameToken でのダイジェスト パスワード
<sp:EncryptedSupportingTokens>
要素レベルのシグネチャ
要素レベルの暗号化
WS-Security 1.1 の非対称バインディングのサポートは、Microsoft .NET 3.0/3.5 では保証されません。
このリリースでは、WebLogic Server および Microsoft .NET 3.5 は Web Services Security Policy (WS-SecurityPolicy) 1.2 をサポートします。Microsoft .NET 3.0 では、SecurityPolicy 仕様の 2005 年 12 月のドラフト バージョンがサポートされています。
2005 年 12 月のドラフト バージョンでは、<sp:SignedEncryptedSupportingTokens> ポリシー アサーションがサポートされていません。そのため、Microsoft .NET 3.0 では、UsernameToken を<sp:SignedSupportingTokens> ポリシー アサーションで暗号化します。UsernameToken を暗号化せずに <sp:SignedSupportingTokens> ポリシー アサーションを使用する場合、WebLogic Server と Microsoft .NET Web Services は相互運用できません。
以下に、WS-SecureConversation の相互運用性ガイドラインを示します。
HTTPS 認証での WS-SecureConversation トークンの使用 (<sp:EndorsingSupportingTokens> 内) はサポートされません。
セキュリティ上の必要性がない限り、<sp:EncryptBeforeSigning/> は使用しないことをお勧めします。代わりに、<sp:SignBeforeEncrypt> (デフォルト) を使用してください。
WebLogic Server の Web サービスではクッキー モードの会話がサポートされますが、この機能は Microsoft 独自の実装であり、他のベンダではサポートされない可能性があります。
<sp:BootstrapPolicy> ポリシー アサーションを使用する場合は、「WS-Security の相互運用性ガイドライン」に定義されているガイドラインを考慮する必要があります。
WS-SecurityPolicy 仕様または WS-SecureConversation 仕様で定義されている WS-SecureConversation のキャンセルおよび更新をサポートする標準メソッドはありません。Microsoft .NET で WS-SecureConversation のキャンセルおよび更新をサポートするために使用されているメソッドには、WebLogic Server 10.x との互換性がありません。そのため、以下の設定が必要になります。
Microsoft .NET クライアントを WebLogic Server の Web サービスと相互運用するには、サーバ サイドで setCompatibilityPreference("msft") メソッドを使用し、Web サービスのセキュリティ MBean 経由で Compatibility フラグを設定する必要があります。
WebLogic Server の Web サービス クライアントを、Compatibility フラグが設定されている WebLogic Server の Web サービスと相互運用するには、次のようにクライアントでもこのフラグを設定する必要があります。
stub._setProperty(WLStub.POLICY_COMPATIBILITY_PREFERENCE,"msft");
以下に、WS-ReliableMessaging の相互運用性ガイドラインを示します。
匿名のリクエスト/応答は、WS-ReliableMessaging 仕様 (http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf) には定義されていないため、WebLogic Server ではサポートされません。
WS-ReliableMessaging セキュリティでは、WS-I Reliable Secure Profile 1.0 Draft 仕様のガイドラインに従い、WS-SecureConversation を使用する必要があります。
匿名での信頼性のあるメッセージングと WS-SecureConversation または WS-Trust の組み合わせはサポートされません。
WebLogic Server は、SAML と WS-Trust の両方を使用する Microsoft .NET 相互運用性シナリオに従って Microsoft .NET と相互運用しません。詳細については、http://131.107.72.15/ilab/ にある Microsoft .NET Web サービス相互運用性に関する次のドキュメントを参照してください。
『WS-SX Scenarios Document』(http://131.107.72.15/ilab/Trust13/WCFInteropPlugFest_WSTrust13.doc)
『WCF (Indigo) Interoperability Lab: WS-Trust10 Scenarios』(http://131.107.72.15/ilab/Trust10/WCFInteropPlugFest_WSTrust10.doc)
ただし、適切にコンフィグレーションすれば、WebLogic Server は Microsoft .NET と相互運用できます。たとえば、STS および Microsoft .NET クライアントにおいて適切にコンフィグレーションされていれば、WS-Security 1.0 に従って、SAML 1.1 Token Profile 1.0 で WebLogic サーバと相互運用可能です。詳細については、次の節を参照してください。
Microsoft .NET では、SAML アサーションの生成に Security Token Service (STS) が必要で、WS-Security 1.0 用の WS-Security SAML 1.1 トークン プロファイルがサポートされており、WS-Security の対称バインディングと SAML holder-of-key の確認手法が推奨されています。一方で Oracle WebLogic は、非対称バインディングと SAML sender-vouches の確認手法を利用することでパフォーマンスを高めており、X.509 証明書を使用してメッセージを署名し、SAML アサーションをバインドします。
WebLogic Server 側の着信ポリシーは WS-Security 1.0 用の WS-Security SAML 1.1 トークン プロファイルであり、発信ポリシーはメッセージが Web サービスによって署名されようにします。こうした処理が必要なのは、Microsoft .NET では WS-Security を使用して保護されているエンドポイントによって応答も保護されると想定しているためです。このコンフィグレーションをサポートするには、SAML アサーションを消費および検証するよう WebLogic Server Security レルムをコンフィグレーションし、WS-Security ポリシーで指示されるメッセージ シグネチャ操作用の公開鍵とプライベート キーのペアおよび対応するトラスト ストアをコンフィグレーションする必要があります。
これは次のような流れになります。
Microsoft .NET クライアントが STS を呼び出します。
STS が、サブジェクトとしてユーザの名前を格納する STS によって署名される SAML アサーションを生成します。
SAML アサーションが sender-vouches 確認手法を使用します。
SAML アサーションが WS-Security ヘッダに追加され、メッセージが呼び出し側のサービスによって署名されます。
メッセージが WebLogic Server に送信され、そこで SAML アサーションがメッセージ シグネチャとともに検証されます。
メッセージが処理されると、返されるメッセージが WebLogic サーバの ID で署名されます。
この署名が Microsoft .NET クライアントで検証され、そのメッセージが改ざんされておらず、WebLogic サーバから送信されたものであることを確認します。
STS は次のようにコンフィグレーションする必要があります。
SHA1 の指紋ではなく、WSS1.0 の X509RawCertificate フォーマットを使用する。
確認手法には、holder-of-key ではなく sender-vouches を使用する。
アサーションの署名には、暗号化キーではなく発行者のプライベート キーを使用する。対称暗号化キーの代わりに暗号化されていない非対称キーを使用すると、パフォーマンスが向上します。
SAML アサーションに AuthenticationStatement を含める。WebLogic では、この認証文を使用してユーザの ID にアクセスします。
wsu:Id を saml:Assertion に追加する。これを追加しない場合、Microsoft .NET クライアントは、非対称バインディングで IssuedToken として使えません。
WebLogic Web サービスの場合、定義済みの Wssp1.2-2007-Saml1.1-SenderVouches-Wss1.0.xml を使用して、メッセージ バインディングに WS-Security 1.0 での SAML 1.1 sender-vouches 認証を強制します。
Microsoft .NET クライアントは次のようにコンフィグレーションします。SAML トークンは STS から取得されるため、STS と通信するよう Microsoft .NET クライアントをコンフィグレーションする必要があります。STS から取得されるトークンを使用した認証は、IssuedToken と呼ばれます。
?xml version="1.0"?> <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" > <sp:AsymmetricBinding> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorToken> <sp:RecipientToken> <wsp:Policy> <sp:X509Token sp:IncludeToken= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never"> <wsp:Policy> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:ProtectTokens/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:AsymmetricBinding> <sp:SignedSupportingTokens> <wsp:Policy> <sp:SamlToken sp:IncludeToken= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:WssSamlV11Token10/> </wsp:Policy> </sp:SamlToken> </wsp:Policy> </sp:SignedSupportingTokens> <sp:Wss10> <wsp:Policy> <sp:MustSupportRefKeyIdentifier/> <sp:MustSupportRefIssuerSerial/> </wsp:Policy> </sp:Wss10> </wsp:Policy>
