Oracle® Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの紹介 11g リリース1(10.3.3) B61646-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 |
|
Web Services Security (WS-Security) 1.0および1.1 |
|
Web Services Security Policy (WS-SecurityPolicy) 1.2 |
|
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 |
|
上記に加え、以下のような機能の組合せもテストしました。
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サービスではCookieモードの会話がサポートされますが、この機能は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 Version 1.0 Working Group Draft仕様のガイドライン(http://www.ws-i.org/Profiles/ReliableSecureProfile-1.0.html
)に従い、WS-SecureConversationを使用する必要があります。
匿名での信頼性のあるメッセージングとWS-SecureConversationまたはWS-Trustの組合せは、WebLogic Webサービス・クライアントおよびMicrosoft .NETサービスでサポートされません。
WebLogic Serverは、SAMLとWS-Trustの両方を使用するMicrosoft .NET相互運用性シナリオに従ってMicrosoft .NETと相互運用しません。詳細は、http://mssoapinterop.org/ilab/
にあるMicrosoft .NET Webサービス相互運用性のプラグフェストのWebサイトで次のドキュメントを参照してください。
『WS-SX Scenarios Document』(http://mssoapinterop.org/ilab/Trust13/WCFInteropPlugFest_WSTrust13.doc
)
『WCF (Indigo) Interoperability Lab: WS-Trust10 Scenarios』(http://mssoapinterop.org/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>
SAMLアサーションが<wsee:Security>
ヘッダーの<ds:Signature>
要素の<ds:SignedInfo>
要素で参照される場合、Microsoft .NETでは、<wsse:SecurityTokenReference>
から参照されるSAMLアサーションをサポートしません。<wsse:SecurityTokenReference>の使用は、http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf
で説明されているWS-Security仕様でのベスト・プラクティスとして定義されます。
Microsoft .NETとの互換性を確保するには、Webサービス・クライアント・コードで、WLStub.POLICY_COMPATIBILITY_PREFERENCE
フラグをWLStub.POLICY_COMPATIBILITY_MSFT
フラグに設定する必要があります。フラグを設定すると、SAMLアサーションは、SecurityTokenReference
を使用せず、直接参照で署名されます。
次に、JAX-WS Webサービス・クライアントに対するMicrosoft .NET互換性フラグの設定方法の例を示します。
例3-1 JAX-WS Webサービス・クライアントでのMicrosoft .NET互換性フラグの設定
. . .
import weblogic.wsee.jaxrpc.WLStub;
. . .
public String test(String hello) throws Exception {
. . .
BindingProvider provider = (BindingProvider)port;
Map context = provider.getRequestContext();
. . .
. . .
context.put(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT);
try {
String result = port.getName(hello);
System.out.println("MSFT Result was: " + result);
return result;
} catch (Exception e) {
throw new RuntimeException (e);
}
}
次に、JAX-RPC Webサービス・クライアントに対するMicrosoft .NET互換性フラグの設定方法の例を示します。
例3-2 JAX-RPC Webサービス・クライアントでのMicrosoft .NET互換性フラグの設定
. . . . . . import weblogic.wsee.jaxrpc.WLStub; . . . @WebMethod() public String callSamlHelloSV_WSS10_MSFT(String input) { try { System.out.println("Calling sayHello(" + input + ") with MSFT Ways"); ((Stub)port)._setProperty(WLStub.POLICY_COMPATIBILITY_PREFERENCE, WLStub.POLICY_COMPATIBILITY_MSFT); String result = port.sayHelloSV_WSS10(input); System.out.println("MSFT Result was: " + result); return result; } catch (RemoteException e) { throw new RuntimeException(e); } }