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] > >
