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.
Stefan Vladov (JIRA) schrieb:
[ https://issues.apache.org/jira/browse/WSS-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641368#action_12641368 ]
Stefan Vladov commented on WSS-151:
-----------------------------------
Hi Werner,
I'm very sorry for reopening this, I should have seen the previously reported
issue. However I did not find anywhere in the specification information about
the namespace of the type attribute. There are a couple of examples where it is
indeed not prefixed but then it is naturally in the namespace of the element in
which it is declared. Thus I think it is also correct to have the respective
prefix before the attribute - no difference in the attribute namespace.
Therefore I still think this is a bug.
Regards,
Stefan
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...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
