cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smith (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CXF-3701) CXF 2.4.1 only supports base64 encoding for nonce of a wsse UserToken
Date Tue, 02 Aug 2011 14:25:27 GMT
CXF 2.4.1 only supports base64 encoding for nonce of a wsse UserToken
---------------------------------------------------------------------

                 Key: CXF-3701
                 URL: https://issues.apache.org/jira/browse/CXF-3701
             Project: CXF
          Issue Type: Bug
          Components: WS-* Components
    Affects Versions: 2.4.1
         Environment: Windows 7, Java 1.6, maven, spring 3.0
            Reporter: David Smith


Our application uses the wsse Username Token for authentication, PasswordType is Digest.
With CXF 2.3.2 our server could accept and authenticate requests from .NET C# applications
(I believe they use WCF libraries).
After upgrading to CXF 2.4.1 the server started rejecting requests from the .NET C# applications,
complaining that the userName token was invalid (I include stack traces and examples of the
SOAP header below). Should say if a client uses Base64 for the encoding then CXF accepts the
UserName Token correctly.

I believe the problem is that 2.4.1 only supports Base64 for the nonce encoding. This seems
to be a step backwards from 2.3.2 as it can process the same requests.

Is this change intentional (something to do with standards?), or is it an oversight? 
Should this be fixed on the .NET client side, or in CXF 2.4.1.

---- Example of SOAP that fail ----

Payload: <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Header><Security
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:UsernameToken
wsu:Id="SecurityToken-1887b286-5706-4f27-8ac8-d53feb2be78c" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsse:Username>Till_0001</wsse:Username><wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">FTSMoH0PbjVfiWkUY0lB19V2CrQ=</wsse:Password><wsse:Nonce>/yGgGFAuAbsExz2cTxqCTA==</wsse:Nonce><wsu:Created>2011-08-02T11:38:39Z</wsu:Created></wsse:UsernameToken></Security></s:Header><s:Body
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">/*
commented out */</s:Body></s:Envelope>

---- Stack trace (extract) ----

Caused by: org.apache.ws.security.WSSecurityException: An invalid security token was provided
(An error happened processing a Username Token)
	at org.apache.ws.security.message.token.UsernameToken.checkBSPCompliance(UsernameToken.java:1078)
	at org.apache.ws.security.message.token.UsernameToken.<init>(UsernameToken.java:154)
	at org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:113)
	at org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(UsernameTokenProcessor.java:52)
	at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:396)
	at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:249)
	... 57 more





--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message