You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mitrik,
A15 Entwicklung Qualitätsmanagement und technisches Marketing <Mi...@akdb.de> on 2012/10/19 11:15:16 UTC
Dispatching WS with WSS4J through STS
Hello,
I am trying to consume a webservice; since in the end many webservices will be consumed, I am using the Dispatch interface. Since I will not know the effective webservices that are going to be consumed I cannot declare the spring beans beforehand.
The webservice declares policies that require STS tokens. The STS defines a MEX (MetaDataExchange).
The basic consumer:
Service s = Service.create($WSDL-URL, $QName);
Dispatch<> d = s.createDispatch($service-name, $jaxb-context, PAYLOAD);
Map<> wss4jProps = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign config
((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new WSS4JOutInterceptor(wss4jProps);
d.invoke($request-message);
My questions:
1) when creating the service and dispatch objects, all referenced xsd schemas are resolved and loaded. However, by logging the made requests (in ProxySelector), I see that the same xsd get loaded repeatedly. Should they not be cached?
2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
3) Although the MEX request fails, the invocation continues to call the STS. Since STSClient creates a new Endpoint, my wss4j settings on the Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
4) Within the wss4j settings I also include Keystore information. Because most of the information comes from the application, I am going to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Thanks in advance,
Dieter
AW: Dispatching WS with WSS4J through STS
Posted by Mitrik,
A15 Entwicklung Qualitätsmanagement und technisches Marketing <Mi...@akdb.de>.
Hi,
---------------------------
ID: 1
Address: http://gov-test.osci2.bos-asp.de/governikus-sts/IdProviderUsernamePassword/mex
Encoding: UTF-8
Http-Method: POST
Content-Type: application/soap+xml; action="http://schemas.xmlsoap.org/ws/2004/09/transfer/Get"
Headers: {Accept=[*/*]}
Payload: <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Header><Action xmlns="http://www.w3.org/2005/08/addressing">http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</Action><MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:2f0ffa57-3c71-4849-99e6-f1f0799a6f8f</MessageID><To xmlns="http://www.w3.org/2005/08/addressing">http://gov-test.osci2.bos-asp.de/governikus-sts/IdProviderUsernamePassword/mex</To><ReplyTo xmlns="http://www.w3.org/2005/08/addressing"><Address>http://www.w3.org/2005/08/addressing/anonymous</Address></ReplyTo></soap:Header><soap:Body /></soap:Envelope>
--------------------------------------
----------------------------
ID: 1
Response-Code: 200
Encoding: UTF-8
Content-Type: application/soap+xml;charset=utf-8
Headers: {connection=[Keep-Alive], content-type=[application/soap+xml;charset=utf-8], Date=[Mon, 22 Oct 2012 09:16:26 GMT], Proxy-Connection=[Keep-Alive], transfer-encoding=[chunked], X-Powered-By=[Servlet 2.5; JBoss-5.0/JBossWeb-2.1]}
Payload: <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:mex="http://schemas.xmlsoap.org/ws/2004/09/mex"><soapenv:Header><Action xmlns="http://www.w3.org/2005/08/addressing">http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse</Action></soapenv:Header><soapenv:Body><mex:Metadata><mex:MetadataSection Dialect="http://schemas.xmlsoap.org/wsdl/" Identifier="http://www.governikus.de/idp/2009/10"><!-- Published by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.2.1-hudson-28-. --><definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:mex="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" xmlns:wsap10="http://www.w3.org/2006/05/addressing/wsdl" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:jxws="http://java.sun.com/xml/ns/jaxws" xmlns:q1="http://schemas.message.com/Message" xmlns:q2="http://schemas.message.com/Message" xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy" xmlns:sc="http://schemas.sun.com/2006/03/wss/server" xmlns:tc="http://schemas.sun.com/ws/2006/05/trust/server" xmlns:wspe="http://schemas.xmlsoap.org/ws/2004/09/policy/encoding" xmlns:t="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:tns="http://www.governikus.de/idp/2009/10" targetNamespace="http://www.governikus.de/idp/2009/10" name="NameOfTheIdProviderWSDL">
<!-- Username Password - here we use the same encryption as the SAFE project -->
<wsp:Policy wsu:Id="IIdProviderService_UsernamePassword_policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10 />
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:IncludeTimestamp />
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:OnlySignEntireHeadersAndBody />
<sp:ProtectionToken>
<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:ProtectionToken>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefEncryptedKey />
<sp:MustSupportRefIssuerSerial />
<sp:MustSupportRefThumbprint />
</wsp:Policy>
</sp:Wss11>
<wsap10:UsingAddressing />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<!-- Password Derived Keys -->
<wsp:Policy wsu:Id="IIdProviderService_PasswordDerivedKey_policy">
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing wsp:Optional="false">
<wsp:Policy />
</wsam:Addressing>
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:RequireDerivedKeys />
<sp:WssUsernameToken10 />
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:ProtectionToken>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<!--sp:EncryptBeforeSigning/-->
<sp:OnlySignEntireHeadersAndBody />
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier />
<sp:MustSupportRefIssuerSerial />
<sp:MustSupportRefThumbprint />
<sp:MustSupportRefEncryptedKey />
</wsp:Policy>
</sp:Wss11>
<sp:SignedEndorsingSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10 />
<sp:RequireDerivedKeys />
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<!-- Hash Password -->
<wsp:Policy wsu:Id="IIdProviderService_PasswordDigest_policy">
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing wsp:Optional="false">
<wsp:Policy />
</wsam:Addressing>
<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:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptSignature />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10 />
<sp:HashPassword />
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier />
<sp:MustSupportRefIssuerSerial />
<sp:MustSupportRefThumbprint />
<sp:MustSupportRefEncryptedKey />
</wsp:Policy>
</sp:Wss11>
<sp:Trust10>
<wsp:Policy>
<sp:MustSupportIssuedTokens />
<sp:RequireClientEntropy />
<sp:RequireServerEntropy />
</wsp:Policy>
</sp:Trust10>
<wspe:Utf816FFFECharacterEncoding />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<!-- X509 -->
<wsp:Policy wsu:Id="IIdProviderService_X509Certificate_policy">
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing wsp:Optional="false">
<wsp:Policy>
<wsam:AnonymousResponses />
</wsp:Policy>
</wsam:Addressing>
<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 />
<sp:RequireThumbprintReference />
</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 />
<sp:RequireThumbprintReference />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptBeforeSigning />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:Wss10>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier />
<sp:MustSupportRefIssuerSerial />
</wsp:Policy>
</sp:Wss10>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:Policy wsu:Id="ManagedService_Policy">
</wsp:Policy>
<wsp:Policy wsu:Id="IIdProviderService_Binding_IssueToken_Input_Policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:EncryptedParts>
<sp:Body />
</sp:EncryptedParts>
<sp:SignedParts>
<sp:Body />
<sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="AckRequested" Namespace="http://docs.oasis-open.org/ws-rx/wsrmp/200702" />
<sp:Header Name="SequenceAcknowledgement" Namespace="http://docs.oasis-open.org/ws-rx/wsrmp/200702" />
<sp:Header Name="Sequence" Namespace="http://docs.oasis-open.org/ws-rx/wsrmp/200702" />
<sp:Header Name="CreateSequence" Namespace="http://docs.oasis-open.org/ws-rx/wsrmp/200702" />
</sp:SignedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:Policy wsu:Id="IIdProviderService_Binding_IssueToken_Output_Policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:EncryptedParts>
<sp:Body />
</sp:EncryptedParts>
<sp:SignedParts>
<sp:Body />
<sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="From" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="FaultTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="ReplyTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="MessageID" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="RelatesTo" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name="AckRequested" Namespace="http://docs.oasis-open.org/ws-rx/wsrmp/200702" />
<sp:Header Name="SequenceAcknowledgement" Namespace="http://docs.oasis-open.org/ws-rx/wsrmp/200702" />
<sp:Header Name="Sequence" Namespace="http://docs.oasis-open.org/ws-rx/wsrmp/200702" />
<sp:Header Name="CreateSequence" Namespace="http://docs.oasis-open.org/ws-rx/wsrmp/200702" />
</sp:SignedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<types>
<xsd:schema targetNamespace="http://messagebox.osci20.bos-bremen.de">
<xsd:import namespace="http://schemas.message.com/Message" />
</xsd:schema>
</types>
<message name="IIdProviderService_IssueToken_InputMessage">
<part name="rstMessage" element="q1:MessageBody" />
</message>
<message name="IIdProviderService_IssueToken_OutputMessage">
<part name="IssueTokenResult" element="q2:MessageBody" />
</message>
<portType name="IIdProviderService">
<operation name="IssueToken">
<input wsam:Action="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue" message="tns:IIdProviderService_IssueToken_InputMessage" />
<output wsam:Action="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal" message="tns:IIdProviderService_IssueToken_OutputMessage" />
<!--
<output wsam:Action="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Issue"
message="tns:IIdProviderService_IssueToken_OutputMessage" /
-->
</operation>
</portType>
<binding name="IIdProviderService_UsernamePassword_Binding" type="tns:IIdProviderService">
<wsp:PolicyReference URI="#IIdProviderService_UsernamePassword_policy" />
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" />
<operation name="IssueToken">
<soap:operation soapAction="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue" style="document" />
<input>
<soap:body use="literal" />
<wsp:PolicyReference URI="#IIdProviderService_Binding_IssueToken_Input_Policy" />
</input>
<output>
<soap:body use="literal" />
<wsp:PolicyReference URI="#IIdProviderService_Binding_IssueToken_Output_Policy" />
</output>
</operation>
</binding>
<binding name="IIdProviderService_PasswordDerivedKey_Binding" type="tns:IIdProviderService">
<wsp:PolicyReference URI="#IIdProviderService_PasswordDerivedKey_policy" />
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" />
<operation name="IssueToken">
<soap:operation soapAction="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue" style="document" />
<input>
<soap:body use="literal" />
<wsp:PolicyReference URI="#IIdProviderService_Binding_IssueToken_Input_Policy" />
</input>
<output>
<soap:body use="literal" />
<wsp:PolicyReference URI="#IIdProviderService_Binding_IssueToken_Output_Policy" />
</output>
</operation>
</binding>
<binding name="IIdProviderService_PasswordDigest_Binding" type="tns:IIdProviderService">
<wsp:PolicyReference URI="#IIdProviderService_PasswordDigest_policy" />
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" />
<operation name="IssueToken">
<soap:operation soapAction="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue" style="document" />
<input>
<soap:body use="literal" />
<wsp:PolicyReference URI="#IIdProviderService_Binding_IssueToken_Input_Policy" />
</input>
<output>
<soap:body use="literal" />
<wsp:PolicyReference URI="#IIdProviderService_Binding_IssueToken_Output_Policy" />
</output>
</operation>
</binding>
<binding name="IIdProviderService_X509Certificate_Binding" type="tns:IIdProviderService">
<wsp:PolicyReference URI="#IIdProviderService_X509Certificate_policy" />
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" />
<operation name="IssueToken">
<soap:operation soapAction="http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue" style="document" />
<input>
<soap:body use="literal" />
<wsp:PolicyReference URI="#IIdProviderService_Binding_IssueToken_Input_Policy" />
</input>
<output>
<soap:body use="literal" />
<wsp:PolicyReference URI="#IIdProviderService_Binding_IssueToken_Output_Policy" />
</output>
</operation>
</binding>
<service name="IdProviderService_UsernamePassword">
<port name="IIdProviderService_UsernamePasswordPort" binding="tns:IIdProviderService_UsernamePassword_Binding">
<wsp:PolicyReference URI="#ManagedService_Policy" />
<soap:address location="http://gov-test.osci2.bos-asp.de/governikus-sts/IdProviderUsernamePassword" />
</port>
</service>
<service name="IdProviderService_PasswordDerivedKey">
<port name="IIdProviderService_PasswordDerivedKeyPort" binding="tns:IIdProviderService_PasswordDerivedKey_Binding">
<wsp:PolicyReference URI="#ManagedService_Policy" />
<soap:address location="REPLACE_WITH_ACTUAL_URL" />
</port>
</service>
<service name="IdProviderService_PasswordDigest">
<port name="IIdProviderService_PasswordDigestPort" binding="tns:IIdProviderService_PasswordDigest_Binding">
<wsp:PolicyReference URI="#ManagedService_Policy" />
<soap:address location="REPLACE_WITH_ACTUAL_URL" />
</port>
</service>
<service name="IdProviderService_X509Certificate">
<port name="IIdProviderService_X509CertificatePort" binding="tns:IIdProviderService_X509Certificate_Binding">
<wsp:PolicyReference URI="#ManagedService_Policy" />
<soap:address location="REPLACE_WITH_ACTUAL_URL" />
</port>
</service>
</definitions></mex:MetadataSection><mex:MetadataSection Dialect="http://www.w3.org/2001/XMLSchema" Identifier="http://schemas.message.com/Message"><!-- Published by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.2.1-hudson-28-. --><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.message.com/Message" elementFormDefault="qualified" targetNamespace="http://schemas.message.com/Message">
<xs:element name="MessageBody" type="tns:MessageBodyType" />
<xs:complexType name="MessageBodyType">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any" />
</xs:sequence>
</xs:complexType>
</xs:schema></mex:MetadataSection></mex:Metadata></soapenv:Body></soapenv:Envelope>
--------------------------------------
Not really wire but Logging*InterceptorFeature. Hope that's enough.
Cheers,
Dieter
> Hi,
>
> OK, MEX call seems to be successful now.
> The problem occurs on the next step by building service model from the
> WSDL.
>
> Could you intercept wire message (request and response) for MEX
> communication and put it here?
>
> Regards,
> Andrei.
>
> -----Original Message-----
> From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches
> Marketing [mailto:Mitrik.Dieter@akdb.de]
> Sent: Montag, 22. Oktober 2012 11:42
> To: users@cxf.apache.org
> Subject: AW: Dispatching WS with WSS4J through STS
>
> Hello Andrei,
>
> I have tried the suggestions from here and your other message. I got a
> little further, but there is still problems.
>
> Here is the current exception, after working in the MEX changes:
> """
> 2012-10-22 11:16:26,913 [main] DEBUG
> org.apache.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on
> interceptor org.apache.cxf.interceptor.StaxInEndingInterceptor@1e75e89
> org.apache.cxf.wsdl11.WSDLRuntimeException: Part rstMessage defined as
> element {http://schemas.message.com/Message}MessageBody which is not in
> the schema.
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildMessage(WSDLServiceBuilder.j
> ava:865)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterfaceOperation(WSDLServi
> ceBuilder.java:593)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterface(WSDLServiceBuilder
> .java:571)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.
> java:347)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.
> java:196)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.
> java:172)
> at
> org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:11
> 9)
> at
> *.Osci2ClientTest$MySTSClient.configureViaEPR(Osci2ClientTest.java:269)
> at
> *.Osci2ClientTest$SetSTSClientOutInterceptor.handleMessage(Osci2ClientTest
> .java:223)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCha
> in.java:271)
> """
>
> The service that I want to consume is: http://gov-test.osci2.bos-
> asp.de/OSCI2Endpoint/user/Alice , MEX=http://gov-test.osci2.bos-
> asp.de/governikus-sts/IdProviderUsernamePassword/mex
>
>
> Here are the relevant code snippets:
> """
>
> ((DispatchImpl<?>)dispatch).getClient().getOutInterceptors().add(new
> SetSTSClientOutInterceptor());
> ...
>
> public static class SetSTSClientOutInterceptor extends
> AbstractPhaseInterceptor<Message> {
> public SetSTSClientOutInterceptor() {
> super(Phase.PREPARE_SEND);
> getBefore().add("IssuedTokenOutInterceptor");
> }
>
> @Override
> public void handleMessage(Message message) throws Fault {
> STSClient stsClient = new
> MySTSClient(message.getExchange().get(Bus.class));
> stsClient.setSoap12();
>
> stsClient.setEndpointName(message.getExchange().getEndpoint().getEnd
> pointInfo().getName().toString());
> stsClient.setServiceName("{http://docs.oasis-
> open.org/ws-sx/ws-trust/200512/}SecurityTokenService");
>
> message.setContextualProperty(SecurityConstants.STS_CLIENT,
> stsClient);
>
> AssertionInfoMap aim =
> message.get(AssertionInfoMap.class);
> // extract Assertion information
> if (aim != null) {
> Collection<AssertionInfo> ais =
> aim.get(SP12Constants.ISSUED_TOKEN);
> if (ais == null || ais.isEmpty()) {
> return;
> }
> if (isRequestor(message)) {
> IssuedToken itok = (IssuedToken)
> ais.iterator().next().getAssertion();
> if (itok.getIssuerEpr() != null) {
> // configure via mex
> boolean useEPRWSAAddrAsMEXLocation =
> !Boolean
> .valueOf((String) message
>
> .getContextualProperty(SecurityConstants.DISABLE_STS_CLIENT_WSMEX_CA
> LL_USING_EPR_ADDRESS));
>
> stsClient.configureViaEPR(itok.getIssuerEpr(),
> useEPRWSAAddrAsMEXLocation);
> }
> }
> }
> }
> }
>
> public static class MySTSClient extends STSClient {
> ...
> @Override
> public void configureViaEPR(EndpointReferenceType ref, boolean
> useEPRWSAAddrAsMEXLocation) {
> ...
>
> proxyFac.setBindingId(SoapBindingConstants.SOAP12_BINDING_ID);
> ...
> """
>
>
> Thank you in advance,
> Dieter
>
> ----------------
>
> See answers bellow
>
> >[dam] I tried creating a STSClient inside an interceptor
> >(list=dispatch.client.out, phase=PREPARE_SEND,
> >before=IssuedTokenOutInterceptor) and assign it to the context. I
> >created the client following STSUtils#getClient(); unfortunately, it
> >NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI
> >because URI|location was null. In the default case, STSUtils would set
> >the location from IssuedToken.EPR. What is the equivalent for my
> interceptor#handleMessage()? Is there a less clunky way to achieve this?
>
> a) By default IssuedTokenOutInterceptor uses address from
> IssuedToken/Issuer WS-Policy element. You can do it exactly the same way:
> Collection<AssertionInfo> ais =
> aim.get(SP12Constants.ISSUED_TOKEN);
> ...
> IssuedToken itok =
> (IssuedToken)ais.iterator().next().getAssertion();
> ...
> STSClient client = STSUtils.getClient(message, "sts",
> itok);
>
> b) Other option is just create STSClient manually and set necessary
> properties:
> STSClient stsClient = (STSClient)
> message.getExchange().get(SecurityConstants.STS_CLIENT);
> if (stsClient == null) {
> stsClient = new STSClient(message.getExchange().getBus());
> }
> stsClient.setWsdlLocation(stsEndpoint + "?wsdl");
>
> stsClient.setServiceName(AuthenticationConstants.STS_SERVICE_NAME);
>
> stsClient.setEndpointName(AuthenticationConstants.STS_ENDPOINT_NAME);
>
> Map<String, Object> props = new HashMap<String, Object>();
> props.put(SecurityConstants.STS_TOKEN_USE_CERT_FOR_KEYINFO,
> "true");
> props.put(SecurityConstants.STS_TOKEN_USERNAME,
> AuthenticationConstants.CONSUMER_ALIAS);
> props.put(SecurityConstants.IS_BSP_COMPLIANT, "false");
> stsClient.setProperties(props);
>
> message.getExchange().put(SecurityConstants.STS_CLIENT,
> stsClient);
>
> stsEndpoint is endpoint of your STS service;
> AuthenticationConstants.STS_SERVICE_NAME is {http://docs.oasis-
> open.org/ws-sx/ws-trust/200512/}SecurityTokenService";
> AuthenticationConstants.STS_ENDPOINT_NAME is "{http://docs.oasis-
> open.org/ws-sx/ws-trust/200512/}X509_Port".
>
> Here you can also set Soap 1.2 binding using stsClient.setSoap12();
>
> >[dam] Adding the suggested properties to dispatch.requestContext did
> >not add any interceptors to the STS Endpoint chain which in turn did not
> add the necessary elements into the outgoing message. Is this a
> consequence of the failing MEX above? Where would the interceptors have
> been injected?
>
> Interceptors are controlled by WS-Policy and will be added automatically
> via InterceptorProviders. InterceptorProviders specify relationships
> between WS-Policy assertions and interceptors.
>
> >[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to
> >make a WebServiceFeature out of this, so that
> service.createDispatch(..,..,.., new SecurityFeature(mysignprops,
> myencprops)?
>
> Not sure does it make sense. Setting properties in request context works
> for all types of clients (generated, configured via Spring/Blueprint), not
> only for Dispatch. But you welcome to create improvement request in CXF
> Jira and submit a patch.
>
> Regards,
> Andrei.
>
>
>
> Hello,
>
> thank you for your suggestions.
> See comments below [dam].
>
> Thank you in advance.
> -------------------------
>
>
> I would recommend do not configure WSS4JOutterceptor directly in code, but
> do it using WS-Policy.
> As sample you can take http://svn.apache.org/repos/asf/cxf/branches/2.3.x-
> fixes/systests/ws-
> specs/src/test/java/org/apache/cxf/systest/ws/security/SecurityPolicyTest.
> java
>
> Code looks like:
> // DoubleIt.wsdl specifies WS-policy
> URL wsdl = SecurityPolicyTest.class.getResource("DoubleIt.wsdl");
> Service service = Service.create(wsdl, SERVICE_QNAME);
>
> QName portQName = new QName(NAMESPACE,
> "DoubleItPortEncryptThenSign");
> Dispatch<Source> disp = service.createDispatch(portQName,
> Source.class, Mode.PAYLOAD);
>
> disp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
> new KeystorePasswordCallback());
>
> disp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
>
> getClass().getResource("alice.properties"));
> disp.getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
>
> getClass().getResource("bob.properties"));
>
> [dam] This approach does feel more comfortable. I had been following the
> WS-Security user's guide where the instructions were to use the wss4j
> interceptors directly.
>
>
> Regarding your questions:
>
> >2) The created service itself is a SOAP12 endpoint; however, the MEX
> endpoint instantiated through STSClient uses SOAP11. The server expects
> SOAP12 and >fails if requested by SOAP11. How do I force the MEX call to
> use SOAP12 instead of SOAP11?
>
> STSClient has setters for both SOAP versions. Default is SOAP11. Actually
> I do not see configuration property in code to change it. Seems only
> possible to create and configure own STSClient instance in your
> Interceptor and set it into SecurityConstants.STS_CLIENT message property
> to be used in IssuedTokenOutInterceptor. Will be nice to configure it via
> property.
>
> [dam] I tried creating a STSClient inside an interceptor
> (list=dispatch.client.out, phase=PREPARE_SEND,
> before=IssuedTokenOutInterceptor) and assign it to the context. I created
> the client following STSUtils#getClient(); unfortunately, it NPEed at
> org.apache.cxf.transport.TransportFinder.findTransportForURI because
> URI|location was null. In the default case, STSUtils would set the
> location from IssuedToken.EPR. What is the equivalent for my
> interceptor#handleMessage()? Is there a less clunky way to achieve this?
>
>
> >3) Although the MEX request fails, the invocation continues to call the
> >STS. Since STSClient creates a new Endpoint, my wss4j settings on the
> >Dispatch have no effect. How can I make the STSClient Endpoint inherit
> its Dispatch's wss4j settings? Or how can I identify the created Endpoint
> in a ClientLifecycleListener to repeat the wss4j settings?
>
> I think it should work out of the box with recommended way.
>
> [dam] Adding the suggested properties to dispatch.requestContext did not
> add any interceptors to the STS Endpoint chain which in turn did not add
> the necessary elements into the outgoing message. Is this a consequence of
> the failing MEX above? Where would the interceptors have been injected?
>
>
> >4) Within the wss4j settings I also include Keystore information.
> >Because most of the information comes from the application, I am going
> >to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the
> name of a context property. Which one is the effective context to add the
> Crypto object to for the implicit STSClient Endpoint request?
>
> Typically you just configure SecurityConstants.SIGNATURE_PROPERTIES and
> SecurityConstants.ENCRYPT_PROPERTIES with properties files pointing on
> your keystore (like in SecurityPolicyTest.java). If it is not appropriate
> for your use case (for example if keys are obtained dynamically), you can
> prepare and set your own Crypto object into message using
> SecurityConstants.SIGNATURE_CRYPTO, SecurityConstants.ENCRYPT_CRYPTO
> properties.
> CXF checks these properties and will use prepared objects.
>
> [dam] Thanks, this is more to my liking. Wouldn't it be even nicer to make
> a WebServiceFeature out of this, so that service.createDispatch(..,..,..,
> new SecurityFeature(mysignprops, myencprops)?
>
>
> Regards,
> Andrei.
>
>
>
> Hello,
>
> I am trying to consume a webservice; since in the end many webservices
> will be consumed, I am using the Dispatch interface. Since I will not know
> the effective webservices that are going to be consumed I cannot declare
> the spring beans beforehand.
> The webservice declares policies that require STS tokens. The STS defines
> a MEX (MetaDataExchange).
>
> The basic consumer:
> Service s = Service.create($WSDL-URL, $QName); Dispatch<> d =
> s.createDispatch($service-name, $jaxb-context, PAYLOAD); Map<> wss4jProps
> = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign
> config
> ((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new
> WSS4JOutInterceptor(wss4jProps); d.invoke($request-message);
>
>
> My questions:
> 1) when creating the service and dispatch objects, all referenced xsd
> schemas are resolved and loaded. However, by logging the made requests (in
> ProxySelector), I see that the same xsd get loaded repeatedly. Should they
> not be cached?
> 2) The created service itself is a SOAP12 endpoint; however, the MEX
> endpoint instantiated through STSClient uses SOAP11. The server expects
> SOAP12 and fails if requested by SOAP11. How do I force the MEX call to
> use SOAP12 instead of SOAP11?
> 3) Although the MEX request fails, the invocation continues to call the
> STS. Since STSClient creates a new Endpoint, my wss4j settings on the
> Dispatch have no effect. How can I make the STSClient Endpoint inherit its
> Dispatch's wss4j settings? Or how can I identify the created Endpoint in a
> ClientLifecycleListener to repeat the wss4j settings?
> 4) Within the wss4j settings I also include Keystore information. Because
> most of the information comes from the application, I am going to
> preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name
> of a context property. Which one is the effective context to add the
> Crypto object to for the implicit STSClient Endpoint request?
>
>
> Thanks in advance,
> Dieter
AW: Dispatching WS with WSS4J through STS
Posted by Mitrik,
A15 Entwicklung Qualitätsmanagement und technisches Marketing <Mi...@akdb.de>.
Hi Andrei,
> Did you get it working?
No, I had pasted the wire messages here (Mon 22.10.2012 12:54) but did not get an answer. I have been trying with Metro since then which has different problems :(
Cheers,
Dieter
> OK, MEX call seems to be successful now.
> The problem occurs on the next step by building service model from the
> WSDL.
>
> Could you intercept wire message (request and response) for MEX
> communication and put it here?
>
> Regards,
> Andrei.
>
> -----Original Message-----
> From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches
> Marketing [mailto:Mitrik.Dieter@akdb.de]
> Sent: Montag, 22. Oktober 2012 11:42
> To: users@cxf.apache.org
> Subject: AW: Dispatching WS with WSS4J through STS
>
> Hello Andrei,
>
> I have tried the suggestions from here and your other message. I got a
> little further, but there is still problems.
>
> Here is the current exception, after working in the MEX changes:
> """
> 2012-10-22 11:16:26,913 [main] DEBUG
> org.apache.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on
> interceptor org.apache.cxf.interceptor.StaxInEndingInterceptor@1e75e89
> org.apache.cxf.wsdl11.WSDLRuntimeException: Part rstMessage defined as
> element {http://schemas.message.com/Message}MessageBody which is not in
> the schema.
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildMessage(WSDLServiceBuilder.j
> ava:865)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterfaceOperation(WSDLServi
> ceBuilder.java:593)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterface(WSDLServiceBuilder
> .java:571)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.
> java:347)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.
> java:196)
> at
> org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.
> java:172)
> at
> org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:11
> 9)
> at
> *.Osci2ClientTest$MySTSClient.configureViaEPR(Osci2ClientTest.java:269)
> at
> *.Osci2ClientTest$SetSTSClientOutInterceptor.handleMessage(Osci2ClientTest
> .java:223)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCha
> in.java:271)
> """
>
> The service that I want to consume is: http://gov-test.osci2.bos-
> asp.de/OSCI2Endpoint/user/Alice , MEX=http://gov-test.osci2.bos-
> asp.de/governikus-sts/IdProviderUsernamePassword/mex
>
>
> Here are the relevant code snippets:
> """
>
> ((DispatchImpl<?>)dispatch).getClient().getOutInterceptors().add(new
> SetSTSClientOutInterceptor());
> ...
>
> public static class SetSTSClientOutInterceptor extends
> AbstractPhaseInterceptor<Message> {
> public SetSTSClientOutInterceptor() {
> super(Phase.PREPARE_SEND);
> getBefore().add("IssuedTokenOutInterceptor");
> }
>
> @Override
> public void handleMessage(Message message) throws Fault {
> STSClient stsClient = new
> MySTSClient(message.getExchange().get(Bus.class));
> stsClient.setSoap12();
>
> stsClient.setEndpointName(message.getExchange().getEndpoint().getEnd
> pointInfo().getName().toString());
> stsClient.setServiceName("{http://docs.oasis-
> open.org/ws-sx/ws-trust/200512/}SecurityTokenService");
>
> message.setContextualProperty(SecurityConstants.STS_CLIENT,
> stsClient);
>
> AssertionInfoMap aim =
> message.get(AssertionInfoMap.class);
> // extract Assertion information
> if (aim != null) {
> Collection<AssertionInfo> ais =
> aim.get(SP12Constants.ISSUED_TOKEN);
> if (ais == null || ais.isEmpty()) {
> return;
> }
> if (isRequestor(message)) {
> IssuedToken itok = (IssuedToken)
> ais.iterator().next().getAssertion();
> if (itok.getIssuerEpr() != null) {
> // configure via mex
> boolean useEPRWSAAddrAsMEXLocation =
> !Boolean
> .valueOf((String) message
>
> .getContextualProperty(SecurityConstants.DISABLE_STS_CLIENT_WSMEX_CA
> LL_USING_EPR_ADDRESS));
>
> stsClient.configureViaEPR(itok.getIssuerEpr(),
> useEPRWSAAddrAsMEXLocation);
> }
> }
> }
> }
> }
>
> public static class MySTSClient extends STSClient {
> ...
> @Override
> public void configureViaEPR(EndpointReferenceType ref, boolean
> useEPRWSAAddrAsMEXLocation) {
> ...
>
> proxyFac.setBindingId(SoapBindingConstants.SOAP12_BINDING_ID);
> ...
> """
>
>
> Thank you in advance,
> Dieter
>
> ----------------
>
> See answers bellow
>
> >[dam] I tried creating a STSClient inside an interceptor
> >(list=dispatch.client.out, phase=PREPARE_SEND,
> >before=IssuedTokenOutInterceptor) and assign it to the context. I
> >created the client following STSUtils#getClient(); unfortunately, it
> >NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI
> >because URI|location was null. In the default case, STSUtils would set
> >the location from IssuedToken.EPR. What is the equivalent for my
> interceptor#handleMessage()? Is there a less clunky way to achieve this?
>
> a) By default IssuedTokenOutInterceptor uses address from
> IssuedToken/Issuer WS-Policy element. You can do it exactly the same way:
> Collection<AssertionInfo> ais =
> aim.get(SP12Constants.ISSUED_TOKEN);
> ...
> IssuedToken itok =
> (IssuedToken)ais.iterator().next().getAssertion();
> ...
> STSClient client = STSUtils.getClient(message, "sts",
> itok);
>
> b) Other option is just create STSClient manually and set necessary
> properties:
> STSClient stsClient = (STSClient)
> message.getExchange().get(SecurityConstants.STS_CLIENT);
> if (stsClient == null) {
> stsClient = new STSClient(message.getExchange().getBus());
> }
> stsClient.setWsdlLocation(stsEndpoint + "?wsdl");
>
> stsClient.setServiceName(AuthenticationConstants.STS_SERVICE_NAME);
>
> stsClient.setEndpointName(AuthenticationConstants.STS_ENDPOINT_NAME);
>
> Map<String, Object> props = new HashMap<String, Object>();
> props.put(SecurityConstants.STS_TOKEN_USE_CERT_FOR_KEYINFO,
> "true");
> props.put(SecurityConstants.STS_TOKEN_USERNAME,
> AuthenticationConstants.CONSUMER_ALIAS);
> props.put(SecurityConstants.IS_BSP_COMPLIANT, "false");
> stsClient.setProperties(props);
>
> message.getExchange().put(SecurityConstants.STS_CLIENT,
> stsClient);
>
> stsEndpoint is endpoint of your STS service;
> AuthenticationConstants.STS_SERVICE_NAME is {http://docs.oasis-
> open.org/ws-sx/ws-trust/200512/}SecurityTokenService";
> AuthenticationConstants.STS_ENDPOINT_NAME is "{http://docs.oasis-
> open.org/ws-sx/ws-trust/200512/}X509_Port".
>
> Here you can also set Soap 1.2 binding using stsClient.setSoap12();
>
> >[dam] Adding the suggested properties to dispatch.requestContext did
> >not add any interceptors to the STS Endpoint chain which in turn did not
> add the necessary elements into the outgoing message. Is this a
> consequence of the failing MEX above? Where would the interceptors have
> been injected?
>
> Interceptors are controlled by WS-Policy and will be added automatically
> via InterceptorProviders. InterceptorProviders specify relationships
> between WS-Policy assertions and interceptors.
>
> >[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to
> >make a WebServiceFeature out of this, so that
> service.createDispatch(..,..,.., new SecurityFeature(mysignprops,
> myencprops)?
>
> Not sure does it make sense. Setting properties in request context works
> for all types of clients (generated, configured via Spring/Blueprint), not
> only for Dispatch. But you welcome to create improvement request in CXF
> Jira and submit a patch.
>
> Regards,
> Andrei.
>
>
>
> Hello,
>
> thank you for your suggestions.
> See comments below [dam].
>
> Thank you in advance.
> -------------------------
>
>
> I would recommend do not configure WSS4JOutterceptor directly in code, but
> do it using WS-Policy.
> As sample you can take http://svn.apache.org/repos/asf/cxf/branches/2.3.x-
> fixes/systests/ws-
> specs/src/test/java/org/apache/cxf/systest/ws/security/SecurityPolicyTest.
> java
>
> Code looks like:
> // DoubleIt.wsdl specifies WS-policy
> URL wsdl = SecurityPolicyTest.class.getResource("DoubleIt.wsdl");
> Service service = Service.create(wsdl, SERVICE_QNAME);
>
> QName portQName = new QName(NAMESPACE,
> "DoubleItPortEncryptThenSign");
> Dispatch<Source> disp = service.createDispatch(portQName,
> Source.class, Mode.PAYLOAD);
>
> disp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
> new KeystorePasswordCallback());
>
> disp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
>
> getClass().getResource("alice.properties"));
> disp.getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
>
> getClass().getResource("bob.properties"));
>
> [dam] This approach does feel more comfortable. I had been following the
> WS-Security user's guide where the instructions were to use the wss4j
> interceptors directly.
>
>
> Regarding your questions:
>
> >2) The created service itself is a SOAP12 endpoint; however, the MEX
> endpoint instantiated through STSClient uses SOAP11. The server expects
> SOAP12 and >fails if requested by SOAP11. How do I force the MEX call to
> use SOAP12 instead of SOAP11?
>
> STSClient has setters for both SOAP versions. Default is SOAP11. Actually
> I do not see configuration property in code to change it. Seems only
> possible to create and configure own STSClient instance in your
> Interceptor and set it into SecurityConstants.STS_CLIENT message property
> to be used in IssuedTokenOutInterceptor. Will be nice to configure it via
> property.
>
> [dam] I tried creating a STSClient inside an interceptor
> (list=dispatch.client.out, phase=PREPARE_SEND,
> before=IssuedTokenOutInterceptor) and assign it to the context. I created
> the client following STSUtils#getClient(); unfortunately, it NPEed at
> org.apache.cxf.transport.TransportFinder.findTransportForURI because
> URI|location was null. In the default case, STSUtils would set the
> location from IssuedToken.EPR. What is the equivalent for my
> interceptor#handleMessage()? Is there a less clunky way to achieve this?
>
>
> >3) Although the MEX request fails, the invocation continues to call the
> >STS. Since STSClient creates a new Endpoint, my wss4j settings on the
> >Dispatch have no effect. How can I make the STSClient Endpoint inherit
> its Dispatch's wss4j settings? Or how can I identify the created Endpoint
> in a ClientLifecycleListener to repeat the wss4j settings?
>
> I think it should work out of the box with recommended way.
>
> [dam] Adding the suggested properties to dispatch.requestContext did not
> add any interceptors to the STS Endpoint chain which in turn did not add
> the necessary elements into the outgoing message. Is this a consequence of
> the failing MEX above? Where would the interceptors have been injected?
>
>
> >4) Within the wss4j settings I also include Keystore information.
> >Because most of the information comes from the application, I am going
> >to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the
> name of a context property. Which one is the effective context to add the
> Crypto object to for the implicit STSClient Endpoint request?
>
> Typically you just configure SecurityConstants.SIGNATURE_PROPERTIES and
> SecurityConstants.ENCRYPT_PROPERTIES with properties files pointing on
> your keystore (like in SecurityPolicyTest.java). If it is not appropriate
> for your use case (for example if keys are obtained dynamically), you can
> prepare and set your own Crypto object into message using
> SecurityConstants.SIGNATURE_CRYPTO, SecurityConstants.ENCRYPT_CRYPTO
> properties.
> CXF checks these properties and will use prepared objects.
>
> [dam] Thanks, this is more to my liking. Wouldn't it be even nicer to make
> a WebServiceFeature out of this, so that service.createDispatch(..,..,..,
> new SecurityFeature(mysignprops, myencprops)?
>
>
> Regards,
> Andrei.
>
>
>
> Hello,
>
> I am trying to consume a webservice; since in the end many webservices
> will be consumed, I am using the Dispatch interface. Since I will not know
> the effective webservices that are going to be consumed I cannot declare
> the spring beans beforehand.
> The webservice declares policies that require STS tokens. The STS defines
> a MEX (MetaDataExchange).
>
> The basic consumer:
> Service s = Service.create($WSDL-URL, $QName); Dispatch<> d =
> s.createDispatch($service-name, $jaxb-context, PAYLOAD); Map<> wss4jProps
> = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign
> config
> ((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new
> WSS4JOutInterceptor(wss4jProps); d.invoke($request-message);
>
>
> My questions:
> 1) when creating the service and dispatch objects, all referenced xsd
> schemas are resolved and loaded. However, by logging the made requests (in
> ProxySelector), I see that the same xsd get loaded repeatedly. Should they
> not be cached?
> 2) The created service itself is a SOAP12 endpoint; however, the MEX
> endpoint instantiated through STSClient uses SOAP11. The server expects
> SOAP12 and fails if requested by SOAP11. How do I force the MEX call to
> use SOAP12 instead of SOAP11?
> 3) Although the MEX request fails, the invocation continues to call the
> STS. Since STSClient creates a new Endpoint, my wss4j settings on the
> Dispatch have no effect. How can I make the STSClient Endpoint inherit its
> Dispatch's wss4j settings? Or how can I identify the created Endpoint in a
> ClientLifecycleListener to repeat the wss4j settings?
> 4) Within the wss4j settings I also include Keystore information. Because
> most of the information comes from the application, I am going to
> preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name
> of a context property. Which one is the effective context to add the
> Crypto object to for the implicit STSClient Endpoint request?
>
>
> Thanks in advance,
> Dieter
RE: Dispatching WS with WSS4J through STS
Posted by Andrei Shakirin <as...@talend.com>.
Hi Mitrik,
Did you get it working?
Regards,
Andrei.
-----Original Message-----
From: Andrei Shakirin [mailto:ashakirin@talend.com]
Sent: Montag, 22. Oktober 2012 12:32
To: users@cxf.apache.org
Cc: Mitrik.Dieter@akdb.de
Subject: RE: Dispatching WS with WSS4J through STS
Hi,
OK, MEX call seems to be successful now.
The problem occurs on the next step by building service model from the WSDL.
Could you intercept wire message (request and response) for MEX communication and put it here?
Regards,
Andrei.
-----Original Message-----
From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches Marketing [mailto:Mitrik.Dieter@akdb.de]
Sent: Montag, 22. Oktober 2012 11:42
To: users@cxf.apache.org
Subject: AW: Dispatching WS with WSS4J through STS
Hello Andrei,
I have tried the suggestions from here and your other message. I got a little further, but there is still problems.
Here is the current exception, after working in the MEX changes:
"""
2012-10-22 11:16:26,913 [main] DEBUG org.apache.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.interceptor.StaxInEndingInterceptor@1e75e89
org.apache.cxf.wsdl11.WSDLRuntimeException: Part rstMessage defined as element {http://schemas.message.com/Message}MessageBody which is not in the schema.
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildMessage(WSDLServiceBuilder.java:865)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterfaceOperation(WSDLServiceBuilder.java:593)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterface(WSDLServiceBuilder.java:571)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:347)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:196)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:172)
at org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:119)
at *.Osci2ClientTest$MySTSClient.configureViaEPR(Osci2ClientTest.java:269)
at *.Osci2ClientTest$SetSTSClientOutInterceptor.handleMessage(Osci2ClientTest.java:223)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
"""
The service that I want to consume is: http://gov-test.osci2.bos-asp.de/OSCI2Endpoint/user/Alice , MEX=http://gov-test.osci2.bos-asp.de/governikus-sts/IdProviderUsernamePassword/mex
Here are the relevant code snippets:
"""
((DispatchImpl<?>)dispatch).getClient().getOutInterceptors().add(new SetSTSClientOutInterceptor());
...
public static class SetSTSClientOutInterceptor extends AbstractPhaseInterceptor<Message> {
public SetSTSClientOutInterceptor() {
super(Phase.PREPARE_SEND);
getBefore().add("IssuedTokenOutInterceptor");
}
@Override
public void handleMessage(Message message) throws Fault {
STSClient stsClient = new MySTSClient(message.getExchange().get(Bus.class));
stsClient.setSoap12();
stsClient.setEndpointName(message.getExchange().getEndpoint().getEndpointInfo().getName().toString());
stsClient.setServiceName("{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService");
message.setContextualProperty(SecurityConstants.STS_CLIENT, stsClient);
AssertionInfoMap aim = message.get(AssertionInfoMap.class);
// extract Assertion information
if (aim != null) {
Collection<AssertionInfo> ais = aim.get(SP12Constants.ISSUED_TOKEN);
if (ais == null || ais.isEmpty()) {
return;
}
if (isRequestor(message)) {
IssuedToken itok = (IssuedToken) ais.iterator().next().getAssertion();
if (itok.getIssuerEpr() != null) {
// configure via mex
boolean useEPRWSAAddrAsMEXLocation = !Boolean
.valueOf((String) message
.getContextualProperty(SecurityConstants.DISABLE_STS_CLIENT_WSMEX_CALL_USING_EPR_ADDRESS));
stsClient.configureViaEPR(itok.getIssuerEpr(), useEPRWSAAddrAsMEXLocation);
}
}
}
}
}
public static class MySTSClient extends STSClient {
...
@Override
public void configureViaEPR(EndpointReferenceType ref, boolean useEPRWSAAddrAsMEXLocation) {
...
proxyFac.setBindingId(SoapBindingConstants.SOAP12_BINDING_ID);
...
"""
Thank you in advance,
Dieter
----------------
See answers bellow
>[dam] I tried creating a STSClient inside an interceptor
>(list=dispatch.client.out, phase=PREPARE_SEND,
>before=IssuedTokenOutInterceptor) and assign it to the context. I
>created the client following STSUtils#getClient(); unfortunately, it
>NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI
>because URI|location was null. In the default case, STSUtils would set
>the location from IssuedToken.EPR. What is the equivalent for my interceptor#handleMessage()? Is there a less clunky way to achieve this?
a) By default IssuedTokenOutInterceptor uses address from IssuedToken/Issuer WS-Policy element. You can do it exactly the same way:
Collection<AssertionInfo> ais = aim.get(SP12Constants.ISSUED_TOKEN);
...
IssuedToken itok = (IssuedToken)ais.iterator().next().getAssertion();
...
STSClient client = STSUtils.getClient(message, "sts", itok);
b) Other option is just create STSClient manually and set necessary properties:
STSClient stsClient = (STSClient) message.getExchange().get(SecurityConstants.STS_CLIENT);
if (stsClient == null) {
stsClient = new STSClient(message.getExchange().getBus());
}
stsClient.setWsdlLocation(stsEndpoint + "?wsdl");
stsClient.setServiceName(AuthenticationConstants.STS_SERVICE_NAME);
stsClient.setEndpointName(AuthenticationConstants.STS_ENDPOINT_NAME);
Map<String, Object> props = new HashMap<String, Object>();
props.put(SecurityConstants.STS_TOKEN_USE_CERT_FOR_KEYINFO, "true");
props.put(SecurityConstants.STS_TOKEN_USERNAME, AuthenticationConstants.CONSUMER_ALIAS);
props.put(SecurityConstants.IS_BSP_COMPLIANT, "false");
stsClient.setProperties(props);
message.getExchange().put(SecurityConstants.STS_CLIENT, stsClient);
stsEndpoint is endpoint of your STS service; AuthenticationConstants.STS_SERVICE_NAME is {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"; AuthenticationConstants.STS_ENDPOINT_NAME is "{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}X509_Port".
Here you can also set Soap 1.2 binding using stsClient.setSoap12();
>[dam] Adding the suggested properties to dispatch.requestContext did
>not add any interceptors to the STS Endpoint chain which in turn did not add the necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
Interceptors are controlled by WS-Policy and will be added automatically via InterceptorProviders. InterceptorProviders specify relationships between WS-Policy assertions and interceptors.
>[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to
>make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new SecurityFeature(mysignprops, myencprops)?
Not sure does it make sense. Setting properties in request context works for all types of clients (generated, configured via Spring/Blueprint), not only for Dispatch. But you welcome to create improvement request in CXF Jira and submit a patch.
Regards,
Andrei.
Hello,
thank you for your suggestions.
See comments below [dam].
Thank you in advance.
-------------------------
I would recommend do not configure WSS4JOutterceptor directly in code, but do it using WS-Policy.
As sample you can take http://svn.apache.org/repos/asf/cxf/branches/2.3.x-fixes/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/security/SecurityPolicyTest.java
Code looks like:
// DoubleIt.wsdl specifies WS-policy
URL wsdl = SecurityPolicyTest.class.getResource("DoubleIt.wsdl");
Service service = Service.create(wsdl, SERVICE_QNAME);
QName portQName = new QName(NAMESPACE, "DoubleItPortEncryptThenSign");
Dispatch<Source> disp = service.createDispatch(portQName, Source.class, Mode.PAYLOAD);
disp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
new KeystorePasswordCallback());
disp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
getClass().getResource("alice.properties"));
disp.getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
getClass().getResource("bob.properties"));
[dam] This approach does feel more comfortable. I had been following the WS-Security user's guide where the instructions were to use the wss4j interceptors directly.
Regarding your questions:
>2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and >fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
STSClient has setters for both SOAP versions. Default is SOAP11. Actually I do not see configuration property in code to change it. Seems only possible to create and configure own STSClient instance in your Interceptor and set it into SecurityConstants.STS_CLIENT message property to be used in IssuedTokenOutInterceptor. Will be nice to configure it via property.
[dam] I tried creating a STSClient inside an interceptor (list=dispatch.client.out, phase=PREPARE_SEND, before=IssuedTokenOutInterceptor) and assign it to the context. I created the client following STSUtils#getClient(); unfortunately, it NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI because URI|location was null. In the default case, STSUtils would set the location from IssuedToken.EPR. What is the equivalent for my interceptor#handleMessage()? Is there a less clunky way to achieve this?
>3) Although the MEX request fails, the invocation continues to call the
>STS. Since STSClient creates a new Endpoint, my wss4j settings on the
>Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
I think it should work out of the box with recommended way.
[dam] Adding the suggested properties to dispatch.requestContext did not add any interceptors to the STS Endpoint chain which in turn did not add the necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
>4) Within the wss4j settings I also include Keystore information.
>Because most of the information comes from the application, I am going
>to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Typically you just configure SecurityConstants.SIGNATURE_PROPERTIES and SecurityConstants.ENCRYPT_PROPERTIES with properties files pointing on your keystore (like in SecurityPolicyTest.java). If it is not appropriate for your use case (for example if keys are obtained dynamically), you can prepare and set your own Crypto object into message using SecurityConstants.SIGNATURE_CRYPTO, SecurityConstants.ENCRYPT_CRYPTO properties.
CXF checks these properties and will use prepared objects.
[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new SecurityFeature(mysignprops, myencprops)?
Regards,
Andrei.
Hello,
I am trying to consume a webservice; since in the end many webservices will be consumed, I am using the Dispatch interface. Since I will not know the effective webservices that are going to be consumed I cannot declare the spring beans beforehand.
The webservice declares policies that require STS tokens. The STS defines a MEX (MetaDataExchange).
The basic consumer:
Service s = Service.create($WSDL-URL, $QName); Dispatch<> d = s.createDispatch($service-name, $jaxb-context, PAYLOAD); Map<> wss4jProps = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign config ((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new WSS4JOutInterceptor(wss4jProps); d.invoke($request-message);
My questions:
1) when creating the service and dispatch objects, all referenced xsd schemas are resolved and loaded. However, by logging the made requests (in ProxySelector), I see that the same xsd get loaded repeatedly. Should they not be cached?
2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
3) Although the MEX request fails, the invocation continues to call the STS. Since STSClient creates a new Endpoint, my wss4j settings on the Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
4) Within the wss4j settings I also include Keystore information. Because most of the information comes from the application, I am going to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Thanks in advance,
Dieter
RE: Dispatching WS with WSS4J through STS
Posted by Andrei Shakirin <as...@talend.com>.
Hi,
OK, MEX call seems to be successful now.
The problem occurs on the next step by building service model from the WSDL.
Could you intercept wire message (request and response) for MEX communication and put it here?
Regards,
Andrei.
-----Original Message-----
From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches Marketing [mailto:Mitrik.Dieter@akdb.de]
Sent: Montag, 22. Oktober 2012 11:42
To: users@cxf.apache.org
Subject: AW: Dispatching WS with WSS4J through STS
Hello Andrei,
I have tried the suggestions from here and your other message. I got a little further, but there is still problems.
Here is the current exception, after working in the MEX changes:
"""
2012-10-22 11:16:26,913 [main] DEBUG org.apache.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.interceptor.StaxInEndingInterceptor@1e75e89
org.apache.cxf.wsdl11.WSDLRuntimeException: Part rstMessage defined as element {http://schemas.message.com/Message}MessageBody which is not in the schema.
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildMessage(WSDLServiceBuilder.java:865)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterfaceOperation(WSDLServiceBuilder.java:593)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterface(WSDLServiceBuilder.java:571)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:347)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:196)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:172)
at org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:119)
at *.Osci2ClientTest$MySTSClient.configureViaEPR(Osci2ClientTest.java:269)
at *.Osci2ClientTest$SetSTSClientOutInterceptor.handleMessage(Osci2ClientTest.java:223)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
"""
The service that I want to consume is: http://gov-test.osci2.bos-asp.de/OSCI2Endpoint/user/Alice , MEX=http://gov-test.osci2.bos-asp.de/governikus-sts/IdProviderUsernamePassword/mex
Here are the relevant code snippets:
"""
((DispatchImpl<?>)dispatch).getClient().getOutInterceptors().add(new SetSTSClientOutInterceptor());
...
public static class SetSTSClientOutInterceptor extends AbstractPhaseInterceptor<Message> {
public SetSTSClientOutInterceptor() {
super(Phase.PREPARE_SEND);
getBefore().add("IssuedTokenOutInterceptor");
}
@Override
public void handleMessage(Message message) throws Fault {
STSClient stsClient = new MySTSClient(message.getExchange().get(Bus.class));
stsClient.setSoap12();
stsClient.setEndpointName(message.getExchange().getEndpoint().getEndpointInfo().getName().toString());
stsClient.setServiceName("{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService");
message.setContextualProperty(SecurityConstants.STS_CLIENT, stsClient);
AssertionInfoMap aim = message.get(AssertionInfoMap.class);
// extract Assertion information
if (aim != null) {
Collection<AssertionInfo> ais = aim.get(SP12Constants.ISSUED_TOKEN);
if (ais == null || ais.isEmpty()) {
return;
}
if (isRequestor(message)) {
IssuedToken itok = (IssuedToken) ais.iterator().next().getAssertion();
if (itok.getIssuerEpr() != null) {
// configure via mex
boolean useEPRWSAAddrAsMEXLocation = !Boolean
.valueOf((String) message
.getContextualProperty(SecurityConstants.DISABLE_STS_CLIENT_WSMEX_CALL_USING_EPR_ADDRESS));
stsClient.configureViaEPR(itok.getIssuerEpr(), useEPRWSAAddrAsMEXLocation);
}
}
}
}
}
public static class MySTSClient extends STSClient {
...
@Override
public void configureViaEPR(EndpointReferenceType ref, boolean useEPRWSAAddrAsMEXLocation) {
...
proxyFac.setBindingId(SoapBindingConstants.SOAP12_BINDING_ID);
...
"""
Thank you in advance,
Dieter
----------------
See answers bellow
>[dam] I tried creating a STSClient inside an interceptor
>(list=dispatch.client.out, phase=PREPARE_SEND,
>before=IssuedTokenOutInterceptor) and assign it to the context. I
>created the client following STSUtils#getClient(); unfortunately, it
>NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI
>because URI|location was null. In the default case, STSUtils would set
>the location from IssuedToken.EPR. What is the equivalent for my interceptor#handleMessage()? Is there a less clunky way to achieve this?
a) By default IssuedTokenOutInterceptor uses address from IssuedToken/Issuer WS-Policy element. You can do it exactly the same way:
Collection<AssertionInfo> ais = aim.get(SP12Constants.ISSUED_TOKEN);
...
IssuedToken itok = (IssuedToken)ais.iterator().next().getAssertion();
...
STSClient client = STSUtils.getClient(message, "sts", itok);
b) Other option is just create STSClient manually and set necessary properties:
STSClient stsClient = (STSClient) message.getExchange().get(SecurityConstants.STS_CLIENT);
if (stsClient == null) {
stsClient = new STSClient(message.getExchange().getBus());
}
stsClient.setWsdlLocation(stsEndpoint + "?wsdl");
stsClient.setServiceName(AuthenticationConstants.STS_SERVICE_NAME);
stsClient.setEndpointName(AuthenticationConstants.STS_ENDPOINT_NAME);
Map<String, Object> props = new HashMap<String, Object>();
props.put(SecurityConstants.STS_TOKEN_USE_CERT_FOR_KEYINFO, "true");
props.put(SecurityConstants.STS_TOKEN_USERNAME, AuthenticationConstants.CONSUMER_ALIAS);
props.put(SecurityConstants.IS_BSP_COMPLIANT, "false");
stsClient.setProperties(props);
message.getExchange().put(SecurityConstants.STS_CLIENT, stsClient);
stsEndpoint is endpoint of your STS service; AuthenticationConstants.STS_SERVICE_NAME is {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"; AuthenticationConstants.STS_ENDPOINT_NAME is "{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}X509_Port".
Here you can also set Soap 1.2 binding using stsClient.setSoap12();
>[dam] Adding the suggested properties to dispatch.requestContext did
>not add any interceptors to the STS Endpoint chain which in turn did not add the necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
Interceptors are controlled by WS-Policy and will be added automatically via InterceptorProviders. InterceptorProviders specify relationships between WS-Policy assertions and interceptors.
>[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to
>make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new SecurityFeature(mysignprops, myencprops)?
Not sure does it make sense. Setting properties in request context works for all types of clients (generated, configured via Spring/Blueprint), not only for Dispatch. But you welcome to create improvement request in CXF Jira and submit a patch.
Regards,
Andrei.
Hello,
thank you for your suggestions.
See comments below [dam].
Thank you in advance.
-------------------------
I would recommend do not configure WSS4JOutterceptor directly in code, but do it using WS-Policy.
As sample you can take http://svn.apache.org/repos/asf/cxf/branches/2.3.x-fixes/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/security/SecurityPolicyTest.java
Code looks like:
// DoubleIt.wsdl specifies WS-policy
URL wsdl = SecurityPolicyTest.class.getResource("DoubleIt.wsdl");
Service service = Service.create(wsdl, SERVICE_QNAME);
QName portQName = new QName(NAMESPACE, "DoubleItPortEncryptThenSign");
Dispatch<Source> disp = service.createDispatch(portQName, Source.class, Mode.PAYLOAD);
disp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
new KeystorePasswordCallback());
disp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
getClass().getResource("alice.properties"));
disp.getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
getClass().getResource("bob.properties"));
[dam] This approach does feel more comfortable. I had been following the WS-Security user's guide where the instructions were to use the wss4j interceptors directly.
Regarding your questions:
>2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and >fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
STSClient has setters for both SOAP versions. Default is SOAP11. Actually I do not see configuration property in code to change it. Seems only possible to create and configure own STSClient instance in your Interceptor and set it into SecurityConstants.STS_CLIENT message property to be used in IssuedTokenOutInterceptor. Will be nice to configure it via property.
[dam] I tried creating a STSClient inside an interceptor (list=dispatch.client.out, phase=PREPARE_SEND, before=IssuedTokenOutInterceptor) and assign it to the context. I created the client following STSUtils#getClient(); unfortunately, it NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI because URI|location was null. In the default case, STSUtils would set the location from IssuedToken.EPR. What is the equivalent for my interceptor#handleMessage()? Is there a less clunky way to achieve this?
>3) Although the MEX request fails, the invocation continues to call the
>STS. Since STSClient creates a new Endpoint, my wss4j settings on the
>Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
I think it should work out of the box with recommended way.
[dam] Adding the suggested properties to dispatch.requestContext did not add any interceptors to the STS Endpoint chain which in turn did not add the necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
>4) Within the wss4j settings I also include Keystore information.
>Because most of the information comes from the application, I am going
>to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Typically you just configure SecurityConstants.SIGNATURE_PROPERTIES and SecurityConstants.ENCRYPT_PROPERTIES with properties files pointing on your keystore (like in SecurityPolicyTest.java). If it is not appropriate for your use case (for example if keys are obtained dynamically), you can prepare and set your own Crypto object into message using SecurityConstants.SIGNATURE_CRYPTO, SecurityConstants.ENCRYPT_CRYPTO properties.
CXF checks these properties and will use prepared objects.
[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new SecurityFeature(mysignprops, myencprops)?
Regards,
Andrei.
Hello,
I am trying to consume a webservice; since in the end many webservices will be consumed, I am using the Dispatch interface. Since I will not know the effective webservices that are going to be consumed I cannot declare the spring beans beforehand.
The webservice declares policies that require STS tokens. The STS defines a MEX (MetaDataExchange).
The basic consumer:
Service s = Service.create($WSDL-URL, $QName); Dispatch<> d = s.createDispatch($service-name, $jaxb-context, PAYLOAD); Map<> wss4jProps = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign config ((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new WSS4JOutInterceptor(wss4jProps); d.invoke($request-message);
My questions:
1) when creating the service and dispatch objects, all referenced xsd schemas are resolved and loaded. However, by logging the made requests (in ProxySelector), I see that the same xsd get loaded repeatedly. Should they not be cached?
2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
3) Although the MEX request fails, the invocation continues to call the STS. Since STSClient creates a new Endpoint, my wss4j settings on the Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
4) Within the wss4j settings I also include Keystore information. Because most of the information comes from the application, I am going to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Thanks in advance,
Dieter
AW: Dispatching WS with WSS4J through STS
Posted by Mitrik,
A15 Entwicklung Qualitätsmanagement und technisches Marketing <Mi...@akdb.de>.
Hello Andrei,
I have tried the suggestions from here and your other message. I got a little further, but there is still problems.
Here is the current exception, after working in the MEX changes:
"""
2012-10-22 11:16:26,913 [main] DEBUG org.apache.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor org.apache.cxf.interceptor.StaxInEndingInterceptor@1e75e89
org.apache.cxf.wsdl11.WSDLRuntimeException: Part rstMessage defined as element {http://schemas.message.com/Message}MessageBody which is not in the schema.
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildMessage(WSDLServiceBuilder.java:865)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterfaceOperation(WSDLServiceBuilder.java:593)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildInterface(WSDLServiceBuilder.java:571)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:347)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:196)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:172)
at org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:119)
at *.Osci2ClientTest$MySTSClient.configureViaEPR(Osci2ClientTest.java:269)
at *.Osci2ClientTest$SetSTSClientOutInterceptor.handleMessage(Osci2ClientTest.java:223)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
"""
The service that I want to consume is: http://gov-test.osci2.bos-asp.de/OSCI2Endpoint/user/Alice , MEX=http://gov-test.osci2.bos-asp.de/governikus-sts/IdProviderUsernamePassword/mex
Here are the relevant code snippets:
"""
((DispatchImpl<?>)dispatch).getClient().getOutInterceptors().add(new SetSTSClientOutInterceptor());
...
public static class SetSTSClientOutInterceptor extends AbstractPhaseInterceptor<Message> {
public SetSTSClientOutInterceptor() {
super(Phase.PREPARE_SEND);
getBefore().add("IssuedTokenOutInterceptor");
}
@Override
public void handleMessage(Message message) throws Fault {
STSClient stsClient = new MySTSClient(message.getExchange().get(Bus.class));
stsClient.setSoap12();
stsClient.setEndpointName(message.getExchange().getEndpoint().getEndpointInfo().getName().toString());
stsClient.setServiceName("{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService");
message.setContextualProperty(SecurityConstants.STS_CLIENT, stsClient);
AssertionInfoMap aim = message.get(AssertionInfoMap.class);
// extract Assertion information
if (aim != null) {
Collection<AssertionInfo> ais = aim.get(SP12Constants.ISSUED_TOKEN);
if (ais == null || ais.isEmpty()) {
return;
}
if (isRequestor(message)) {
IssuedToken itok = (IssuedToken) ais.iterator().next().getAssertion();
if (itok.getIssuerEpr() != null) {
// configure via mex
boolean useEPRWSAAddrAsMEXLocation = !Boolean
.valueOf((String) message
.getContextualProperty(SecurityConstants.DISABLE_STS_CLIENT_WSMEX_CALL_USING_EPR_ADDRESS));
stsClient.configureViaEPR(itok.getIssuerEpr(), useEPRWSAAddrAsMEXLocation);
}
}
}
}
}
public static class MySTSClient extends STSClient {
...
@Override
public void configureViaEPR(EndpointReferenceType ref, boolean useEPRWSAAddrAsMEXLocation) {
...
proxyFac.setBindingId(SoapBindingConstants.SOAP12_BINDING_ID);
...
"""
Thank you in advance,
Dieter
----------------
See answers bellow
>[dam] I tried creating a STSClient inside an interceptor
>(list=dispatch.client.out, phase=PREPARE_SEND,
>before=IssuedTokenOutInterceptor) and assign it to the context. I
>created the client following STSUtils#getClient(); unfortunately, it
>NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI
>because URI|location was null. In the default case, STSUtils would set
>the location from IssuedToken.EPR. What is the equivalent for my interceptor#handleMessage()? Is there a less clunky way to achieve this?
a) By default IssuedTokenOutInterceptor uses address from IssuedToken/Issuer WS-Policy element. You can do it exactly the same way:
Collection<AssertionInfo> ais = aim.get(SP12Constants.ISSUED_TOKEN);
...
IssuedToken itok = (IssuedToken)ais.iterator().next().getAssertion();
...
STSClient client = STSUtils.getClient(message, "sts", itok);
b) Other option is just create STSClient manually and set necessary properties:
STSClient stsClient = (STSClient) message.getExchange().get(SecurityConstants.STS_CLIENT);
if (stsClient == null) {
stsClient = new STSClient(message.getExchange().getBus());
}
stsClient.setWsdlLocation(stsEndpoint + "?wsdl");
stsClient.setServiceName(AuthenticationConstants.STS_SERVICE_NAME);
stsClient.setEndpointName(AuthenticationConstants.STS_ENDPOINT_NAME);
Map<String, Object> props = new HashMap<String, Object>();
props.put(SecurityConstants.STS_TOKEN_USE_CERT_FOR_KEYINFO, "true");
props.put(SecurityConstants.STS_TOKEN_USERNAME, AuthenticationConstants.CONSUMER_ALIAS);
props.put(SecurityConstants.IS_BSP_COMPLIANT, "false");
stsClient.setProperties(props);
message.getExchange().put(SecurityConstants.STS_CLIENT, stsClient);
stsEndpoint is endpoint of your STS service; AuthenticationConstants.STS_SERVICE_NAME is {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"; AuthenticationConstants.STS_ENDPOINT_NAME is "{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}X509_Port".
Here you can also set Soap 1.2 binding using stsClient.setSoap12();
>[dam] Adding the suggested properties to dispatch.requestContext did
>not add any interceptors to the STS Endpoint chain which in turn did not add the necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
Interceptors are controlled by WS-Policy and will be added automatically via InterceptorProviders. InterceptorProviders specify relationships between WS-Policy assertions and interceptors.
>[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to
>make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new SecurityFeature(mysignprops, myencprops)?
Not sure does it make sense. Setting properties in request context works for all types of clients (generated, configured via Spring/Blueprint), not only for Dispatch. But you welcome to create improvement request in CXF Jira and submit a patch.
Regards,
Andrei.
Hello,
thank you for your suggestions.
See comments below [dam].
Thank you in advance.
-------------------------
I would recommend do not configure WSS4JOutterceptor directly in code, but do it using WS-Policy.
As sample you can take http://svn.apache.org/repos/asf/cxf/branches/2.3.x-fixes/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/security/SecurityPolicyTest.java
Code looks like:
// DoubleIt.wsdl specifies WS-policy
URL wsdl = SecurityPolicyTest.class.getResource("DoubleIt.wsdl");
Service service = Service.create(wsdl, SERVICE_QNAME);
QName portQName = new QName(NAMESPACE, "DoubleItPortEncryptThenSign");
Dispatch<Source> disp = service.createDispatch(portQName, Source.class, Mode.PAYLOAD);
disp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
new KeystorePasswordCallback());
disp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
getClass().getResource("alice.properties"));
disp.getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
getClass().getResource("bob.properties"));
[dam] This approach does feel more comfortable. I had been following the WS-Security user's guide where the instructions were to use the wss4j interceptors directly.
Regarding your questions:
>2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and >fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
STSClient has setters for both SOAP versions. Default is SOAP11. Actually I do not see configuration property in code to change it. Seems only possible to create and configure own STSClient instance in your Interceptor and set it into SecurityConstants.STS_CLIENT message property to be used in IssuedTokenOutInterceptor. Will be nice to configure it via property.
[dam] I tried creating a STSClient inside an interceptor (list=dispatch.client.out, phase=PREPARE_SEND, before=IssuedTokenOutInterceptor) and assign it to the context. I created the client following STSUtils#getClient(); unfortunately, it NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI because URI|location was null. In the default case, STSUtils would set the location from IssuedToken.EPR. What is the equivalent for my interceptor#handleMessage()? Is there a less clunky way to achieve this?
>3) Although the MEX request fails, the invocation continues to call the
>STS. Since STSClient creates a new Endpoint, my wss4j settings on the
>Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
I think it should work out of the box with recommended way.
[dam] Adding the suggested properties to dispatch.requestContext did not add any interceptors to the STS Endpoint chain which in turn did not add the necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
>4) Within the wss4j settings I also include Keystore information.
>Because most of the information comes from the application, I am going
>to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Typically you just configure SecurityConstants.SIGNATURE_PROPERTIES and SecurityConstants.ENCRYPT_PROPERTIES with properties files pointing on your keystore (like in SecurityPolicyTest.java). If it is not appropriate for your use case (for example if keys are obtained dynamically), you can prepare and set your own Crypto object into message using SecurityConstants.SIGNATURE_CRYPTO, SecurityConstants.ENCRYPT_CRYPTO properties.
CXF checks these properties and will use prepared objects.
[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new SecurityFeature(mysignprops, myencprops)?
Regards,
Andrei.
Hello,
I am trying to consume a webservice; since in the end many webservices will be consumed, I am using the Dispatch interface. Since I will not know the effective webservices that are going to be consumed I cannot declare the spring beans beforehand.
The webservice declares policies that require STS tokens. The STS defines a MEX (MetaDataExchange).
The basic consumer:
Service s = Service.create($WSDL-URL, $QName); Dispatch<> d = s.createDispatch($service-name, $jaxb-context, PAYLOAD); Map<> wss4jProps = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign config ((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new WSS4JOutInterceptor(wss4jProps); d.invoke($request-message);
My questions:
1) when creating the service and dispatch objects, all referenced xsd schemas are resolved and loaded. However, by logging the made requests (in ProxySelector), I see that the same xsd get loaded repeatedly. Should they not be cached?
2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
3) Although the MEX request fails, the invocation continues to call the STS. Since STSClient creates a new Endpoint, my wss4j settings on the Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
4) Within the wss4j settings I also include Keystore information. Because most of the information comes from the application, I am going to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Thanks in advance,
Dieter
RE: Dispatching WS with WSS4J through STS
Posted by Andrei Shakirin <as...@talend.com>.
See answers bellow
>[dam] I tried creating a STSClient inside an interceptor (list=dispatch.client.out, phase=PREPARE_SEND, before=IssuedTokenOutInterceptor) and assign it to
>the context. I created the client following STSUtils#getClient(); unfortunately, it NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI
>because URI|location was null. In the default case, STSUtils would set the location from IssuedToken.EPR. What is the equivalent for my
>interceptor#handleMessage()? Is there a less clunky way to achieve this?
a) By default IssuedTokenOutInterceptor uses address from IssuedToken/Issuer WS-Policy element. You can do it exactly the same way:
Collection<AssertionInfo> ais = aim.get(SP12Constants.ISSUED_TOKEN);
...
IssuedToken itok = (IssuedToken)ais.iterator().next().getAssertion();
...
STSClient client = STSUtils.getClient(message, "sts", itok);
b) Other option is just create STSClient manually and set necessary properties:
STSClient stsClient = (STSClient) message.getExchange().get(SecurityConstants.STS_CLIENT);
if (stsClient == null) {
stsClient = new STSClient(message.getExchange().getBus());
}
stsClient.setWsdlLocation(stsEndpoint + "?wsdl");
stsClient.setServiceName(AuthenticationConstants.STS_SERVICE_NAME);
stsClient.setEndpointName(AuthenticationConstants.STS_ENDPOINT_NAME);
Map<String, Object> props = new HashMap<String, Object>();
props.put(SecurityConstants.STS_TOKEN_USE_CERT_FOR_KEYINFO, "true");
props.put(SecurityConstants.STS_TOKEN_USERNAME, AuthenticationConstants.CONSUMER_ALIAS);
props.put(SecurityConstants.IS_BSP_COMPLIANT, "false");
stsClient.setProperties(props);
message.getExchange().put(SecurityConstants.STS_CLIENT, stsClient);
stsEndpoint is endpoint of your STS service;
AuthenticationConstants.STS_SERVICE_NAME is {http://docs.oasis-open.org/ws-sx/ws-trust/200512/}SecurityTokenService"; AuthenticationConstants.STS_ENDPOINT_NAME is "{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}X509_Port".
Here you can also set Soap 1.2 binding using stsClient.setSoap12();
>[dam] Adding the suggested properties to dispatch.requestContext did not add any interceptors to the STS Endpoint chain which in turn did not add the
>necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
Interceptors are controlled by WS-Policy and will be added automatically via InterceptorProviders. InterceptorProviders specify relationships between WS-Policy assertions and interceptors.
>[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new
>SecurityFeature(mysignprops, myencprops)?
Not sure does it make sense. Setting properties in request context works for all types of clients (generated, configured via Spring/Blueprint), not only for Dispatch. But you welcome to create improvement request in CXF Jira and submit a patch.
Regards,
Andrei.
-----Original Message-----
From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches Marketing [mailto:Mitrik.Dieter@akdb.de]
Sent: Freitag, 19. Oktober 2012 15:33
To: users@cxf.apache.org
Subject: AW: Dispatching WS with WSS4J through STS
Hello,
thank you for your suggestions.
See comments below [dam].
Thank you in advance.
-------------------------
I would recommend do not configure WSS4JOutterceptor directly in code, but do it using WS-Policy.
As sample you can take http://svn.apache.org/repos/asf/cxf/branches/2.3.x-fixes/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/security/SecurityPolicyTest.java
Code looks like:
// DoubleIt.wsdl specifies WS-policy
URL wsdl = SecurityPolicyTest.class.getResource("DoubleIt.wsdl");
Service service = Service.create(wsdl, SERVICE_QNAME);
QName portQName = new QName(NAMESPACE, "DoubleItPortEncryptThenSign");
Dispatch<Source> disp = service.createDispatch(portQName, Source.class, Mode.PAYLOAD);
disp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
new KeystorePasswordCallback());
disp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
getClass().getResource("alice.properties"));
disp.getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
getClass().getResource("bob.properties"));
[dam] This approach does feel more comfortable. I had been following the WS-Security user's guide where the instructions were to use the wss4j interceptors directly.
Regarding your questions:
>2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and >fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
STSClient has setters for both SOAP versions. Default is SOAP11. Actually I do not see configuration property in code to change it. Seems only possible to create and configure own STSClient instance in your Interceptor and set it into SecurityConstants.STS_CLIENT message property to be used in IssuedTokenOutInterceptor. Will be nice to configure it via property.
[dam] I tried creating a STSClient inside an interceptor (list=dispatch.client.out, phase=PREPARE_SEND, before=IssuedTokenOutInterceptor) and assign it to the context. I created the client following STSUtils#getClient(); unfortunately, it NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI because URI|location was null. In the default case, STSUtils would set the location from IssuedToken.EPR. What is the equivalent for my interceptor#handleMessage()? Is there a less clunky way to achieve this?
>3) Although the MEX request fails, the invocation continues to call the
>STS. Since STSClient creates a new Endpoint, my wss4j settings on the
>Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
I think it should work out of the box with recommended way.
[dam] Adding the suggested properties to dispatch.requestContext did not add any interceptors to the STS Endpoint chain which in turn did not add the necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
>4) Within the wss4j settings I also include Keystore information.
>Because most of the information comes from the application, I am going
>to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Typically you just configure SecurityConstants.SIGNATURE_PROPERTIES and SecurityConstants.ENCRYPT_PROPERTIES with properties files pointing on your keystore (like in SecurityPolicyTest.java). If it is not appropriate for your use case (for example if keys are obtained dynamically), you can prepare and set your own Crypto object into message using SecurityConstants.SIGNATURE_CRYPTO, SecurityConstants.ENCRYPT_CRYPTO properties.
CXF checks these properties and will use prepared objects.
[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new SecurityFeature(mysignprops, myencprops)?
Regards,
Andrei.
-----Original Message-----
From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches Marketing [mailto:Mitrik.Dieter@akdb.de]
Sent: Freitag, 19. Oktober 2012 11:15
To: users@cxf.apache.org
Subject: Dispatching WS with WSS4J through STS
Hello,
I am trying to consume a webservice; since in the end many webservices will be consumed, I am using the Dispatch interface. Since I will not know the effective webservices that are going to be consumed I cannot declare the spring beans beforehand.
The webservice declares policies that require STS tokens. The STS defines a MEX (MetaDataExchange).
The basic consumer:
Service s = Service.create($WSDL-URL, $QName); Dispatch<> d = s.createDispatch($service-name, $jaxb-context, PAYLOAD); Map<> wss4jProps = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign config ((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new WSS4JOutInterceptor(wss4jProps); d.invoke($request-message);
My questions:
1) when creating the service and dispatch objects, all referenced xsd schemas are resolved and loaded. However, by logging the made requests (in ProxySelector), I see that the same xsd get loaded repeatedly. Should they not be cached?
2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
3) Although the MEX request fails, the invocation continues to call the STS. Since STSClient creates a new Endpoint, my wss4j settings on the Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
4) Within the wss4j settings I also include Keystore information. Because most of the information comes from the application, I am going to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Thanks in advance,
Dieter
RE: Dispatching WS with WSS4J through STS
Posted by Andrei Shakirin <as...@talend.com>.
Hi,
I have investigated your Soap 1.2 problem deeply:
as far as you have this problem already by MEX call, actually there is no simple way to configure it in STSClient.
STSClient.soapVersion used only for STS call, not for the MEX.
You can do the following: wrap CXF STS client in own class and override STSClient.configureViaEPR() method.
Overridden method will behave the same, except MEX call.
You can set Soap1.2 binding id for MEX proxy factory:
...
JaxWsProxyFactoryBean proxyFac = new JaxWsProxyFactoryBean();
proxyFac.setAddress(mexLoc);
proxyFac.setBindingId(SoapBindingConstants.SOAP12_BINDING_ID);
MetadataExchange exc = proxyFac.create(MetadataExchange.class);
Metadata metadata = exc.get2004();
...
I hope this helps.
Regards,
Andrei.
-----Original Message-----
From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches Marketing [mailto:Mitrik.Dieter@akdb.de]
Sent: Freitag, 19. Oktober 2012 15:33
To: users@cxf.apache.org
Subject: AW: Dispatching WS with WSS4J through STS
Hello,
thank you for your suggestions.
See comments below [dam].
Thank you in advance.
-------------------------
I would recommend do not configure WSS4JOutterceptor directly in code, but do it using WS-Policy.
As sample you can take http://svn.apache.org/repos/asf/cxf/branches/2.3.x-fixes/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/security/SecurityPolicyTest.java
Code looks like:
// DoubleIt.wsdl specifies WS-policy
URL wsdl = SecurityPolicyTest.class.getResource("DoubleIt.wsdl");
Service service = Service.create(wsdl, SERVICE_QNAME);
QName portQName = new QName(NAMESPACE, "DoubleItPortEncryptThenSign");
Dispatch<Source> disp = service.createDispatch(portQName, Source.class, Mode.PAYLOAD);
disp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
new KeystorePasswordCallback());
disp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
getClass().getResource("alice.properties"));
disp.getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
getClass().getResource("bob.properties"));
[dam] This approach does feel more comfortable. I had been following the WS-Security user's guide where the instructions were to use the wss4j interceptors directly.
Regarding your questions:
>2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and >fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
STSClient has setters for both SOAP versions. Default is SOAP11. Actually I do not see configuration property in code to change it. Seems only possible to create and configure own STSClient instance in your Interceptor and set it into SecurityConstants.STS_CLIENT message property to be used in IssuedTokenOutInterceptor. Will be nice to configure it via property.
[dam] I tried creating a STSClient inside an interceptor (list=dispatch.client.out, phase=PREPARE_SEND, before=IssuedTokenOutInterceptor) and assign it to the context. I created the client following STSUtils#getClient(); unfortunately, it NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI because URI|location was null. In the default case, STSUtils would set the location from IssuedToken.EPR. What is the equivalent for my interceptor#handleMessage()? Is there a less clunky way to achieve this?
>3) Although the MEX request fails, the invocation continues to call the
>STS. Since STSClient creates a new Endpoint, my wss4j settings on the
>Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
I think it should work out of the box with recommended way.
[dam] Adding the suggested properties to dispatch.requestContext did not add any interceptors to the STS Endpoint chain which in turn did not add the necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
>4) Within the wss4j settings I also include Keystore information.
>Because most of the information comes from the application, I am going
>to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Typically you just configure SecurityConstants.SIGNATURE_PROPERTIES and SecurityConstants.ENCRYPT_PROPERTIES with properties files pointing on your keystore (like in SecurityPolicyTest.java). If it is not appropriate for your use case (for example if keys are obtained dynamically), you can prepare and set your own Crypto object into message using SecurityConstants.SIGNATURE_CRYPTO, SecurityConstants.ENCRYPT_CRYPTO properties.
CXF checks these properties and will use prepared objects.
[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new SecurityFeature(mysignprops, myencprops)?
Regards,
Andrei.
-----Original Message-----
From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches Marketing [mailto:Mitrik.Dieter@akdb.de]
Sent: Freitag, 19. Oktober 2012 11:15
To: users@cxf.apache.org
Subject: Dispatching WS with WSS4J through STS
Hello,
I am trying to consume a webservice; since in the end many webservices will be consumed, I am using the Dispatch interface. Since I will not know the effective webservices that are going to be consumed I cannot declare the spring beans beforehand.
The webservice declares policies that require STS tokens. The STS defines a MEX (MetaDataExchange).
The basic consumer:
Service s = Service.create($WSDL-URL, $QName); Dispatch<> d = s.createDispatch($service-name, $jaxb-context, PAYLOAD); Map<> wss4jProps = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign config ((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new WSS4JOutInterceptor(wss4jProps); d.invoke($request-message);
My questions:
1) when creating the service and dispatch objects, all referenced xsd schemas are resolved and loaded. However, by logging the made requests (in ProxySelector), I see that the same xsd get loaded repeatedly. Should they not be cached?
2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
3) Although the MEX request fails, the invocation continues to call the STS. Since STSClient creates a new Endpoint, my wss4j settings on the Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
4) Within the wss4j settings I also include Keystore information. Because most of the information comes from the application, I am going to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Thanks in advance,
Dieter
AW: Dispatching WS with WSS4J through STS
Posted by Mitrik,
A15 Entwicklung Qualitätsmanagement und technisches Marketing <Mi...@akdb.de>.
Hello,
thank you for your suggestions.
See comments below [dam].
Thank you in advance.
-------------------------
I would recommend do not configure WSS4JOutterceptor directly in code, but do it using WS-Policy.
As sample you can take http://svn.apache.org/repos/asf/cxf/branches/2.3.x-fixes/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/security/SecurityPolicyTest.java
Code looks like:
// DoubleIt.wsdl specifies WS-policy
URL wsdl = SecurityPolicyTest.class.getResource("DoubleIt.wsdl");
Service service = Service.create(wsdl, SERVICE_QNAME);
QName portQName = new QName(NAMESPACE, "DoubleItPortEncryptThenSign");
Dispatch<Source> disp = service.createDispatch(portQName, Source.class, Mode.PAYLOAD);
disp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
new KeystorePasswordCallback());
disp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
getClass().getResource("alice.properties"));
disp.getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
getClass().getResource("bob.properties"));
[dam] This approach does feel more comfortable. I had been following the WS-Security user's guide where the instructions were to use the wss4j interceptors directly.
Regarding your questions:
>2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and >fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
STSClient has setters for both SOAP versions. Default is SOAP11. Actually I do not see configuration property in code to change it. Seems only possible to create and configure own STSClient instance in your Interceptor and set it into SecurityConstants.STS_CLIENT message property to be used in IssuedTokenOutInterceptor. Will be nice to configure it via property.
[dam] I tried creating a STSClient inside an interceptor (list=dispatch.client.out, phase=PREPARE_SEND, before=IssuedTokenOutInterceptor) and assign it to the context. I created the client following STSUtils#getClient(); unfortunately, it NPEed at org.apache.cxf.transport.TransportFinder.findTransportForURI because URI|location was null. In the default case, STSUtils would set the location from IssuedToken.EPR. What is the equivalent for my interceptor#handleMessage()? Is there a less clunky way to achieve this?
>3) Although the MEX request fails, the invocation continues to call the
>STS. Since STSClient creates a new Endpoint, my wss4j settings on the
>Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
I think it should work out of the box with recommended way.
[dam] Adding the suggested properties to dispatch.requestContext did not add any interceptors to the STS Endpoint chain which in turn did not add the necessary elements into the outgoing message. Is this a consequence of the failing MEX above? Where would the interceptors have been injected?
>4) Within the wss4j settings I also include Keystore information.
>Because most of the information comes from the application, I am going
>to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Typically you just configure SecurityConstants.SIGNATURE_PROPERTIES and SecurityConstants.ENCRYPT_PROPERTIES with properties files pointing on your keystore (like in SecurityPolicyTest.java). If it is not appropriate for your use case (for example if keys are obtained dynamically), you can prepare and set your own Crypto object into message using SecurityConstants.SIGNATURE_CRYPTO, SecurityConstants.ENCRYPT_CRYPTO properties.
CXF checks these properties and will use prepared objects.
[dam] Thanks, this is more to my liking. Wouldn't it be even nicer to make a WebServiceFeature out of this, so that service.createDispatch(..,..,.., new SecurityFeature(mysignprops, myencprops)?
Regards,
Andrei.
-----Original Message-----
From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches Marketing [mailto:Mitrik.Dieter@akdb.de]
Sent: Freitag, 19. Oktober 2012 11:15
To: users@cxf.apache.org
Subject: Dispatching WS with WSS4J through STS
Hello,
I am trying to consume a webservice; since in the end many webservices will be consumed, I am using the Dispatch interface. Since I will not know the effective webservices that are going to be consumed I cannot declare the spring beans beforehand.
The webservice declares policies that require STS tokens. The STS defines a MEX (MetaDataExchange).
The basic consumer:
Service s = Service.create($WSDL-URL, $QName); Dispatch<> d = s.createDispatch($service-name, $jaxb-context, PAYLOAD); Map<> wss4jProps = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign config ((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new WSS4JOutInterceptor(wss4jProps); d.invoke($request-message);
My questions:
1) when creating the service and dispatch objects, all referenced xsd schemas are resolved and loaded. However, by logging the made requests (in ProxySelector), I see that the same xsd get loaded repeatedly. Should they not be cached?
2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
3) Although the MEX request fails, the invocation continues to call the STS. Since STSClient creates a new Endpoint, my wss4j settings on the Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
4) Within the wss4j settings I also include Keystore information. Because most of the information comes from the application, I am going to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Thanks in advance,
Dieter
RE: Dispatching WS with WSS4J through STS
Posted by Andrei Shakirin <as...@talend.com>.
I would recommend do not configure WSS4JOutterceptor directly in code, but do it using WS-Policy.
As sample you can take http://svn.apache.org/repos/asf/cxf/branches/2.3.x-fixes/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/security/SecurityPolicyTest.java
Code looks like:
// DoubleIt.wsdl specifies WS-policy
URL wsdl = SecurityPolicyTest.class.getResource("DoubleIt.wsdl");
Service service = Service.create(wsdl, SERVICE_QNAME);
QName portQName = new QName(NAMESPACE, "DoubleItPortEncryptThenSign");
Dispatch<Source> disp = service.createDispatch(portQName, Source.class, Mode.PAYLOAD);
disp.getRequestContext().put(SecurityConstants.CALLBACK_HANDLER,
new KeystorePasswordCallback());
disp.getRequestContext().put(SecurityConstants.SIGNATURE_PROPERTIES,
getClass().getResource("alice.properties"));
disp.getRequestContext().put(SecurityConstants.ENCRYPT_PROPERTIES,
getClass().getResource("bob.properties"));
Regarding your questions:
>2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and >fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
STSClient has setters for both SOAP versions. Default is SOAP11. Actually I do not see configuration property in code to change it. Seems only possible to create and configure own STSClient instance in your Interceptor and set it into SecurityConstants.STS_CLIENT message property to be used in IssuedTokenOutInterceptor. Will be nice to configure it via property.
>3) Although the MEX request fails, the invocation continues to call the STS. Since STSClient creates a new Endpoint, my wss4j settings on the Dispatch have no
>effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to
>repeat the wss4j settings?
I think it should work out of the box with recommended way.
>4) Within the wss4j settings I also include Keystore information. Because most of the information comes from the application, I am going to preconfigure a
>Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the
>implicit STSClient Endpoint request?
Typically you just configure SecurityConstants.SIGNATURE_PROPERTIES and SecurityConstants.ENCRYPT_PROPERTIES with properties files pointing on your keystore (like in SecurityPolicyTest.java). If it is not appropriate for your use case (for example if keys are obtained dynamically), you can prepare and set your own Crypto object into message using SecurityConstants.SIGNATURE_CRYPTO, SecurityConstants.ENCRYPT_CRYPTO properties.
CXF checks these properties and will use prepared objects.
Regards,
Andrei.
-----Original Message-----
From: Mitrik Dieter, A15 Entwicklung Qualitätsmanagement und technisches Marketing [mailto:Mitrik.Dieter@akdb.de]
Sent: Freitag, 19. Oktober 2012 11:15
To: users@cxf.apache.org
Subject: Dispatching WS with WSS4J through STS
Hello,
I am trying to consume a webservice; since in the end many webservices will be consumed, I am using the Dispatch interface. Since I will not know the effective webservices that are going to be consumed I cannot declare the spring beans beforehand.
The webservice declares policies that require STS tokens. The STS defines a MEX (MetaDataExchange).
The basic consumer:
Service s = Service.create($WSDL-URL, $QName); Dispatch<> d = s.createDispatch($service-name, $jaxb-context, PAYLOAD); Map<> wss4jProps = createWSS4JProps(); // with username, pwd, certificates, encrypt, sign config ((DispatchImpl<>)d).getClient().getEndpoint().getOutInterceptors().add(new WSS4JOutInterceptor(wss4jProps); d.invoke($request-message);
My questions:
1) when creating the service and dispatch objects, all referenced xsd schemas are resolved and loaded. However, by logging the made requests (in ProxySelector), I see that the same xsd get loaded repeatedly. Should they not be cached?
2) The created service itself is a SOAP12 endpoint; however, the MEX endpoint instantiated through STSClient uses SOAP11. The server expects SOAP12 and fails if requested by SOAP11. How do I force the MEX call to use SOAP12 instead of SOAP11?
3) Although the MEX request fails, the invocation continues to call the STS. Since STSClient creates a new Endpoint, my wss4j settings on the Dispatch have no effect. How can I make the STSClient Endpoint inherit its Dispatch's wss4j settings? Or how can I identify the created Endpoint in a ClientLifecycleListener to repeat the wss4j settings?
4) Within the wss4j settings I also include Keystore information. Because most of the information comes from the application, I am going to preconfigure a Crypto object by SIG_PROP_REF_ID, which contains the name of a context property. Which one is the effective context to add the Crypto object to for the implicit STSClient Endpoint request?
Thanks in advance,
Dieter