Hi Nandana, Can you pass me the link for opening a bug in JIRA ?
Abhay Srivastava Reference Architecture Shared Services and Architecture | Smith Barney Technology | CitiGroup GWM | New York (212) 657 - 9358 -----Original Message----- From: Nandana Mihindukulasooriya [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 12:25 AM To: [email protected] Subject: Re: Editing the services.xml to allow both Basic Auth and Rampart auth. Hi Abhay, As per ws-security 1.2 spec. password is not a required field. But, > whenever I not set password in my Axis2 client, I get an error. Is it > because the way Axis2 has implemented the ws-security2 spec. ? > This can be supported in Rampart with WS Security policy 1.2 spec. Can you please raise a JIRA. But I am not sure whether we can get this in to Rampart 1.4 release. thanks, nandana [1] - http://issues.apache.org/jira/browse/Rampart > > 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 11: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 > >> > >
