Return-Path: X-Original-To: apmail-axis-java-dev-archive@www.apache.org Delivered-To: apmail-axis-java-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DA9FBD6CC for ; Mon, 4 Mar 2013 06:49:07 +0000 (UTC) Received: (qmail 72304 invoked by uid 500); 4 Mar 2013 06:49:05 -0000 Delivered-To: apmail-axis-java-dev-archive@axis.apache.org Received: (qmail 71969 invoked by uid 500); 4 Mar 2013 06:49:04 -0000 Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@axis.apache.org Delivered-To: mailing list java-dev@axis.apache.org Received: (qmail 71903 invoked by uid 99); 4 Mar 2013 06:49:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Mar 2013 06:49:02 +0000 X-ASF-Spam-Status: No, hits=3.2 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nathan.a.clement@hotmail.com designates 65.54.190.164 as permitted sender) Received: from [65.54.190.164] (HELO bay0-omc3-s26.bay0.hotmail.com) (65.54.190.164) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Mar 2013 06:48:57 +0000 Received: from BAY002-W81 ([65.54.190.189]) by bay0-omc3-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Mar 2013 22:48:37 -0800 X-EIP: [RzYMKwFMEaP7snW6PQCmQGsACTAfxtez] X-Originating-Email: [nathan.a.clement@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_bac26049-2fc9-4b84-b4ef-11aeadfe2f5d_" From: Nathan Clement To: "java-dev@axis.apache.org" Subject: RE: Rampart: sp:HashPassword does not require receiving a hashed password Date: Mon, 4 Mar 2013 17:48:37 +1100 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 04 Mar 2013 06:48:37.0626 (UTC) FILETIME=[4C6D55A0:01CE18A4] X-Virus-Checked: Checked by ClamAV on apache.org --_bac26049-2fc9-4b84-b4ef-11aeadfe2f5d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ruchith=2C Thanks for your quick response. I was halfway through writing my own patch= to 1.6.2 in that exact area of the code :) I have instead applied your ch= angesets to my working copy of the Rampart source. However=2C I'm having a= problem with the following code: } else if (wssUt.getPassword() =3D=3D null || !wssUt.getPasswordType().equals(WSConstants.PASSWORD_TEXT)) { throw new RampartException("invalidUsernameTokenType")=3B When a PasswordDigest is used=2C wssUt.getPassword() returns the hashed pas= sword value=2C and so this exception is thrown=2C even though the request i= s valid according to the policy. Am I missing something here=2C or should = this if statement be something like: } else if (!ut.isHashPassword() && (wssUt.getPassword() =3D=3D null || !wssUt.getPasswordType().equals(WSConstants.PASSWORD_TEXT))) { throw new RampartException("invalidUsernameTokenType")=3B Happy to raise a bug and provide a patch if you concur. Thanks=2C Nathan > Date: Mon=2C 4 Mar 2013 01:03:33 -0500 > Subject: Re: Rampart: sp:HashPassword does not require receiving a hashed= password > From: ruchith.fernando@gmail.com > To: java-dev@axis.apache.org >=20 > Hi Nathan=2C >=20 > IMHO you are correct that the fix should be in > PolicyBasedResultsValidator and I believe this is fixed in the latest > rampart trunk [1]=2C [2]=2C [3]. Please try the latest rampart trunk. > Please do file a bug and provide a patch if these fixes are not > sufficient . >=20 > In the case of previous releases=2C I think the password callback > handler implementation provided at the server side can check the > password type and throw an exception in the case a plain text password > is used. >=20 > Thanks=2C > Ruchith >=20 > 1. http://svn.apache.org/viewvc?view=3Drevision&revision=3D1442444 > 2. http://svn.apache.org/viewvc?view=3Drevision&revision=3D1440696 > 3. http://svn.apache.org/viewvc?view=3Drevision&revision=3D1440633 >=20 > On Mon=2C Mar 4=2C 2013 at 12:08 AM=2C Nathan Clement > wrote: > > Hi=2C > > > > I'm new to Rampart and I've been experimenting with UsernameTokens. My > > policy file contains the assertion. However=2C when > > receiving a wsse:Security header=2C Rampart is allowing a plain text pa= ssword. > > From the WS-SecurityPolicy 1.2 spec: > > > > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypo= licy-1.2-spec-os.html > > > > /sp:UsernameToken/wsp:Policy/sp:HashPassword > > This optional element is a policy assertion that indicates that the > > wsse:Password element MUST be present in the Username token and that th= e > > content of the wsse:Password element MUST contain a hash of the timesta= mp=2C > > nonce and password as defined in [WSS: Username Token Profile]. > > > > From this I understand that my policy should mean that request with > > UsernameTokens containing plaintext passwords are rejected. Does Rampa= rt > > support this policy on the receiving side? > > > > I see that WSS4J's WSSConfig has a "requiredPasswordType" property. I'= m > > happy to attempt to write a patch for Rampart that sets this property b= ased > > on the policy. Is this the right place to implement this functionality= =2C or > > should it be part of PolicyBasedResultsValidator? > > > > The full policy is: > > > > > > > > > xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-ws= security-utility-1.0.xsd" > > xmlns:wsp=3D"http://schemas.xmlsoap.org/ws/2004/09/policy"> > > > > > > > xmlns:sp=3D"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> > > > > > > > > > > > > > > > > > > > > > xmlns:sp=3D"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> > > > > > sp:IncludeToken=3D"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/2= 00702/IncludeToken/AlwaysToRecipient"> > > > > > > > > > > > > > > > > > > > > > > Thanks=2C > > > > Nathan > > >=20 > --------------------------------------------------------------------- > To unsubscribe=2C e-mail: java-dev-unsubscribe@axis.apache.org > For additional commands=2C e-mail: java-dev-help@axis.apache.org >=20 = --_bac26049-2fc9-4b84-b4ef-11aeadfe2f5d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ruchith=2C

Thanks for = your quick response. =3B I was halfway through writing my own patch to = 1.6.2 in that exact area of the code :) =3B I have instead applied your= changesets to my working copy of the Rampart source. =3B However=2C I'= m having a problem with the following code:

 =3B =3B =3B= } else if (wssUt.getPassword() =3D=3D null ||
 =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B !wssUt.getP= asswordType().equals(WSConstants.PASSWORD_TEXT)) {
 =3B =3B = =3B =3B =3B =3B =3B throw new RampartException("invalidUser= nameTokenType")=3B

When a PasswordDigest is used=2C wssUt.getPasswor= d() returns the hashed password value=2C and so this exception is thrown=2C= even though the request is valid according to the policy. =3B Am I mis= sing something here=2C or should this if statement be something like:
 =3B =3B =3B } else if (!ut.isHashPassword() &=3B&=3B (= wssUt.getPassword() =3D=3D null ||
 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B !wssUt.getPasswordType(= ).equals(WSConstants.PASSWORD_TEXT))) {
 =3B =3B =3B =3B=  =3B =3B =3B throw new RampartException("invalidUsernameTokenTy= pe")=3B

Happy to raise a bug and provide a patch if you concur.
<= br>Thanks=2C

Nathan

>=3B Date: Mon=2C 4 Mar 2013 01:03:33 -0500
>=3B Subject: Re: Ramp= art: sp:HashPassword does not require receiving a hashed password
>=3B= From: ruchith.fernando@gmail.com
>=3B To: java-dev@axis.apache.org>=3B
>=3B Hi Nathan=2C
>=3B
>=3B IMHO you are correct t= hat the fix should be in
>=3B PolicyBasedResultsValidator and I believ= e this is fixed in the latest
>=3B rampart trunk [1]=2C [2]=2C [3]. Pl= ease try the latest rampart trunk.
>=3B Please do file a bug and provi= de a patch if these fixes are not
>=3B sufficient .
>=3B
>= =3B In the case of previous releases=2C I think the password callback
&g= t=3B handler implementation provided at the server side can check the
&g= t=3B password type and throw an exception in the case a plain text password=
>=3B is used.
>=3B
>=3B Thanks=2C
>=3B Ruchith
>= =3B
>=3B 1. http://svn.apache.org/viewvc?view=3Drevision&=3Brevisi= on=3D1442444
>=3B 2. http://svn.apache.org/viewvc?view=3Drevision&= =3Brevision=3D1440696
>=3B 3. http://svn.apache.org/viewvc?view=3Drevi= sion&=3Brevision=3D1440633
>=3B
>=3B On Mon=2C Mar 4=2C 2013 = at 12:08 AM=2C Nathan Clement
>=3B <=3Bnathan.a.clement@hotmail.com&= gt=3B wrote:
>=3B >=3B Hi=2C
>=3B >=3B
>=3B >=3B I'm n= ew to Rampart and I've been experimenting with UsernameTokens. My
>= =3B >=3B policy file contains the <=3Bsp:HashPassword/>=3B assertion.= However=2C when
>=3B >=3B receiving a wsse:Security header=2C Ramp= art is allowing a plain text password.
>=3B >=3B From the WS-Securit= yPolicy 1.2 spec:
>=3B >=3B
>=3B >=3B http://docs.oasis-open.= org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html
&g= t=3B >=3B
>=3B >=3B /sp:UsernameToken/wsp:Policy/sp:HashPassword>=3B >=3B This optional element is a policy assertion that indicates = that the
>=3B >=3B wsse:Password element MUST be present in the User= name token and that the
>=3B >=3B content of the wsse:Password eleme= nt MUST contain a hash of the timestamp=2C
>=3B >=3B nonce and passw= ord as defined in [WSS: Username Token Profile].
>=3B >=3B
>=3B= >=3B From this I understand that my policy should mean that request with=
>=3B >=3B UsernameTokens containing plaintext passwords are rejecte= d. Does Rampart
>=3B >=3B support this policy on the receiving side= ?
>=3B >=3B
>=3B >=3B I see that WSS4J's WSSConfig has a "req= uiredPasswordType" property. I'm
>=3B >=3B happy to attempt to writ= e a patch for Rampart that sets this property based
>=3B >=3B on the= policy. Is this the right place to implement this functionality=2C or
= >=3B >=3B should it be part of PolicyBasedResultsValidator?
>=3B &= gt=3B
>=3B >=3B The full policy is:
>=3B >=3B
>=3B >= =3B <=3B?xml version=3D"1.0" encoding=3D"UTF-8"?>=3B
>=3B >=3B &= lt=3Bwsp:Policy wsu:Id=3D"UTOverTransport"
>=3B >=3B
>=3B >= =3B xmlns:wsu=3D"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-ws= security-utility-1.0.xsd"
>=3B >=3B xmlns:wsp=3D"http://= schemas.xmlsoap.org/ws/2004/09/policy">=3B
>=3B >=3B <=3Bwsp:E= xactlyOne>=3B
>=3B >=3B <=3Bwsp:All>=3B
>=3B >=3B = <=3Bsp:TransportBinding
>=3B >=3B xmlns:sp=3D"http://docs.oas= is-open.org/ws-sx/ws-securitypolicy/200702">=3B
>=3B >=3B = <=3Bwsp:Policy>=3B
>=3B >=3B <=3Bsp:AlgorithmSuite&g= t=3B
>=3B >=3B <=3Bwsp:Policy>=3B
>=3B >=3B = <=3Bsp:Basic256Sha256/>=3B
>=3B >=3B &l= t=3B/wsp:Policy>=3B
>=3B >=3B <=3B/sp:AlgorithmSuite&g= t=3B
>=3B >=3B <=3B/wsp:Policy>=3B
>=3B >=3B = <=3B/sp:TransportBinding>=3B
>=3B >=3B
>=3B >=3B = <=3Bsp:SignedSupportingTokens
>=3B >=3B xmlns:sp=3D"http://docs.oa= sis-open.org/ws-sx/ws-securitypolicy/200702">=3B
>=3B >=3B = <=3Bwsp:Policy>=3B
>=3B >=3B <=3Bsp:UsernameToken>=3B >=3B sp:IncludeToken=3D"http://docs.oasis-open.org/ws-sx/ws-secu= ritypolicy/200702/IncludeToken/AlwaysToRecipient">=3B
>=3B >=3B = <=3Bwsp:Policy>=3B
>=3B >=3B <=3Bsp:Ha= shPassword/>=3B
>=3B >=3B <=3B/wsp:Policy>=3B
&= gt=3B >=3B <=3B/sp:UsernameToken>=3B
>=3B >=3B = <=3B/wsp:Policy>=3B
>=3B >=3B <=3B/sp:SignedSupportin= gTokens>=3B
>=3B >=3B <=3B/wsp:All>=3B
>=3B >=3B = <=3B/wsp:ExactlyOne>=3B
>=3B >=3B <=3B/wsp:Policy>=3B
>= =3B >=3B
>=3B >=3B Thanks=2C
>=3B >=3B
>=3B >=3B Nat= han
>=3B >=3B
>=3B
>=3B ---------------------------------= ------------------------------------
>=3B To unsubscribe=2C e-mail: ja= va-dev-unsubscribe@axis.apache.org
>=3B For additional commands=2C e-m= ail: java-dev-help@axis.apache.org
>=3B
= --_bac26049-2fc9-4b84-b4ef-11aeadfe2f5d_--