Mir,
you are right. There are several problems with UsernameToken,
some of them stem from definitions in the OASIS WS Specs.
Your example ping1.py uses a "unknown" password type declaration.
The current implementation just checks if the password type
is "Digest" according to the OASIS WS Spec in use, that is if the URI
matches the URI string defined in the spec (username token profile).
If WSS4J detects a password type "Digest" according to the WS specs
then WSS4J can perform the security checks as specified.
If the string does not match then WSS4J does not employ any further
checks - its up to the application to some more checks.
Reasons are:
- the password type attribute is optional
- there are 2 predefined password types, only for one of them
security mechanisms are specified ("Digest")
- it is also possible to define other password types (this is not
explicitly ruled out) that may require application specific handling.
If WSS4J (the security engine) detects a password type other than
"Digest" WSS4J populates the WSUsernameTokenPrincipal data structure with
the following data elements: Username, Password, Nonce, Created and returns
this data structure to the applications. It is then up to the application
to perform its security checks.
There was a a discussion here in the mailing list some time ago how to
handle the UsernameToken and the password. Back then it was decided that
WSS4J should handle "Digest" passwords only (because only for this type
of password the mechanisms are specified), handling of other password
types ("Text" and application defined types) shall be left to the
application (application in this case is the Axis service).
Regards,
Werner
> -----Urspr�ngliche Nachricht-----
> Von: Mir Shafiqul Islam [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 21. April 2005 21:10
> An: Dittmann Werner
> Cc: [email protected]
> Betreff: Re: AW: AW: Possible security bug in handling digest password
>
>
> Hi Werner, I tried out the settings you suggested and reinstalled the
> application. Now I have processNonCompliantMessages set to false. The
> ping2.py script (see my previous mail) which previously
> worked does not
> work anymore. Which is the correct behavior since I have
> older namespace
> for wsu. However, the ping1.py script was *still* able to invoke the
> service and PWCallBack class never got called. The behavior for that
> script remained the same as it was before. So, toggling the value of
> processNonCompliantMessages still did not provide the scurity needed
> from non compliant messages.
>
> Thanks
> Mir
>
> Dittmann Werner wrote:
>
> >Mir,
> >
> >sorry, I didn't read your e-mail carefully. WSS4J can be
> >configured to support this behaviour using parameters
> >in WSSConfig.java. Currently the parameter
> >"processNonCompliantMessages" is set to true, meaning that
> >WSS4J processes non-compliant messages (messages that
> >do use a match of the various OASIS WSS namespaces). This
> >was done to support a simple migration from the various draft
> >specifications to the agreed standard.
> >
> >If you set this parameter to false (and recompile the whole
> >stuff - unfortunatly we didn't yet implement a way do do
> >it during runtime) then WSS4J is restrictive in the sense you
> >mentioned.
> >
> >Regards,
> >Werner
> >
> >
> >
> >>-----Urspr�ngliche Nachricht-----
> >>Von: Mir Shafiqul Islam [mailto:[EMAIL PROTECTED]
> >>Gesendet: Mittwoch, 20. April 2005 17:53
> >>An: Dittmann Werner
> >>Cc: [email protected]
> >>Betreff: Re: AW: Possible security bug in handling digest password
> >>
> >>
> >>Hi Werner, you are absolutely right in your assessment of
> mixing the
> >>name spaces and not sticking to one single one. However, an
> attacker
> >>would not mind doing it and mix and match name spaces to access the
> >>service without being authorized. And that is my point, if
> >>the xml sent
> >>does not adhere to a specification or mix and match and
> wss4j can not
> >>properly detect the required element (in this case the digest
> >>password)
> >>wss4j should throw up its hands in the air and not let anyone
> >>in. Right
> >>now it just silently lets the invoker pass through and invoke
> >>the actual
> >>service (ping1.py).
> >>
> >>Thanks
> >>Mir
> >>
> >>Dittmann Werner wrote:
> >>
> >>
> >>
> >>>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-wssec
> >>>
> >>>
> >>urity-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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
>
