Hi Jon, 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.
Yes, this was a limitation of the WS - Security Policy 1.1 specification. It doesn't allow us to specify the password type. But the good news is WS - Security Policy 1.2 allows us to set three password types. 1.) Plain text password 2.) Hash password ( Digest ) 3.) No Password ( just the username ) and Apache Rampart now supports WS - Security Policy 1.2 ( experimental ). You can now specify which type of password you want using SP 1.2 in Rampart. I also ran into a bug (see Jira Rampart-84). And this bug - [1] has been fixed now. > Additionally, the requirement that the uname/password match the jks > certificate alias and password makes configuring the client and test > service > very time consuming. > And this is no longer the case. Now you can have a cert alias different to the username of the Username Token. Please take a look at [2]. > I would prefer to use rampart/policy, Cool. > but have not figured out how to do so. Please post any questions you have to the rampart-dev list. Thanks, Nandana [1] - http://issues.apache.org/jira/browse/RAMPART-84 [2] - http://nandanasm.wordpress.com/2007/10/29/using-usernametokens-with-different-username-to-cert-alias-as-supporting-tokens-in-rampart/ > > > 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] > > -- Nandana Mihindukulasooriya Software Engineer WSO2 inc. http://nandana83.blogspot.com/ http://nandanasm.wordpress.com/
