Hir, loking at your examples I found that you mix some "standard" levels of the WS specification (yes, there were some draft standards, the first implementation of WSS4J implemented a draft, later we changed to the agreed standard - this is why we intoduced the "backward" compatibility mode, the various string are defined in WSConstants, by default we use the OASIS_1_= setup).
The ping2.py is the example that uses the right URI for the password type, however the napespace definition for wsu is not correct. It should read as: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd if you use the agreed OASIS 1.0 specification (if you refer to the original OASIS docs pls also look at the errata when looking up the correct namespace defintions). Because of the wrong wsu namespace WSS4J cannot find an element that is required for PasswordDigest (wsu:Created). Regards, Werner > -----Urspr�ngliche Nachricht----- > Von: Mir Shafiqul Islam [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. April 2005 21:46 > An: [email protected] > Betreff: Possible security bug in handling digest password > > > I am new to wss4j and ws-security in general. So I maybe missing > something obvious. > > I have axis 1.2 RC3 along with latest wss4j code from cvs. I have a > simple service setup with my own password call back handler and > everything works as expected from java environment. However, while > testing interoperability with some simple python scripts I ran into a > behavior that I can at best call a security hole. > > Here is the scenario. If the password Type is specified as > "wsse:PasswordDigest" (compliant to older specification) the > WSDoAllReceiver class never detects the password as legitimate digest > password. The type is compared against fixed constant value > specified in > WSConstants.PASSWORD_DIGEST > (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-usern ame-token-profile-1.0#PasswordDigest). Since the password type supplied is non compliant (or unknown) to the Type specification should not wss4j throw some sort of exception? The user is allowed to invoke the web service method as if he was fully authenticated. This can be easily reproduced with the attached python scripts. Just create a simple echo/ping service with axis and wss4j ping1.py : Does not authenticate using password call back class and lets user invoke method ping2.py : Does the right thing and invokes appropriate password call back class server.config.xml : My service deployer file ping1.output.txt: Packet captured via ethereal. Never authenticated the user but invoked the ws method successfully ping2.output.txt: Packet captured via ethereal. Failed to authenticate the user so displayed proper error message Thanks! Mir
