I also have similar use case scenarios - besides the username token+basic auth, I have Username token + saml token (either can be supplied). Last time I checked Neethi did not support alternative policies. I am not sure if that has been improved. I am also intrested in an answer.
-----Original Message----- From: Sanjay Vivek [mailto:[EMAIL PROTECTED] Sent: Monday, April 21, 2008 9:27 AM To: [email protected] Subject: RE: Editing the services.xml to allow both Basic Auth and Rampart auth. Do you mean getting rid of the password in Scenario 2? I'm not entirely sure about this but I believe Token Assertions in the form of UsernameTokens expects a username/password pair. I could be wrong about this though. The reason I would like Scenario 2 in place, i.e. no security mechanism, is because I could then use Basic Auth for scenario 2 by specifiying 2 filters in the web.xml, one for Rampart Auth (in scenario 1) and another for Basic Auth (in Scenario 2). Cheers. Regards Sanjay >-----Original Message----- >From: Srivastava, Abhay [mailto:[EMAIL PROTECTED] >Sent: 21 April 2008 16:03 >To: [email protected] >Subject: RE: Editing the services.xml to allow both Basic Auth and >Rampart auth. > >Is it possible to get rid off of password while passing the >usernametoken? > > >Abhay Srivastava >Reference Architecture >Shared Services and Architecture | Smith Barney Technology | CitiGroup >GWM >(212) 657 - 4617 > >-----Original Message----- >From: Sanjay Vivek [mailto:[EMAIL PROTECTED] >Sent: Monday, April 21, 2008 10:46 AM >To: [email protected] >Subject: RE: Editing the services.xml to allow both Basic Auth and >Rampart auth. > >I would like to further expand on this scenario. Is it possible to >construct a security policy that has 2 alternatives, that is a Web >client can satisfy all requirements in either scenario 1 or scenario 2. > >For example, in scenario 1, the Web Service client has to use >UsernameToken, while in Scenario 2, there is no security mechanism in >place. I know this is possible with WS-Security Policy but I'm not sure >if scenario 2 is possible, i.e. no security mechanism at all. > >Regards >Sanjay > >>-----Original Message----- >>From: Sanjay Vivek [mailto:[EMAIL PROTECTED] >>Sent: 21 April 2008 14:04 >>To: [email protected] >>Subject: Editing the services.xml to allow both Basic Auth >and Rampart >>auth. >> >>Hi everyone, >> >>Is it possible to deploy a service that is either Basic Auth >or Rampart > >>auth enabled by defining it in the services.xml? >>For example, if we wish to a deploy a Basic Auth enabled service, we >>edit the server.xml (for >>Tomcat) accordlingly and we do the same for Rampart authentication. >> >>However, to enable this, the services.xml file has to be >edited so that > >>it allows clients to send SOAP messages that contain both WS-SEC and >>non-WS-SEC headers (in the form of Basic auth) to consume the service. >>So basically the service shouldn't throw up exceptions when >the client >>is not Rampart enabled. >> >>Any insight would be appreciated. Cheers. >> >>Regards >>-------------- >>Sanjay Vivek >>Web Analyst >>Middleware Team >>ISS >>University of Newcastle Upon Tyne >> > ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **********************************************************************
