[jira] Commented: (WSS-151) Password type in UsernameToken not deserialized correctly

["Werner Dittmann (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WSS-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641360#action_12641360 ] 

Werner Dittmann commented on WSS-151:
-------------------------------------

There was a similar error report just a few days ago.
The problem is _not_ at WSS4J but on .Net 3.5 . The OASIS
WSS specification clearly define that the "Type" attribute
for password is _not_ qualified with a namespace - it is
a simple local name without any namespace.

Regards,
Werner




> Password type in UsernameToken not deserialized correctly
> ---------------------------------------------------------
>
>                 Key: WSS-151
>                 URL: https://issues.apache.org/jira/browse/WSS-151
>             Project: WSS4J
>          Issue Type: Bug
>          Components: WSS4J Core
>    Affects Versions: 1.5.4
>         Environment: axis21.4.1 / rampart 1.4 / wss4j 1.5.4
>            Reporter: Stefan Vladov
>            Assignee: Ruchith Udayanga Fernando
>             Fix For: 1.5.5
>
>
> This is an interoperability issue that occurred when testing axis2/rampart/wss4j with a username token with a .Net 3.5 client. The .net client insists on serializing the namespace of the type attribute like this:
> <o:UsernameToken xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" u:Id="uuid-28ef8476-5c1c-4585-a43f-a5f9439e5a01-1">
>         <o:Username>me</o:Username>
> 	<o:Password o:Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">me</o:Password>
> </o:UsernameToken>
> Note the namespace prefix on the type attribute ("o:")
> In wss4j UsernameToken constructor from a DOM element implementation the type attribute is retrieved like this:
> passwordType = elementPassword.getAttribute("Type");
> With axis2 we naturally use the axiom DOM implementation. The getAttribute element in the ElementImpl tries to match the attribute name to any of the parsed attributes. In this attempt however the method getNodeName is used (defined in the DOM Node interface). The implementation of this method may vary based on the actual node interface successor. The getNodeName in the AttrImpl class in axiom will essentially return "o:Type" and therefore the attribute is not found. I am not completely sure whether this is the correct behavior of axiom but anyway I think it is a perfectly good xml that is sent by the .net client and it should be parsed correctly. 
> I suggest looping through the attributes in the UsernameToken constructor and searching for an attribute with local name "Type". I could supply a patch if you are interested... it's not very complicated. If you think this is a bug in axiom I will report it to them...

-- 
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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org