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"/>
    <property name="endpointName" 
value="{http://docs.oasis-open.org/ws-sx/ws-trust/200512/}STS_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] 
Sent: Wednesday, March 23, 2016 7:27 AM
To: 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> 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
> found.   Expected {
> http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTokenR
> 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

Reply via email to