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, <[email protected]> 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: [email protected]
> Cc: [email protected]
> 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:[email protected]]
> Sent: Wednesday, March 23, 2016 7:40 AM
> To: Chappell, Stephen CTR (FAA)
> Cc: [email protected]
> 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, <[email protected]<mailto:
> [email protected]>> 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
> >"/>
>     <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>"/>
>     <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:[email protected]<mailto:
> [email protected]>]
> Sent: Wednesday, March 23, 2016 7:27 AM
> To: [email protected]<mailto:[email protected]>
> 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, <[email protected]<mailto:
> [email protected]>> 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
> >
> > found.   Expected {
> > http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenR
> > <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

Reply via email to