A few months ago I struggled with the uname/password issue using both rampart/basic and rampart/policy. I eventually had to use rampart/basic because my service insisted on a clear text Username Token and a signed SOAP body. Password encryption is done via SSL. The service would not accept a nonce element in the Username token. I could not figure out how to do this with rampart/policy. I also ran into a bug (see Jira Rampart-84). Additionally, the requirement that the uname/password match the jks certificate alias and password makes configuring the client and test service very time consuming.
I would prefer to use rampart/policy, but have not figured out how to do so. Nunny wrote: > > Hi Josef, > > 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. >> > > Yes. Agreed. In fact, that is why Rampart allows not only to set the > username > but the whole in/out flow configuration programmatically as Dimuthu has > described > in her mail. And the Rampart sample 11 [1] also shows how to do this. > > 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? > > > I would say why. When you use the policy based approach what is actually > being used is Rampart handlers and the rampart engine does all the dirty > work. > But if you use parameter based configuration WSS4J handlers are the ones > being used. So as you can see it is not only about configuration and it is > also > about what implementation is really being used. If you look at the > development, > bug fixes, feature additions it is clear why it is always recommended to > use > policy > based configuration. And all the interop tests with .NET / C are also done > using > policy based configuration. Hope I didn't confuse you with the > implementation > details. The bottom line is parameter based configuration ( WSS4J handlers > ) > > is deprecated and most of the new development happens in the policy based > configuration ( Rampart handlers ). So if you are starting to use Rampart, > I > think > is always better to use policy based configuration for all the scenarios > whether > it is simple or complex. > > >> 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 sample one [2] , shows how to use a username token to authenticate > even > though there the policy provides the username. But if simply set the > username and > password using options in the client, it will work fine as you expected. > > I will have the same issue in a few weeks from now and hope to get it done >> the easy way. :-) > > > I hope you didn't mean parameter based configuration when you said > "the easy way". ;) Anyway we will include more samples on how to use the > policy > based configuration which would help people to understand how to use > Rampart > > in various scenarios. If you think there are common scenarios missing in > the > > Rampart samples, please do post suggestions to rampart dev list and we > would > > include those samples in the Rampart distribution. That would be a great > help to > improve the usability of Rampart. > > Thanks, > Nandana > > >> >> -----Ursprüngliche Nachricht----- >> Von: Dimuthu Leelarathne [mailto:[EMAIL PROTECTED] >> Gesendet: Donnerstag, 17. Januar 2008 04:03 >> An: [email protected] >> Betreff: Re: Dynamically setting the username/password with Rampart. >> >> >> Hi, >> >> Since you have used the configuration parameters username/password will >> not be picked up from the options object. Username/password will be >> given priority if you are using policy based configuration only. >> >> This is how you set username/password dynamically if you are using >> configuration parameter approach. >> >> OutflowConfiguration ofc = new OutflowConfiguration(); >> ofc.setActionItems("UsernameToken"); >> options.setProperty(WSSHandlerConstants.OUTFLOW_SECURITY, >> ofc.getProperty()); >> >> myCallback.setUTUsername("bob"); >> myCallback.setUTPassword("bobpass"); >> options.put(WSHandlerConstants.PW_CALLBACK_REF, myCallback); >> >> /* >> myCallback is an instance of a class extending from >> org.apache.ws.security.WSPasswordCallback. >> You should implement it. >> */ >> >> Then remove the password callback class given in the client.axis2.xml >> because there Rampart doesn't give priority to PW_CALLBAK_REF. >> >> Thanks, >> Dimuthu. >> >> >> >> On Wed, 2008-01-16 at 11:36 +0000, Sanjay Vivek wrote: >> > Hi everyone, >> > >> > I'm attempting to call a simple Web Service (an Echo Service) that is >> > protected by WS-Security UsernameToken. I'm using Axis2-1.3 and Rampart >> > 1.3. I've been looking at the samples given in the Apache Rampart >> distro >> > and it makes sense to me. However, in the samples given in the Rampart >> > distro, the username is hardcoded within the OuflowSecurity element in >> > the client config file (client.axis2.xml) as shown below: >> > >> > <parameter name="OutflowSecurity"> >> > <action> >> > <items>UsernameToken Timestamp</items> >> > <user>bob</user> >> > >> > >> <passwordCallbackClass>org.apache.rampart.samples.sample02.PWCBHandler</ >> > passwordCallbackClass> >> > </action> >> > </parameter> >> > >> > >> > However, I want to set username/password dynamically, and I'm >> attempting >> > to use the ServiceClient to do just this. >> > >> > The code snippet below shows how I've gone about using the >> ServiceClient >> > to set the username and password: >> > >> > ConfigurationContext ctx = ConfigurationContextFactory >> > .createConfigurationContextFromFileSystem(axis2ConfPath, null); >> > >> > ServiceClient client = new ServiceClient(ctx, null); >> > OMElement payload = client.sendReceive(getPayload("Hello world")); >> > >> > Options options = new Options(); >> > client.engageModule(new QName("rampart")); >> > >> > options.setTo(targetEPR); >> > options.setAction("urn:echo"); >> > >> > options.setUserName("bob"); >> > options.setPassword("wspwd"); >> > >> > client.setOptions(options); >> > result = client.sendReceive(payload); >> > >> > However, the client seems to be picking up the value within the <user> >> > element in the "OutflowSecurity" element which is defined in >> > client.axis2.xml (from axis2ConfPath/conf). How do I override the >> "user" >> > value in client.axis2.xml so that the client picks up the username from >> > 'options.setUserName("bob")'? Any help would be appreciated. Cheers. >> > >> > Regards >> > -------------- >> > Sanjay Vivek >> > Web Analyst >> > Middleware Team >> > ISS >> > University of Newcastle Upon Tyne >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/Dynamically-setting-the-username-password-with-Rampart.-tp14879210p15166005.html Sent from the Axis - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
