[
https://issues.apache.org/jira/browse/WSS-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641407#action_12641407
]
Werner Dittmann commented on WSS-151:
-------------------------------------
Hi Stefan,
the WSS specification does not assign a namespace to this
attribute. Other attributes, for example wsu:Id do have
namespaces assigned to it. Thus this "Type" attribute shall
not have a namespace.
The relevant specification is:
"Web Services Security, UsernameToken Profile 1.1,
OASIS Standard Specification, 1 February 2006 "
The namespace of an element is independent of the namespaces of
its attributes. Attributes do _not_ inherit the element's
namespace, even a default namespace is not applied to an attribute
(refer to chapter 6.3 Uniqueness of Attributes, W3C document
"Namespaces in XML 1.0 (Second Edition)".
Taking all this into consideration the notation of "o:Type=...."
is wrong.
Regards,
Werner
P.S. Only .Net 3.5 seems to have this problem, other implementations
from other vendors are ok AFAIK.
W.
> 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]
