[jira] Reopened: (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:all-tabpanel
]
Glen Mazza reopened CXF-2894:
-
Estimated Complexity: Moderate
This problem has popped up in another place with respect to the EncryptedData
element of the SOAP body.
Metro is expecting this (see the wsse:KeyIdentifier element under
SecurityTokenReference):
http://schemas.xmlsoap.org/ws/2006/02/addressingidentity";
xmlns:ns18="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512";
xmlns:ns17="http://www.w3.org/2003/05/soap-envelope"; Id="_5007"
Type="http://www.w3.org/2001/04/xmlenc#Content";>
http://www.w3.org/2001/04/xmlenc#aes256-cbc"; />
http://www.w3.org/2001/XMLSchema-instance";
xsi:type="KeyInfoType">
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID";>uuid-7a6d6259-af70-466f-b6c6-fd89c44bea71
FMIK0lHrb8mzPmore encrypted
dataosjRq9bIsq85gg4CJa
But we are sending this instead (wsse:Reference instead of KeyIdentifier):
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="Id-20911796">
http://www.w3.org/2001/04/xmlenc#";
Id="EncDataId-15" Type="http://www.w3.org/2001/04/xmlenc#Content";>
http://www.w3.org/2001/04/xmlenc#aes256-cbc"; />
http://www.w3.org/2000/09/xmldsig#";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
URI="#uuid-4635d8e6-2d7a-4679-b609-782c2177b740" />
jp3E2kXyR+Mmore encrypted
dataZsasdfasoD
Metro is correct because of the same rationale given earlier, namely that the
SAML Token Profile does not define usage of wsse:Reference for SAML Assertions,
only KeyIdentifier or EmbeddedReference. (Section 3.3 of SAML Token Profile of
1 Dec. 2004 pdf lines 250-272.)
However, unlike my earlier fix on the Signature side it looks like a change to
WSS4J will be needed here.
In particular (untested):
1.) (in CXF) SymmeticBindingHandler.doEncryption() needs new code similar to
what I added for .doSignature():
if (!isRequestor()) {
... same current code...
} else { // new block added
if (encrToken instanceof IssuedToken) {
encr.setUseKeyIdentifier(true);
encr.setCustomReferenceValue(WSConstants.WSS_SAML_NS
+ WSConstants.SAML_ASSERTION_ID);
encr.setKeyIdentifierType(WSConstants.CUSTOM_KEY_IDENTIFIER);
}
}
2.) (in WSS4J) Ability to handle SAML token references for encryption needs to
be added:
WSSecEncryptedKey.prepareInternal() method:
switch (keyIdentifierType) {
...rest of old code...
// add this case
case WSConstants.CUSTOM_KEY_IDENTIFIER:
secRef.setKeyIdentifier(customTokenValueType, customTokenId);
break;
}
This additional case is identical to that already present in WSS4J's
WSSecSignature.prepare() method.
As a sanity check, can anyone see why the above case clause should be in
WSS4J's WSSecSignature but *not* in their WSSecEncryptedKey? Hope not to
embarrass myself to the WSS4J team.
> 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
>Assignee: Glen Mazza
> Attachments: 20100714DoubleItMetroWSTrust.zip, CXF2894Example.txt
>
>
> 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/do
[jira] Updated: (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:all-tabpanel
]
Glen Mazza updated CXF-2894:
Attachment: (was: 20100714DoubleItMetroWSTrust.zip)
> 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
>Assignee: Glen Mazza
> Attachments: CXF2894Example.txt
>
>
> 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.
[jira] Updated: (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:all-tabpanel
]
Glen Mazza updated CXF-2894:
Attachment: 20100724DoubleItMetroWSTrust.zip
Sample project demonstrating problem with EncryptionData element.
> 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
>Assignee: Glen Mazza
> Attachments: 20100724DoubleItMetroWSTrust.zip, CXF2894Example.txt
>
>
> 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.
[jira] Commented: (CXF-2907) Allow DynamicClientFactory to use any JAXB version 2.1 or greater
[ https://issues.apache.org/jira/browse/CXF-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892026#action_12892026 ] Daniel Kulp commented on CXF-2907: -- Resolved it by using our staxutils to parse it wrather than rely on any issues with whatever parser is picked up. > Allow DynamicClientFactory to use any JAXB version 2.1 or greater > - > > Key: CXF-2907 > URL: https://issues.apache.org/jira/browse/CXF-2907 > Project: CXF > Issue Type: Improvement > Components: JAXB Databinding >Affects Versions: 2.2.9 >Reporter: Gary Gregory >Assignee: Daniel Kulp > Fix For: 2.2.10 > > Attachments: CXF-2907.diff, cxf-systests-databinding-pom.diff, > DynamicClientFactoryTest.diff > > > I want to use JAXB 2.2.1 to benefit from a JAXB bug fix but I am having > problems getting CXF to recognize it is there. > All is well when we use JAXB 2.1.13. > I followed the instructions here to use JAXB on top of Java 6: > https://jaxb.dev.java.net/guide/Migrating_JAXB_2_0_applications_to_JavaSE_6.html > I think the problem is the way CXF detects the JAXB version in > DynamicClientFactory#isJaxb21(SchemaCompiler). > The implementation fails to see JAXB 2.2.1 because the build id is not in the > expected format: hudson-jaxb-ri-2.2-7 > Has anyone else run into this issue? I am using a CXF 2.2.10 snapshot build > to work around CXF 2.2.9 bug [CXF-2900]. > My details: > Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_20 > Java home: C:\Program Files\Java\jdk1.6.0_20\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2907) Allow DynamicClientFactory to use any JAXB version 2.1 or greater
[ https://issues.apache.org/jira/browse/CXF-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892050#action_12892050 ] Gary Gregory commented on CXF-2907: --- Thanks Dan. I will pick up the next snapshot build. In the meantime, I have been updating from SVN and building locally as it seems Hudson is really backed up with jobs. I do not even see a CXF build scheduled. > Allow DynamicClientFactory to use any JAXB version 2.1 or greater > - > > Key: CXF-2907 > URL: https://issues.apache.org/jira/browse/CXF-2907 > Project: CXF > Issue Type: Improvement > Components: JAXB Databinding >Affects Versions: 2.2.9 >Reporter: Gary Gregory >Assignee: Daniel Kulp > Fix For: 2.2.10 > > Attachments: CXF-2907.diff, cxf-systests-databinding-pom.diff, > DynamicClientFactoryTest.diff > > > I want to use JAXB 2.2.1 to benefit from a JAXB bug fix but I am having > problems getting CXF to recognize it is there. > All is well when we use JAXB 2.1.13. > I followed the instructions here to use JAXB on top of Java 6: > https://jaxb.dev.java.net/guide/Migrating_JAXB_2_0_applications_to_JavaSE_6.html > I think the problem is the way CXF detects the JAXB version in > DynamicClientFactory#isJaxb21(SchemaCompiler). > The implementation fails to see JAXB 2.2.1 because the build id is not in the > expected format: hudson-jaxb-ri-2.2-7 > Has anyone else run into this issue? I am using a CXF 2.2.10 snapshot build > to work around CXF 2.2.9 bug [CXF-2900]. > My details: > Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_20 > Java home: C:\Program Files\Java\jdk1.6.0_20\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
