[
https://issues.apache.org/jira/browse/WSS-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609360#action_12609360
]
Rick Duckworth commented on WSS-130:
------------------------------------
Thanks for everyone's input. I am currently installing WSS4J 1.5.4 into my
application to observe its behavior. I will give an update later.
In regards to George's comment I would tend to disagree. IMO since I have
specified in the configuration file that I would like WSDoAllReceiver to use
action UsernameToken I would expect the framework to at least ensure that the
UsernameToken element is present in the SOAP Security header and that it is
valid. I don't see any of this going on in WSS4J 1.5.2.
I will have to explore Fred's suggestion. However my first thought is how can
WSS4J check the results if it isn't even doing the authentication when the
UsernameToken is missing or invalid in the SOAP Security header?
Again, I am now installing WSS4J 1.5.4 and will test all of your suggestions
before commenting further. Thanks for your input!
> WSSecutityEngine does not validate UsernameToken in Soap header
> ---------------------------------------------------------------
>
> Key: WSS-130
> URL: https://issues.apache.org/jira/browse/WSS-130
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Handlers
> Affects Versions: 1.5.2
> Environment: Any
> Reporter: Rick Duckworth
> Assignee: Ruchith Udayanga Fernando
>
> WSS4J does not validate the UsernameToken in the SOAP header of a request.
> Consider the following SOAP message...
> <?xml version="1.0" encoding="UTF-8"?>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> <soapenv:Header>
> <wsse:Security
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soapenv:mustUnderstand="1">
> <wsu:UsernameToken
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="UsernameToken-802441115">
> <wsse:Username>user</wsse:Username>
> <wsse:Password
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";>test</wsse:Password>
> </wsu:UsernameToken>
> </wsse:Security>
> </soapenv:Header>
> <soapenv:Body>
> <getAlertTemplates xmlns="http://service.com";></getAlertTemplates>
> </soapenv:Body>
> </soapenv:Envelope>
> Notice the incorrect namespace on the UsernameToken. It should be
> wsse:UsernameToken rather than wsu:UsernameToken. WSS4J will gladly hand
> this request to the web service without processing the UsernameToken and thus
> delegating to the CallbackHandler and performing authentication. In addition
> if the UsernameToken is completely missing the same behavior is observed.
> The problem occurs in WSSecurityEngine.processSecurityHeader(). It gets a
> reference to the security header node and iterates through each of its
> children. If the child is an element then it attempts to retrieve a
> processor for it via WSSConfig.getProcessor(). The problem here is that if
> the UsernameToken does not follow the OASIS standard then a processor will
> not be returned and consequently the CallbackHandler that is configured to
> handle authentication is never called. Similarly it is not called if the
> UsernameToken is completely missing. It seems that there should be some
> mechanism to validate the UsernameToken before processing is attempted. If
> validation fails then the request must fail in a similar fashion as if the
> entire Security header is missing.
--
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]
