Hi Nandana, Thanks for the heads up. Will alternative policies be added to Rampart 1.4? I naturally assumed that alternative policies were supported by Rampart after reading [1] which states that it is supported by versions 1.3 and above. Thanks for your help.
Regards Sanjay [1] - http://wso2.org/library/3132 >-----Original Message----- >From: Nandana Mihindukulasooriya [mailto:[EMAIL PROTECTED] >Sent: 23 April 2008 04:58 >To: [email protected] >Subject: Re: Editing the services.xml to allow both Basic Auth >and Rampart auth. > >Hi Sanjay, > >The policy document below describes 2 policy alternatives, one that >> contains a policy assertion requiring the inclusion of a certain >> security token and the other that doesn't contain a policy assertion. >> Does this policy mean that a client that is not Rampart enabled (i.e. >> the SOAP request header doesn't contain WS-Sec headers) will be able >> to consume the service? Or does the service just ignore the >2nd policy >> assertion and only the first policy assertion is used? Cheers. >> >> <wsp:ExactlyOne> >> <wsp:All> >> <sp:SecurityToken> >> <sp:TokenType>sp:X509v3</sp:TokenType> >> </sp:SecurityToken> >> <sp:UsernameToken /> >> </wsp:All> >> <wsp:All> >> </wsp:All> >> </wsp:ExactlyOne> >> </wsp:Policy> >> > >Rampart doesn't support alternative policies at the moment. >We only consider the first alternative when >validating/building messages according to security policies. >you can find the relevant code snippet in the RampartMessageData class. > > if(this.servicePolicy != null){ > // We consider only the first alternative, >Rampart doesn't support alternative policies > List it = >(List)this.servicePolicy.getAlternatives().next(); > > //Process policy and build policy data > this.policyData = RampartPolicyBuilder.build(it); > } > >Possible work around for this is having two end points with >the two desired policies and I agree this may not suit all the >scenarios. > >thanks, >nandana >
