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:[email protected]] Sent: Freitag, 19. Oktober 2012 11:15 To: [email protected] 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
