Oh, well that explains it then. Thanx! Stephen W. Chappell
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] Sent: Wednesday, March 23, 2016 8:45 AM To: Chappell, Stephen CTR (FAA) Cc: users@cxf.apache.org Subject: Re: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection? That's because there are no security policies that support RSA-SHA256 as the specs are quite old now, so CXF gives you the option of overriding the signature algorithm via a configuration parameter. Colm. On Wed, Mar 23, 2016 at 12:38 PM, <stephen.ctr.chapp...@faa.gov<mailto:stephen.ctr.chapp...@faa.gov>> wrote: Solved. Sucking in the WSDL and using the WS-SecurityPolicy did the trick, once I set up the ws-security.signature.* properties in the property map. One weird thing though is that I had to explicitly set the signature algorithm ... <property name="properties"> <map> ... <entry key="ws-security.asymmetric.signature.algorithm" value="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> </map> </property> It was no problem to do that, but it seems weird since everything else got configured from the policy. Thanx, Stephen W. Chappell -----Original Message----- From: Chappell, Stephen CTR (FAA) Sent: Wednesday, March 23, 2016 7:47 AM To: cohei...@apache.org<mailto:cohei...@apache.org> Cc: users@cxf.apache.org<mailto:users@cxf.apache.org> Subject: RE: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection? I was used to using the interceptors from other projects, so I didn’t really give it any thought; but it does make more sense to use the policy approach. Now if I can just get the property map configured right … Stephen W. Chappell From: Colm O hEigeartaigh [mailto:cohei...@apache.org<mailto:cohei...@apache.org>] Sent: Wednesday, March 23, 2016 7:40 AM To: Chappell, Stephen CTR (FAA) Cc: users@cxf.apache.org<mailto:users@cxf.apache.org> Subject: Re: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection? I guess so. It's unusual to use the WSS4J interceptors when invoking on the STS, all of the testing is done with WS-SecurityPolicy. Colm. On Wed, Mar 23, 2016 at 11:37 AM, <stephen.ctr.chapp...@faa.gov<mailto:stephen.ctr.chapp...@faa.gov><mailto:stephen.ctr.chapp...@faa.gov<mailto:stephen.ctr.chapp...@faa.gov>>> wrote: Yeah, that is exactly what my wsdl looks like. I think the problem is that I didn't specify a wsdlLocation in my client bean, only a location. That worked fine for the issue operation, but not at all for validate. So I tried configuring that and ran into some new problems, which I think is because the WSDL specifies security policy and the client uses WSS4JOutInterceptors to configure the outbound security. This is my client bean configuration: <bean name="stsClient" class="gov.faa.iam.sts.STSClientSSPS"> <constructor-arg ref="cxf"/> <!-- <property name="location" value="http://localhost:9080/FAA-IAM-STS/STS-BST"/> --> <property name="wsdlLocation" value="http://localhost:9080/FAA-IAM-STS/STS-BST?wsdl"/> <property name="serviceName" value="{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}BSTSecurityTokenService<http://docs.oasis-open.org/ws-sx/ws-trust/200512/%7dBSTSecurityTokenService><http://docs.oasis-open.org/ws-sx/ws-trust/200512/%7dBSTSecurityTokenService>"/> <property name="endpointName" value="{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}STS_Port<http://docs.oasis-open.org/ws-sx/ws-trust/200512/%7dSTS_Port><http://docs.oasis-open.org/ws-sx/ws-trust/200512/%7dSTS_Port>"/> <property name="useCertificateForConfirmationKeyInfo" value="true" /> <property name="features"> <list> <ref bean="wsAddressingFeature"/> </list> </property> <property name="inInterceptors"> <list> <ref bean="inTimerInterceptor"/> </list> </property> <property name="outInterceptors"> <list> <ref bean="wss4jOutInterceptor"/> <ref bean="outTimerInterceptor"/> </list> </property> <property name="properties"> <map> <entry key="ws-security.sts.token.username" value="test-user (test ca 1)"/> <entry key="ws-security.sts.token.properties" value-ref="cryptoProperties"/> </map> </property> <!-- CXF 2.7 adds Renewing properties --> <property name="sendRenewing" value="false"/> </bean> So I'm working on configuring the right properties in the property map to make it all work. Am I on the right track with that? Thanx, Stephen W. Chappell -----Original Message----- From: Colm O hEigeartaigh [mailto:cohei...@apache.org<mailto:cohei...@apache.org><mailto:cohei...@apache.org<mailto:cohei...@apache.org>>] Sent: Wednesday, March 23, 2016 7:27 AM To: users@cxf.apache.org<mailto:users@cxf.apache.org><mailto:users@cxf.apache.org<mailto:users@cxf.apache.org>> Subject: Re: STSClient.validateSecurityToken expects RequestSecurityTokenResponseCollection? What does your WSDL look like? At a guess it is expecting the Collection to be returned as opposed to the single element. The portType should look something like: <wsdl:operation name="Validate"> <wsdl:input wsam:Action=" http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate"; message="tns:RequestSecurityTokenMsg"/> <wsdl:output wsam:Action=" http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ValidateFinal"; message="tns:RequestSecurityTokenResponseMsg"/> </wsdl:operation> Colm. On Tue, Mar 22, 2016 at 5:44 PM, <stephen.ctr.chapp...@faa.gov<mailto:stephen.ctr.chapp...@faa.gov><mailto:stephen.ctr.chapp...@faa.gov<mailto:stephen.ctr.chapp...@faa.gov>>> wrote: > Hi - > > I'm using the CXF 3.1.4 STSClient to write a simple test client for my > CXF-based STS. Requesting tokens has worked as expected, but > requesting validation of a token is having a problem. It would appear > that STSClient creates a proper RST, and gets a proper RSTR from the > STS. But something deep inside the stack is expecting a > RequestSecurityTokenResponseCollection > instead of a RequestSecurityTokenResponse, which is causing this exception: > > org.apache.cxf.interceptor.Fault: Unexpected element { > http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenResponse<http://docs.oasis-open.org/ws-sx/ws-trust/200512%7dRequestSecurityTokenResponse><http://docs.oasis-open.org/ws-sx/ws-trust/200512%7dRequestSecurityTokenResponse> > found. Expected { > http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenR<http://docs.oasis-open.org/ws-sx/ws-trust/200512%7dRequestSecurityTokenR> > <http://docs.oasis-open.org/ws-sx/ws-trust/200512%7dRequestSecurityTok > enR> > esponseCollection > . > at > org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:280) > at > org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:191) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:798) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1669) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1550) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1347) > at > org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56) > at > org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215) > at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at > org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308) > at > org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514) > at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423) > at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324) > at > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277) > at > org.apache.cxf.ws.security.trust.AbstractSTSClient.validate(AbstractSTSClient.java:1124) > at > org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(STSClient.java:105) > at > org.apache.cxf.ws.security.trust.STSClient.validateSecurityToken(STSClient.java:100) > at > gov.faa.iam.sts.IAMSTSTestClient.sendValidateRequest(IAMSTSTestClient.java:242) > at > gov.faa.iam.sts.IAMSTSTestClient.run(IAMSTSTestClient.java:264) > at > gov.faa.iam.sts.IAMSTSTestClient.main(IAMSTSTestClient.java:326) > > I really don't want to change the STS at this point to return a RSTRC > for validations. But it's not clear what to change in the STSClient to > deal with the RSTR - there's already code there for handling it, but > the execution doesn't look like it's getting that far. I'm not even > sure why it says it's expecting an RSTRC. Does anyone have any ideas > on what might be happening here? > > Thanx, > > > Stephen W. Chappell > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
