cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Müller (JIRA) <>
Subject [jira] [Commented] (CXF-3701) CXF 2.4.1 only supports base64 encoding for nonce of a wsse UserToken
Date Thu, 07 Feb 2013 11:49:12 GMT


Christian Müller commented on CXF-3701:

Hello Colm,

we hit the same problem after upgrading from 

Can you please explain which relation the WS-I basic profile you mentioned and the OASIS web
service security spec [1] has?
I'm asking because OASIS spec says (startign with line 249):
249 /wsse:UsernameToken/wsse:Nonce
250 This optional element specifies a cryptographically random nonce. Each message
251 including a <wsse:Nonce> element MUST use a new nonce value in order for web
252 service producers to detect replay attacks.

So it says this element is *OPTIONAL*. Any clarification is appreciated.


> CXF 2.4.1 only supports base64 encoding for nonce of a wsse UserToken
> ---------------------------------------------------------------------
>                 Key: CXF-3701
>                 URL:
>             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=""><s:Header><Security
wsu:Id="SecurityToken-1887b286-5706-4f27-8ac8-d53feb2be78c" xmlns:wsse=""
xmlns:xsi="" xmlns:xsd="">/*
commented out */</s:Body></s:Envelope>
> ---- Stack trace (extract) ----
> Caused by: An invalid security token was
provided (An error happened processing a Username Token)
> 	at
> 	at<init>(
> 	at
> 	at
> 	at
> 	at
> 	... 57 more

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message