cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Mazza (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (CXF-2894) use wsse:KeyIdentifier instead of wsse:Reference for SAML token profile
Date Sat, 24 Jul 2010 16:24:50 GMT

     [ 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):

   <S:Body wsu:Id="_5006">
      <xenc:EncryptedData
         xmlns:ns19="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">
         <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
         <ds:KeyInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:type="KeyInfoType">
            <wsse:SecurityTokenReference>
               <wsse:KeyIdentifier
                  ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">uuid-7a6d6259-af70-466f-b6c6-fd89c44bea71
               </wsse:KeyIdentifier>
            </wsse:SecurityTokenReference>
         </ds:KeyInfo>
         <xenc:CipherData>
             <xenc:CipherValue>FMIK0lHrb8mzP....more encrypted data....osjRq9bIsq85gg4CJa</xenc:CipherValue>
         </xenc:CipherData>
      </xenc:EncryptedData>
   </S:Body>

But we are sending this instead (wsse:Reference instead of KeyIdentifier):

   <soap:Body xmlns: 
      wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-20911796">
      <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
         Id="EncDataId-15" Type="http://www.w3.org/2001/04/xmlenc#Content">
         <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
         <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <wsse:SecurityTokenReference
               xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
               <wsse:Reference
                  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                  URI="#uuid-4635d8e6-2d7a-4679-b609-782c2177b740" />
            </wsse:SecurityTokenReference>
         </ds:KeyInfo>
         <xenc:CipherData>
            <xenc:CipherValue>jp3E2kXyR+M....more encrypted data....ZsasdfasoD</xenc:CipherValue>
         </xenc:CipherData>
      </xenc:EncryptedData>
   </soap:Body>

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/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.


Mime
View raw message