You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "David Smith (JIRA)" <ji...@apache.org> on 2011/08/02 16:25:27 UTC

[jira] [Created] (CXF-3701) CXF 2.4.1 only supports base64 encoding for nonce of a wsse UserToken

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

        

[jira] [Resolved] (CXF-3701) CXF 2.4.1 only supports base64 encoding for nonce of a wsse UserToken

Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colm O hEigeartaigh resolved CXF-3701.
--------------------------------------

    Resolution: Invalid
      Assignee: Colm O hEigeartaigh

> 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
>            Assignee: Colm O hEigeartaigh
>
> 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

        

[jira] [Commented] (CXF-3701) CXF 2.4.1 only supports base64 encoding for nonce of a wsse UserToken

Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102685#comment-13102685 ] 

Colm O hEigeartaigh commented on CXF-3701:
------------------------------------------


The Nonce of a UsernameToken must contain a Base64 EncodingType as per the Basic Security Profile 1.1 specification:

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html#Nonce/@EncodingType_Attribute_Mandatory

You can disable Basic Security Profile enforcement in CXF by setting the SecurityConstants property "ws-security.is-bsp-compliant" to "false".

Colm.


> 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