[
https://issues.apache.org/jira/browse/CXF-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573412#comment-13573412
]
Christian Müller edited comment on CXF-3701 at 2/7/13 12:05 PM:
----------------------------------------------------------------
Sorry, I was in rush...
We received a soap request with the following UsernameToken header:
{code:xml}
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="SecurityToken-fcb94d7c-43b9-40dc-a82d-2236f7fa27ce">
<wsse:Username>xxxx</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">GSA+Jt9f4Hpl8bhnH8uPn9mw3Jg=</wsse:Password>
<wsse:Nonce>m8XkPjoZX/pt2T6aKbA9nA==</wsse:Nonce>
<wsu:Created>2013-02-07T09:32:58Z</wsu:Created>
</wsse:UsernameToken>
{code:xml}
and since upgrading to CXF 2.4.3, we get the following exception:
{noformat}
2013-02-07 10:33:00,621 | WARN | tp1176322895-242 | WSS4JInInterceptor
| - - breadcrumbId: |
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)[132:org.apache.ws.security.wss4j:1.6.1]
at
org.apache.ws.security.message.token.UsernameToken.<init>(UsernameToken.java:154)[132:org.apache.ws.security.wss4j:1.6.1]
at
org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:113)[132:org.apache.ws.security.wss4j:1.6.1]
at
org.apache.ws.security.processor.UsernameTokenProcessor.handleToken(UsernameTokenProcessor.java:52)[132:org.apache.ws.security.wss4j:1.6.1]
at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:396)[132:org.apache.ws.security.wss4j:1.6.1]
at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:249)[134:org.apache.cxf.bundle:2.4.3.fuse-01-02]
at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:85)[134:org.apache.cxf.bundle:2.4.3.fuse-01-02]
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)[134:org.apache.cxf.bundle:2.4.3.fuse-01-02]
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)[134:org.apache.cxf.bundle:2.4.3.fuse-01-02]
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:319)[134:org.apache.cxf.bundle:2.4.3.fuse-01-02]
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:287)[134:org.apache.cxf.bundle:2.4.3.fuse-01-02]
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72)[134:org.apache.cxf.bundle:2.4.3.fuse-01-02]
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:939)[116:org.eclipse.jetty.server:7.4.5.fuse20111017]
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)[116:org.eclipse.jetty.server:7.4.5.fuse20111017]
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)[116:org.eclipse.jetty.server:7.4.5.fuse20111017]
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247)[116:org.eclipse.jetty.server:7.4.5.fuse20111017]
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)[116:org.eclipse.jetty.server:7.4.5.fuse20111017]
at
org.eclipse.jetty.server.Server.handle(Server.java:346)[116:org.eclipse.jetty.server:7.4.5.fuse20111017]
at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:438)[116:org.eclipse.jetty.server:7.4.5.fuse20111017]
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:905)[116:org.eclipse.jetty.server:7.4.5.fuse20111017]
at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:567)[111:org.eclipse.jetty.http:7.4.5.fuse20111017]
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)[111:org.eclipse.jetty.http:7.4.5.fuse20111017]
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:43)[116:org.eclipse.jetty.server:7.4.5.fuse20111017]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:538)[112:org.eclipse.jetty.io:7.4.5.fuse20111017]
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:43)[112:org.eclipse.jetty.io:7.4.5.fuse20111017]
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)[117:org.eclipse.jetty.util:7.4.5.fuse20111017]
{noformat}
OASIS web service security profile says:
{noformat}
254 /wsse:UsernameToken/wsse:Nonce/@EncodingType
255 This optional attribute URI specifies the encoding type of the nonce (see
the definition of
256 <wsse:BinarySecurityToken> for valid values). If this attribute isn't
specified then
257 the default of Base64 encoding is used.
{noformat}
So, how can we resolve this issue for our customer?
was (Author: muellerc):
Sorry, I was in rush...
{code:xml}
{code:xml}
{noformat}
254 /wsse:UsernameToken/wsse:Nonce/@EncodingType
255 This optional attribute URI specifies the encoding type of the nonce (see
the definition of
256 <wsse:BinarySecurityToken> for valid values). If this attribute isn't
specified then
257 the default of Base64 encoding is used.
{noformat}
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira