Hi Josef, Sorry, forgot to put the links to the samples.
[1] - https://svn.apache.org/repos/asf/webservices/rampart/trunk/java/modules/rampart-samples/basic/sample11/ [2] - https://svn.apache.org/repos/asf/webservices/rampart/trunk/java/modules/rampart-samples/policy/sample01/ Thanks, nandana On Jan 22, 2008 9:20 PM, Nandana Mihindukulasooriya <[EMAIL PROTECTED]> 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] > > > > >
