[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
