You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Glen Mazza (JIRA)" <ji...@apache.org> on 2010/07/22 06:05:49 UTC

[jira] Commented: (CXF-2894) use wsse:KeyIdentifier instead of wsse:Reference for SAML token profile

    [ https://issues.apache.org/jira/browse/CXF-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890996#action_12890996 ] 

Glen Mazza commented on CXF-2894:
---------------------------------

I can make this problem more specific -- for a Metro web service provider signature validation, the wsse:SecurityTokenReference child of the ds:Signature element in the SOAP header needs to use KeyIdentifier instead of Reference.  wsse:Reference is fine as-is as a child of SecurityTokenReference in other places.

Also, to clarify, this problem does not occur when the CXF client makes a call to the Metro STS -- that works all well--it's just the subsequent call to the Metro web service provider using that token that is the problem.  (Although the token itself is OK, it's just the sibling ds:Signature element with the above problem that's causing the error.)

I'm attaching the failed SOAP request to the Metro web service provider as well as (part of) the SOAP response listing the error.

> use wsse:KeyIdentifier instead of wsse:Reference for SAML token profile
> -----------------------------------------------------------------------
>
>                 Key: CXF-2894
>                 URL: https://issues.apache.org/jira/browse/CXF-2894
>             Project: CXF
>          Issue Type: Bug
>          Components: WS-* Components
>            Reporter: Glen Mazza
>         Attachments: 20100714DoubleItMetroWSTrust.zip
>
>
> CXF should be using the KeyIdentifier element when identifying SAML Assertions within wsse:SecurityTokenReference elements.
> Issue and explanation in this thread:
> http://cxf.547215.n5.nabble.com/Problem-using-SAML-token-profile-to-access-a-Metro-web-service-td1064848.html#a1064848
> Attached zip contains a Metro web service and STS (intended for standalone Tomcat deployment), a working Metro client, and a complaining CXF one, all components Mavenized for easily compilation, deployment, and execution.
> Instructions to host sample web service and STS from attachment:
> 1.) If necessary, to allow mvn tomcat:deploy to work in next step, set up Maven tomcat config:
> Pale green "Maven only" section of Step #8 here has instructions:
> http://www.jroller.com/gmazza/entry/web_service_tutorial#WFstep8
> 2.) From root directory, type mvn clean install tomcat:deploy
> (can call tomcat:undeploy on subsequent runs)
> Once done, confirm can see Metro web service WSDL from browser:
> https://localhost:8443/doubleit/services/doubleit?wsdl
> And confirm can see Metro STS WSDL:
> http://localhost:8080/DoubleItSTS/DoubleItSTSService?wsdl
> 3.) 
> Place the 2.2 version of jaxws-api.jar (https://jax-ws.dev.java.net/) in the JDK_HOME/jre/lib/endorsed folder. 
> Once done, navigate to Metro client folder (/client-metro) and run mvn exec:exec
> Confirm can see output of doubled number results (10 doubled is 20).
> Wireshark results of the whole STS process w/Metro is here:
> http://www.jroller.com/gmazza/entry/metro_wstrust_analysis
> 5.) 
> Remove 2.2 JAXWS-api.jar from endorsed folder.
> Navigate to CXF client folder (/client-cxf) and run 
> mvn clean install exec:exec (need to build here, as client-cxf is not part of parent POM due to Metro dependencies.)
> Should see this error message:
> [INFO] Jul 14, 2010 8:00:46 AM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromWSDL
> [INFO] INFO: Creating Service {http://www.example.org/contract/DoubleIt}DoubleItService from WSDL: file:/work/workspace/DoubleItMetroWSTrust/client-cxf/src/main/resources/DoubleItService.wsdl
> [INFO] Jul 14, 2010 8:00:48 AM org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage
> [INFO] WARNING: Request does not contain required Security header, but it's a fault.
> ----->[INFO] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: unsupported directreference ValueType http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID<-----
> [INFO] 	at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
> [INFO] 	at $Proxy38.doubleIt(Unknown Source)
> [INFO] 	at client.WSClient.doubleIt(WSClient.java:18)
> [INFO] 	at client.WSClient.main(WSClient.java:11)
> [INFO] Caused by: org.apache.cxf.binding.soap.SoapFault: unsupported directreference ValueType http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID
> [INFO] 	at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)
> [INFO] 	at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)
> [INFO] 	at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)
> [INFO] 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> If you can use Wireshark to trace localhost calls (always can on Linux, sometimes on Windows), can use Wireshark's Show TCP stream capability to get more of error message: http://www.jroller.com/gmazza/entry/soap_calls_over_wireshark

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.