Re: Dynamically setting the username/password with Rampart. - Nandana Mihindukulasooriya - org.apache.ws.axis-user

10 messages in org.apache.ws.axis-userRe: Dynamically setting the username/...

From	Sent On	Attachments
Sanjay Vivek	Jan 16, 2008 3:35 am
Dimuthu Leelarathne	Jan 16, 2008 7:02 pm
Stadelmann Josef	Jan 21, 2008 11:04 pm
Nandana Mihindukulasooriya	Jan 22, 2008 7:19 am
Nandana Mihindukulasooriya	Jan 22, 2008 7:21 am
Dimuthu Leelarathne	Jan 22, 2008 8:20 pm
Sanjay Vivek	Jan 24, 2008 2:22 am
Dimuthu Leelarathne	Jan 24, 2008 6:42 pm
Jon Hanshew	Jan 29, 2008 10:26 am
Nandana Mihindukulasooriya	Jan 29, 2008 6:46 pm

Subject:	Re: Dynamically setting the username/password with Rampart.
From:	Nandana Mihindukulasooriya (nand...@gmail.com)
Date:	Jan 29, 2008 6:46:45 pm
List:	org.apache.ws.axis-user

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:muth...@apache.org] Gesendet: Donnerstag, 17. Januar 2008 04:03 An: axis...@ws.apache.org 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.

-- Nandana Mihindukulasooriya Software Engineer WSO2 inc.

http://nandana83.blogspot.com/ http://nandanasm.wordpress.com/

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets