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
Stefan Vladov (JIRA) schrieb:
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]
