[
https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933325#action_12933325
]
Glen Mazza commented on WSS-238:
--------------------------------
Looks good Colm, thanks! I applied the patch to the WSS4J 1.5.x branch and
linked it into CXF 2.3.1-SNAPSHOT, which I then tied to the CXF client. It
seems to work fine (the attachment lists the Client -> STS, STS-> Client,
Client -> WSP and WSP -> Client results via Wireshark). I would go ahead and
apply this patch.
I'm not sure that moving setCustomReferenceValue from WSSecEncrypt to
WSSecEncryptedKey would raise a backward compatibility issue because the latter
is the superclass of the former (going in the other direction, I can more
easily see the backward compatibility concern). So long as the second reason
you gave holds though, your modification sounds like a good idea.
After this patch is applied, we will have one last problem, the one I gave in
the description field for this bug (at the top of this page): WSS4J can't
handle the final SOAP response from the web service provider back to the SOAP
client (the SOAP response is at the bottom of the latest attachment.) The blog
entry I listed above has the downloadable source for the full CXF client, Metro
client, Metro STS and Metro web service (all Maven-based). I can walk you
through running them all using IRC if it would help you replicate this
bug--it's a reasonably fast process if you know what you're doing.
This is the stack trace from the SOAP client at the end as WSS4J tries to
process the SOAP response:
[INFO] Nov 18, 2010 1:00:36 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromWSDL
[INFO] INFO: Creating Service
{http://www.example.org/contract/DoubleIt}DoubleItService from WSDL:
file:/media/NewDriveExt3/workspace/DoubleItMetroWSTrust/client-cxf/src/main/resources/DoubleItService.wsdl
[INFO] Nov 18, 2010 1:00:37 AM
org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl build
[INFO] WARNING: No assertion builder for type
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RequireInternalReference
registered.
[INFO] Nov 18, 2010 1:00:38 AM
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage
[INFO] WARNING:
[INFO] org.apache.ws.security.WSSecurityException: Referenced security token
could not be retrieved (Reference "#uuid-526391a2-929e-49db-b890-54812517062b")
[INFO] at
org.apache.ws.security.message.token.SecurityTokenReference.getKeyIdentifierTokenElement(SecurityTokenReference.java:200)
[INFO] at
org.apache.ws.security.processor.ReferenceListProcessor.getKeyFromSecurityTokenReference(ReferenceListProcessor.java:356)
[INFO] at
org.apache.ws.security.processor.ReferenceListProcessor.decryptDataRefEmbedded(ReferenceListProcessor.java:162)
[INFO] at
org.apache.ws.security.processor.ReferenceListProcessor.handleReferenceList(ReferenceListProcessor.java:113)
[INFO] at
org.apache.ws.security.processor.ReferenceListProcessor.handleToken(ReferenceListProcessor.java:76)
[INFO] at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:328)
[INFO] at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:245)
[INFO] at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:215)
[INFO] at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:81)
[INFO] at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:247)
[INFO] at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:733)
[INFO] at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2304)
[INFO] at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2166)
[INFO] at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:2019)
[INFO] at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
[INFO] at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:712)
[INFO] at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
[INFO] at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:247)
[INFO] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
[INFO] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
[INFO] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
[INFO] at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
[INFO] at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
[INFO] at $Proxy24.doubleIt(Unknown Source)
[INFO] at client.WSClient.doubleIt(WSClient.java:17)
[INFO] at client.WSClient.main(WSClient.java:11)
[INFO] Nov 18, 2010 1:00:38 AM org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
[INFO] WARNING: Interceptor for
{http://www.example.org/contract/DoubleIt}DoubleItService#{http://www.example.org/contract/DoubleIt}DoubleIt
has thrown exception, unwinding now
.... stack trace repeated twice ....
[INFO] Caused by: org.apache.ws.security.WSSecurityException: Referenced
security token could not be retrieved (Reference
"#uuid-526391a2-929e-49db-b890-54812517062b")
[INFO] at
org.apache.ws.security.message.token.SecurityTokenReference.getKeyIdentifierTokenElement(SecurityTokenReference.java:200)
[INFO] at
org.apache.ws.security.processor.ReferenceListProcessor.getKeyFromSecurityTokenReference(ReferenceListProcessor.java:356)
[INFO] at
org.apache.ws.security.processor.ReferenceListProcessor.decryptDataRefEmbedded(ReferenceListProcessor.java:162)
[INFO] at
org.apache.ws.security.processor.ReferenceListProcessor.handleReferenceList(ReferenceListProcessor.java:113)
[INFO] at
org.apache.ws.security.processor.ReferenceListProcessor.handleToken(ReferenceListProcessor.java:76)
[INFO] at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:328)
[INFO] at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:245)
[INFO] at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:215)
[INFO] at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:81)
[INFO] at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:247)
[INFO] at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:733)
[INFO] at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2304)
[INFO] at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2166)
[INFO] at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:2019)
[INFO] at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
[INFO] at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:712)
[INFO] at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
[INFO] at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:247)
[INFO] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
[INFO] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
[INFO] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
[INFO] at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
[INFO] at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
[INFO] ... 3 more
[INFO] ------------------------------------------
This may not be an easy bug to fix--it's beyond my scope of knowledge right now
so I don't think I'll be able to supply a patch suggestion to you like I did
earlier.
> Switch to wsse:KeyIdentifier instead of wsse:Reference for SAML references
> within SOAP:body EncryptedData elements.
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WSS-238
> URL: https://issues.apache.org/jira/browse/WSS-238
> Project: WSS4J
> Issue Type: Improvement
> Components: WSS4J Core
> Affects Versions: 1.5.9
> Reporter: Glen Mazza
> Assignee: Colm O hEigeartaigh
> Fix For: 1.5.10, 1.6
>
> Attachments: EncryptedDataPatch.txt, patch238.txt,
> TestWSSecuritySAMLKeyIdentifier.java, wss-238-revised.patch,
> WSS-238Results.txt
>
>
> Per CXF bug CXF-2894: http://tinyurl.com/23jx6cx
> Within the soap:body/EncryptedData/SecurityTokenReference element, Glassfish
> Metro is requiring wsse:KeyIdentifiers instead of wsse:Reference elements
> when referring to SAML Assertions. Metro appears correct because 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.)
> The attached patch will switch SecurityTokenReference from wsse:Reference to
> wsse:KeyIdentifier when handling SAML Assertions. I've confirmed Metro web
> service providers will now work with this patch. However, backwards
> compatibility issues with systems expecting the current wsse:Reference may
> need to be taken into account.
> WSS4J has another problem with not being able to decrypt SOAP responses that
> use wsse:KeyIdentifier instead of wsse:Reference for SAML Assertions.
> Namely, org.apache.ws.security.processor.ReferenceListProcessor's
> getKeyFromSecurityTokenReference() method will need changing to be able to
> work with SAML Assertions coming from a wsse:KeyIdentifier element instead of
> wsse:Reference. I was not immediately successful in getting this second part
> to work because I could not see how a SAMLTokenProcessor can be initialized
> from a KeyIdentifier instead of the Reference element within this method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
