You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Sanjay Vivek <Sa...@newcastle.ac.uk> on 2008/01/16 12:36:00 UTC
Dynamically setting the username/password with Rampart.
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Dynamically setting the username/password with Rampart.
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
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 <na...@gmail.com>
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:muthulee@apache.org]
> > Gesendet: Donnerstag, 17. Januar 2008 04:03
> > An: axis-user@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.
> > >
> > > Regards
> > > --------------
> > > Sanjay Vivek
> > > Web Analyst
> > > Middleware Team
> > > ISS
> > > University of Newcastle Upon Tyne
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
Re: Dynamically setting the username/password with Rampart.
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
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:muthulee@apache.org]
> >> Gesendet: Donnerstag, 17. Januar 2008 04:03
> >> An: axis-user@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.
> >> >
> >> > Regards
> >> > --------------
> >> > Sanjay Vivek
> >> > Web Analyst
> >> > Middleware Team
> >> > ISS
> >> > University of Newcastle Upon Tyne
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-user-help@ws.apache.org
> >>
> >>
> >
> >
>
> --
> 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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Nandana Mihindukulasooriya
Software Engineer
WSO2 inc.
http://nandana83.blogspot.com/
http://nandanasm.wordpress.com/
Re: Dynamically setting the username/password with Rampart.
Posted by Jon Hanshew <jh...@visa.com>.
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:muthulee@apache.org]
>> Gesendet: Donnerstag, 17. Januar 2008 04:03
>> An: axis-user@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.
>> >
>> > Regards
>> > --------------
>> > Sanjay Vivek
>> > Web Analyst
>> > Middleware Team
>> > ISS
>> > University of Newcastle Upon Tyne
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: axis-user-help@ws.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>
>
--
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Dynamically setting the username/password with Rampart.
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
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:muthulee@apache.org]
> Gesendet: Donnerstag, 17. Januar 2008 04:03
> An: axis-user@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.
> >
> > Regards
> > --------------
> > Sanjay Vivek
> > Web Analyst
> > Middleware Team
> > ISS
> > University of Newcastle Upon Tyne
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
RE: AW: Dynamically setting the username/password with Rampart.
Posted by Dimuthu Leelarathne <mu...@apache.org>.
Hi Sanjay,
The folder samples/basic contains parameter based configuration samples
and the folder samples/policy contains policy based configuration.
Yes we MUST add more documentation on Policy/Parameter based
configuration and a sample on how to set username/password dynamically.
Thank you,
Dimuthu
On Thu, 2008-01-24 at 10:22 +0000, Sanjay Vivek wrote:
> Hi everyone,
>
> I would like to add my comments on this topic since I'm the one who
> initially posed this question :). I initially started off with Rampart
> because we wanted to incorporate authentication and WS Security to our
> WS code. Our aim was to use the authentication session to figure out who
> called our WS and to set access privileges accordingly.
>
> I used the sample code in samples/basic (in the Apache Rampart distro)
> as a starting point and quickly realised that code in samples/basic had
> the username/password hardcoded in client.axis2.xml. I didn't know about
> the parameter or the policy based approach because there was no mention
> about it on the Apache Rampart homepage. So perhaps it would be helpful
> if you could include further details on how to configure Rampart and the
> differences between the parameter and policy approach?
>
> BTW, Rampart is working perfectly with our WS. Cheers.
>
> Regards
> Sanjay
>
> >-----Original Message-----
> >From: Dimuthu Leelarathne [mailto:muthulee@apache.org]
> >Sent: 23 January 2008 04:21
> >To: Stadelmann Josef
> >Cc: axis-user@ws.apache.org
> >Subject: Re: AW: Dynamically setting the username/password
> >with Rampart.
> >
> >Hi,
> >
> >Please see my answer below.
> >
> >On Tue, 2008-01-22 at 08:04 +0100, Stadelmann Josef wrote:
> >> Hi Rampart Developers,
> >>
> >> 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.
> >> And I really wonder why Rampart can not pick up UserName and
> >Password
> >> from the options if set as shown by
> >>
> >> > options.setUserName("bob");
> >> > options.setPassword("wspwd");
> >>
> >> and as intended by .-2, What is wrong with his intention?
> >The solution
> >> given in the answer .-1 is very much more confusing me, and
> >it really
> >> opens ground for many more question toward the team: when to
> >use which
> >> option and xml file.
> >>
> >> I think what most users seek in any case is a simple possibel first
> >> approach to do things and if this first approach does not fit
> >> requirements a more complex approach is only then required. But
> >> sometimes I get the impression that we get allmost always the served
> >> with the complex approach first and then after a while and
> >claiming users a more easy approach is give/developed.
> >>
> >> Not only true for Rampart.
> >>
> >> 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?
> >>
> >> At least documentation or the answer could go and say in
> >which case or
> >> configuration or architecture or design one has to use
> >>
> >> > options.setUserName("bob");
> >> > options.setPassword("wspwd");
> >>
> >> and in which case one has to use the proposed approache given by .-1
> >>
> >> If I read ...
> >>
> >> > the username is hardcoded within the OuflowSecurity element in the
> >> > client config file (client.axis2.xml) as shown below:
> >>
> >> HARDCODED ... I become a bit crazzy. How often do we need it
> >like that
> >> and how often do we need the dynamic approach as .-2 is asking
> >> for/attempts to have implemented by an easy approach.
> >>
> >> 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 has been tested and hence often examples can
> >just be taken
> >> from the tests caes, but for that test code has to be provided.
> >>
> >> I will have the same issue in a few weeks from now and hope
> >to get it
> >> done the easy way. :-)
> >
> >
> >The general practice is NOT to use username/password
> >hard-coded in the axis2.config.xml file in production.
> >Username/password hard-coded in the file only for testing and
> >purposes.
> >
> >There are two ways you can configure Rampart.
> > * Parameter approach
> > * Policy approach
> >
> >We have deprecated the parameter based configuration and
> >always encourage the policy based configuration. When a person
> >is using policy based approach everything works smoothly, i.e.
> >username/password is picked up from the option object without
> >any extra work.
> >
> >I gave this solution [i am referring to the
> >OutflowConfiguration solution] because he was using the
> >parameter configuration.
> >
> >If you are using policy based approach you won't be having
> >this issue in a few weeks :)
> >
> >Thank you,
> >Dimuthu.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
RE: AW: Dynamically setting the username/password with Rampart.
Posted by Sanjay Vivek <Sa...@newcastle.ac.uk>.
Hi everyone,
I would like to add my comments on this topic since I'm the one who
initially posed this question :). I initially started off with Rampart
because we wanted to incorporate authentication and WS Security to our
WS code. Our aim was to use the authentication session to figure out who
called our WS and to set access privileges accordingly.
I used the sample code in samples/basic (in the Apache Rampart distro)
as a starting point and quickly realised that code in samples/basic had
the username/password hardcoded in client.axis2.xml. I didn't know about
the parameter or the policy based approach because there was no mention
about it on the Apache Rampart homepage. So perhaps it would be helpful
if you could include further details on how to configure Rampart and the
differences between the parameter and policy approach?
BTW, Rampart is working perfectly with our WS. Cheers.
Regards
Sanjay
>-----Original Message-----
>From: Dimuthu Leelarathne [mailto:muthulee@apache.org]
>Sent: 23 January 2008 04:21
>To: Stadelmann Josef
>Cc: axis-user@ws.apache.org
>Subject: Re: AW: Dynamically setting the username/password
>with Rampart.
>
>Hi,
>
>Please see my answer below.
>
>On Tue, 2008-01-22 at 08:04 +0100, Stadelmann Josef wrote:
>> Hi Rampart Developers,
>>
>> 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.
>> And I really wonder why Rampart can not pick up UserName and
>Password
>> from the options if set as shown by
>>
>> > options.setUserName("bob");
>> > options.setPassword("wspwd");
>>
>> and as intended by .-2, What is wrong with his intention?
>The solution
>> given in the answer .-1 is very much more confusing me, and
>it really
>> opens ground for many more question toward the team: when to
>use which
>> option and xml file.
>>
>> I think what most users seek in any case is a simple possibel first
>> approach to do things and if this first approach does not fit
>> requirements a more complex approach is only then required. But
>> sometimes I get the impression that we get allmost always the served
>> with the complex approach first and then after a while and
>claiming users a more easy approach is give/developed.
>>
>> Not only true for Rampart.
>>
>> 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?
>>
>> At least documentation or the answer could go and say in
>which case or
>> configuration or architecture or design one has to use
>>
>> > options.setUserName("bob");
>> > options.setPassword("wspwd");
>>
>> and in which case one has to use the proposed approache given by .-1
>>
>> If I read ...
>>
>> > the username is hardcoded within the OuflowSecurity element in the
>> > client config file (client.axis2.xml) as shown below:
>>
>> HARDCODED ... I become a bit crazzy. How often do we need it
>like that
>> and how often do we need the dynamic approach as .-2 is asking
>> for/attempts to have implemented by an easy approach.
>>
>> 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 has been tested and hence often examples can
>just be taken
>> from the tests caes, but for that test code has to be provided.
>>
>> I will have the same issue in a few weeks from now and hope
>to get it
>> done the easy way. :-)
>
>
>The general practice is NOT to use username/password
>hard-coded in the axis2.config.xml file in production.
>Username/password hard-coded in the file only for testing and
>purposes.
>
>There are two ways you can configure Rampart.
> * Parameter approach
> * Policy approach
>
>We have deprecated the parameter based configuration and
>always encourage the policy based configuration. When a person
>is using policy based approach everything works smoothly, i.e.
>username/password is picked up from the option object without
>any extra work.
>
>I gave this solution [i am referring to the
>OutflowConfiguration solution] because he was using the
>parameter configuration.
>
>If you are using policy based approach you won't be having
>this issue in a few weeks :)
>
>Thank you,
>Dimuthu.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: AW: Dynamically setting the username/password with Rampart.
Posted by Dimuthu Leelarathne <mu...@apache.org>.
Hi,
Please see my answer below.
On Tue, 2008-01-22 at 08:04 +0100, Stadelmann Josef wrote:
> Hi Rampart Developers,
>
> 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.
> And I really wonder why Rampart can not pick up UserName and Password from
> the options if set as shown by
>
> > options.setUserName("bob");
> > options.setPassword("wspwd");
>
> and as intended by .-2, What is wrong with his intention? The solution
> given in the answer .-1 is very much more confusing me, and it really opens
> ground for many more question toward the team: when to use which option and
> xml file.
>
> I think what most users seek in any case is a simple possibel first approach to
> do things and if this first approach does not fit requirements a more complex
> approach is only then required. But sometimes I get the impression that
> we get allmost always the served with the complex approach first and then after a
> while and claiming users a more easy approach is give/developed.
>
> Not only true for Rampart.
>
> 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?
>
> At least documentation or the answer could go and say in
> which case or configuration or architecture or design one has to use
>
> > options.setUserName("bob");
> > options.setPassword("wspwd");
>
> and in which case one has to use the proposed approache given by .-1
>
> If I read ...
>
> > the username is hardcoded within the OuflowSecurity element in
> > the client config file (client.axis2.xml) as shown below:
>
> HARDCODED ... I become a bit crazzy. How often do we need it like that and
> how often do we need the dynamic approach as .-2 is asking for/attempts to
> have implemented by an easy approach.
>
> 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 has been tested and hence often examples can just be taken from
> the tests caes, but for that test code has to be provided.
>
> I will have the same issue in a few weeks from now and hope to get it done
> the easy way. :-)
The general practice is NOT to use username/password hard-coded in the
axis2.config.xml file in production. Username/password hard-coded in the
file only for testing and purposes.
There are two ways you can configure Rampart.
* Parameter approach
* Policy approach
We have deprecated the parameter based configuration and always
encourage the policy based configuration. When a person is using policy
based approach everything works smoothly, i.e. username/password is
picked up from the option object without any extra work.
I gave this solution [i am referring to the OutflowConfiguration
solution] because he was using the parameter configuration.
If you are using policy based approach you won't be having this issue in
a few weeks :)
Thank you,
Dimuthu.
> Josef.Stadelmann@
> axa-winterthur.ch
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Dimuthu Leelarathne [mailto:muthulee@apache.org]
> Gesendet: Donnerstag, 17. Januar 2008 04:03
> An: axis-user@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.
> >
> > Regards
> > --------------
> > Sanjay Vivek
> > Web Analyst
> > Middleware Team
> > ISS
> > University of Newcastle Upon Tyne
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
AW: Dynamically setting the username/password with Rampart.
Posted by Stadelmann Josef <jo...@axa-winterthur.ch>.
Hi Rampart Developers,
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.
And I really wonder why Rampart can not pick up UserName and Password from
the options if set as shown by
> options.setUserName("bob");
> options.setPassword("wspwd");
and as intended by .-2, What is wrong with his intention? The solution
given in the answer .-1 is very much more confusing me, and it really opens
ground for many more question toward the team: when to use which option and
xml file.
I think what most users seek in any case is a simple possibel first approach to
do things and if this first approach does not fit requirements a more complex
approach is only then required. But sometimes I get the impression that
we get allmost always the served with the complex approach first and then after a
while and claiming users a more easy approach is give/developed.
Not only true for Rampart.
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?
At least documentation or the answer could go and say in
which case or configuration or architecture or design one has to use
> options.setUserName("bob");
> options.setPassword("wspwd");
and in which case one has to use the proposed approache given by .-1
If I read ...
> the username is hardcoded within the OuflowSecurity element in
> the client config file (client.axis2.xml) as shown below:
HARDCODED ... I become a bit crazzy. How often do we need it like that and
how often do we need the dynamic approach as .-2 is asking for/attempts to
have implemented by an easy approach.
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 has been tested and hence often examples can just be taken from
the tests caes, but for that test code has to be provided.
I will have the same issue in a few weeks from now and hope to get it done
the easy way. :-)
Josef.Stadelmann@
axa-winterthur.ch
-----Ursprüngliche Nachricht-----
Von: Dimuthu Leelarathne [mailto:muthulee@apache.org]
Gesendet: Donnerstag, 17. Januar 2008 04:03
An: axis-user@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.
>
> Regards
> --------------
> Sanjay Vivek
> Web Analyst
> Middleware Team
> ISS
> University of Newcastle Upon Tyne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Dynamically setting the username/password with Rampart.
Posted by Dimuthu Leelarathne <mu...@apache.org>.
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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org