Hi everyone, I would like to add my comments on this topic since I'm the one who initially posed this question :). I initially started off with Rampart because we wanted to incorporate authentication and WS Security to our WS code. Our aim was to use the authentication session to figure out who called our WS and to set access privileges accordingly.
I used the sample code in samples/basic (in the Apache Rampart distro) as a starting point and quickly realised that code in samples/basic had the username/password hardcoded in client.axis2.xml. I didn't know about the parameter or the policy based approach because there was no mention about it on the Apache Rampart homepage. So perhaps it would be helpful if you could include further details on how to configure Rampart and the differences between the parameter and policy approach? BTW, Rampart is working perfectly with our WS. Cheers. Regards Sanjay >-----Original Message----- >From: Dimuthu Leelarathne [mailto:[EMAIL PROTECTED] >Sent: 23 January 2008 04:21 >To: Stadelmann Josef >Cc: [email protected] >Subject: Re: AW: Dynamically setting the username/password >with Rampart. > >Hi, > >Please see my answer below. > >On Tue, 2008-01-22 at 08:04 +0100, Stadelmann Josef wrote: >> Hi Rampart Developers, >> >> I think what .-2 is asking for is somehow "the normal case". >userName >> and password in a xml file is, sorry to me a bit artificial >and the wrong place. >> And I really wonder why Rampart can not pick up UserName and >Password >> from the options if set as shown by >> >> > options.setUserName("bob"); >> > options.setPassword("wspwd"); >> >> and as intended by .-2, What is wrong with his intention? >The solution >> given in the answer .-1 is very much more confusing me, and >it really >> opens ground for many more question toward the team: when to >use which >> option and xml file. >> >> I think what most users seek in any case is a simple possibel first >> approach to do things and if this first approach does not fit >> requirements a more complex approach is only then required. But >> sometimes I get the impression that we get allmost always the served >> with the complex approach first and then after a while and >claiming users a more easy approach is give/developed. >> >> Not only true for Rampart. >> >> For me it is very clear what .-2 wants, but the solution >given by .-1 >> is confusing me. Why do I need to think about a policy based >approach >> if I have such a simple demand as .-2 wants? >> >> At least documentation or the answer could go and say in >which case or >> configuration or architecture or design one has to use >> >> > options.setUserName("bob"); >> > options.setPassword("wspwd"); >> >> and in which case one has to use the proposed approache given by .-1 >> >> If I read ... >> >> > the username is hardcoded within the OuflowSecurity element in the >> > client config file (client.axis2.xml) as shown below: >> >> HARDCODED ... I become a bit crazzy. How often do we need it >like that >> and how often do we need the dynamic approach as .-2 is asking >> for/attempts to have implemented by an easy approach. >> >> Please Rampart developers become clear about when to use >which approach. >> And include a working example for each possible approach you >can think >> of. Rampart has been tested and hence often examples can >just be taken >> from the tests caes, but for that test code has to be provided. >> >> I will have the same issue in a few weeks from now and hope >to get it >> done the easy way. :-) > > >The general practice is NOT to use username/password >hard-coded in the axis2.config.xml file in production. >Username/password hard-coded in the file only for testing and >purposes. > >There are two ways you can configure Rampart. > * Parameter approach > * Policy approach > >We have deprecated the parameter based configuration and >always encourage the policy based configuration. When a person >is using policy based approach everything works smoothly, i.e. >username/password is picked up from the option object without >any extra work. > >I gave this solution [i am referring to the >OutflowConfiguration solution] because he was using the >parameter configuration. > >If you are using policy based approach you won't be having >this issue in a few weeks :) > >Thank you, >Dimuthu. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
