You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Sanjay Vivek <Sa...@newcastle.ac.uk> on 2008/01/14 13:06:49 UTC
Keeping the Password Callback Handler classes separate.
Hi everyone,
I've a simple EchoService and I would like to keep the Password Callback
Handler classes separate for both the client and service. So what I did
was to edit my client.axis2.xml as shown:
<parameter name="OutflowSecurity">
<action>
<items>UsernameToken Timestamp</items>
<user>wsuser</user>
<passwordCallbackClass>
echo.PWHandlerClient
</passwordCallbackClass>
<!--
<passwordType>PasswordText</passwordType>
-->
</action>
</parameter>
And I edited my services.xml as shown:
<parameter name="InflowSecurity">
<action>
<items>UsernameToken Timestamp</items>
<passwordCallbackClass>
echo.PWHandlerServer
</passwordCallbackClass>
</action>
</parameter>
How does client.axis2.xml know where to look for the PWHandlerClient
class? I put both the PWHandlerClient and PWHandlerServer classes in my
EchoService.aar. However, I'm getting the following exception when I
attempt to invoke the service:
Exception in thread "main" org.apache.axis2.AxisFault: WSHandler: cannot
load password callback class: echo.PWCBHandlerClient;
Where should I put the PWHandlerClient class? Any help would be
appreciated. Cheers.
Regards
--------------
Sanjay Vivek
Web Analyst
Middleware Team
ISS
University of Newcastle Upon Tyne
Re: Keeping the Password Callback Handler classes separate.
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Sanjay,
I still think if you starting from the scratch it is better to use
the policy based
configuration rather than parameter based configuration. We have tested
setting the
username and password using options in the policy based configuration and
will look
in to what happens in the parameter based configuration.
Regards,
Nandana
On Jan 15, 2008 10:56 PM, Sanjay Vivek <Sa...@newcastle.ac.uk> wrote:
> Hi Nandana,
>
> The following 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 "user" value from 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
>
>
Re: Keeping the Password Callback Handler classes separate.
Posted by Ruchith Fernando <ru...@apache.org>.
Sanjay Vivek wrote:
> Hi Nandana,
>
> The following 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 "user" value from 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.
options.setUserName/Password approach is not valid for parameter based
configuration. This can only be used with the policy based approach.
Thanks,
Ruchith
>
> Regards
> Sanjay
>
>
RE: Keeping the Password Callback Handler classes separate.
Posted by Sanjay Vivek <Sa...@newcastle.ac.uk>.
Hi Nandana,
The following 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 "user" value from 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
RE: Keeping the Password Callback Handler classes separate.
Posted by Sanjay Vivek <Sa...@newcastle.ac.uk>.
Hi Nandana,
>Yes, In your scenario,
>1) Do you plan to use secure transport HTTPS ?
I'm planning to use HTTPS as the secure transport. We're not planning on
using keys just yet.
> I think the exception is quite correct if the password
>callback class is not in the client's classpath. You should
>put the client's password callback in the client's claspath.
>But you can even set the username and password using the
>service client's API in the client code.
You gave me a very good example on how to do implement this in an
earlier email. What you suggested was to dynamically set the username
and password using the client's options as shown below:
ServiceClient client = new ServiceClient(ctx, null);
Options options = client.getOptions();
options.setUserName("user");
options.setPassword("password");
Do I have to do anything regarding the "OutflowSecurity" parameter in
client.axis2.xml? Or does 'options.setUserName("user")' automatically
pass on the "user" value to "OutflowSecurity" as shown below? And what
do I specify within the <passwordCallbackClass> element? Do I leave this
empty since there's no callback handler on the client side? Thanks again
for your help.
<module ref="rampart" />
<parameter name="OutflowSecurity">
<action>
<items>UsernameToken Timestamp</items>
<user>user</user>
<passwordCallbackClass>org.apache.rampart.samples.PWCBHandler</passwordC
allbackClass>
</action>
</parameter>
Regards
Sanjay
>-----Original Message-----
>From: Nandana Mihindukulasooriya [mailto:nandana.cse@gmail.com]
>Sent: 15 January 2008 11:42
>To: rampart-dev@ws.apache.org
>Subject: Re: Keeping the Password Callback Handler classes separate.
>
>Hi Sanjay,
>
>So can I implement this model using the Policy based config model for
>> Rampart?
>
>
>Yes, In your scenario,
>1) Do you plan to use secure transport HTTPS ?
>2) Are you plan to use ( at least server's ) key for securing
>the service ?
>
>
>> I can't seem to get it working otherwise as I mentioned
>earlier as the
>> client can't find the PWHandlerClient class. Thanks again.
>
>
>I think you will be able to fix the no class found thing by
>having the password callback in the client's classpath. But I
>think, as Paul has said it is better to move to policy based
>configuration.
>
>Regards,
>Nandana
>
Re: Keeping the Password Callback Handler classes separate.
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Sanjay,
So can I implement this model using the Policy based config model for
> Rampart?
Yes, In your scenario,
1) Do you plan to use secure transport HTTPS ?
2) Are you plan to use ( at least server's ) key for securing the service ?
> I can't seem to get it working otherwise as I mentioned earlier
> as the client can't find the PWHandlerClient class. Thanks again.
I think you will be able to fix the no class found thing by having the
password
callback in the client's classpath. But I think, as Paul has said it is
better to
move to policy based configuration.
Regards,
Nandana
RE: Keeping the Password Callback Handler classes separate.
Posted by Sanjay Vivek <Sa...@newcastle.ac.uk>.
Hi Paul,
So can I implement this model using the Policy based config model for
Rampart? I can't seem to get it working otherwise as I mentioned earlier
as the client can't find the PWHandlerClient class. Thanks again.
Regards
Sanjay
>-----Original Message-----
>From: Paul Fremantle [mailto:pzfreo@gmail.com]
>Sent: 14 January 2008 13:25
>To: rampart-dev@ws.apache.org
>Subject: Re: Keeping the Password Callback Handler classes separate.
>
>Sanjay
>
>Firstly, as of the latest version of Axis2 you no longer need
>to use the callback in the client. You can simply call
>stub._getServiceClient.setUserName()/setPassword()
>
>Secondly, you can merge the two pieces of code into a single
>callback handler but it doesn't make sense. I think you are
>doing pretty much the right thing in having two classes and
>different configs for client and service.
>
>Paul
Re: Keeping the Password Callback Handler classes separate.
Posted by Paul Fremantle <pz...@gmail.com>.
Sanjay
Firstly, as of the latest version of Axis2 you no longer need to use
the callback in the client. You can simply call
stub._getServiceClient.setUserName()/setPassword()
Secondly, you can merge the two pieces of code into a single callback
handler but it doesn't make sense. I think you are doing pretty much
the right thing in having two classes and different configs for client
and service.
Paul
On Jan 14, 2008 1:21 PM, Sanjay Vivek <Sa...@newcastle.ac.uk> wrote:
> Hi again,
>
> I'm a slightly confused with the Callback model and hopefully you can
> clear up my confusion. The scenario below is what I had in mind for
> particular implementation.
>
> If for example I'm the client and I'm sending in a request to the
> service, then the callback needs to find and "fill in" the password:
>
> if (callbacks[i] instanceof WSPasswordCallback) {
> WSPasswordCallback pc = (WSPasswordCallback)
> callbacks[i];
> logInfo(pc);
> // We need the password to fill in, so the usage code
> must
> // match the WSPasswordCallback.USERNAME_TOKEN value
> // i.e. "2"
> if (pc.getUsage() != WSPasswordCallback.USERNAME_TOKEN)
> {
> throw new UnsupportedCallbackException(callbacks[i],
>
> "Usage code was not USERNAME_TOKEN - value was "
>
> + pc.getUsage());
> }
> // Get the username that was sent
> String username = pc.getIdentifer();
> // Now find the password from the user store, and set it
>
> String password = findPassword(username);
> pc.setPassword(password);
> } else {
> throw new UnsupportedCallbackException(callbacks[i],
> "Unrecognized Callback");
> }
>
>
> If on the other hand, I'm the service, then I'm expecting the username
> and password to be sent as an input, which the service then validates:
>
> if (callbacks[i] instanceof WSPasswordCallback) {
> WSPasswordCallback pc = (WSPasswordCallback)
> callbacks[i];
> logInfo(pc);
> // We are doing authentication only, so the usage code
> must
> // match the WSPasswordCallback.USERNAME_TOKEN_UNKNOWN
> value
>
> // i.e. "5"
> if (pc.getUsage() !=
> WSPasswordCallback.USERNAME_TOKEN_UNKNOWN) {
> throw new UnsupportedCallbackException(callbacks[i],
>
> "Usage code was not USERNAME_TOKEN_UNKNOWN -
> value
> was "
> + pc.getUsage());
> }
> // Get the username and password that were sent
> String username = pc.getIdentifer();
> String password = pc.getPassword();
> // Now pass them to your authentication mechanism
> authenticate(username, password); // throws
> WSSecurityException.FAILED_AUTHENTICATION on failure
> } else {
> throw new UnsupportedCallbackException(callbacks[i],
> "Unrecognized Callback");
> }
>
> However, the above scenario can't be implemented without the password
> Callback Handler classes being separate (I think so anyway). I'm
> assuming that the samples given in the Rampart bistro only implements
> the client side of things and doesn't do any password validation on the
> service side. BTW, I've only looked at the samples in /basic/samples and
> please correct me if I'm wrong about the above assumption. Does the
> Policy based config model for Rampart help in this respect? Cheers.
>
> Regards
> Sanjay
>
>
> >-----Original Message-----
> >From: Paul Fremantle [mailto:pzfreo@gmail.com]
> >Sent: 14 January 2008 12:18
> >To: rampart-dev@ws.apache.org
> >Subject: Re: Keeping the Password Callback Handler classes separate.
> >
> >Sanjay
> >
> >I think this approach would work much better with the Policy
> >based config model for Rampart. You should be able to put the
> >PWCallback class in the lib directory if you really want to
> >separate it from the service code.
> >
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: Keeping the Password Callback Handler classes separate.
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Sanjay,
When using Username Tokens, there are two scenarios.
1.) Using the plain text password
2.) Using the hashed password
In both scenarios, in client side, when Username Builder is building the
Username Token it calls the callback with the
WSPasswordCallback.USERNAME_TOKEN
usage and the callback fills the password according to the user id.
In the sever side , in plain text password scenario , Usename Token
Processor
calls the password callback with the passedword and the usage set to
WSPasswordCallback.USERNAME_TOKEN_UNKNOWN and the callback validates
and throws and exception if the authentication fails.
However in the hashed password scenario, Usename Token Processor calls the
callback with the usage set to WSPasswordCallback.USERNAME_TOKEN and the
callback simply fills the password and return it. Then the Usename Token
Processor
does the check to see the hashes match.
So when implementing the service's password callback you need to handle both
scanarios.
assuming that the samples given in the Rampart bistro only implements
> the client side of things and doesn't do any password validation on the
> service side.
Yes, got your point. If the password is plain text then there will be no
validation in the current
implementation of password callback in the samples. Anyway we can do it in
the same class
by changing the behavior according to the usage value. But I also think in
practical scenarios
most of the time we need to have two password callback classes one for
client and one for service.
Regards,
Nandana
RE: Keeping the Password Callback Handler classes separate.
Posted by Sanjay Vivek <Sa...@newcastle.ac.uk>.
Hi again,
I'm a slightly confused with the Callback model and hopefully you can
clear up my confusion. The scenario below is what I had in mind for
particular implementation.
If for example I'm the client and I'm sending in a request to the
service, then the callback needs to find and "fill in" the password:
if (callbacks[i] instanceof WSPasswordCallback) {
WSPasswordCallback pc = (WSPasswordCallback)
callbacks[i];
logInfo(pc);
// We need the password to fill in, so the usage code
must
// match the WSPasswordCallback.USERNAME_TOKEN value
// i.e. "2"
if (pc.getUsage() != WSPasswordCallback.USERNAME_TOKEN)
{
throw new UnsupportedCallbackException(callbacks[i],
"Usage code was not USERNAME_TOKEN - value was "
+ pc.getUsage());
}
// Get the username that was sent
String username = pc.getIdentifer();
// Now find the password from the user store, and set it
String password = findPassword(username);
pc.setPassword(password);
} else {
throw new UnsupportedCallbackException(callbacks[i],
"Unrecognized Callback");
}
If on the other hand, I'm the service, then I'm expecting the username
and password to be sent as an input, which the service then validates:
if (callbacks[i] instanceof WSPasswordCallback) {
WSPasswordCallback pc = (WSPasswordCallback)
callbacks[i];
logInfo(pc);
// We are doing authentication only, so the usage code
must
// match the WSPasswordCallback.USERNAME_TOKEN_UNKNOWN
value
// i.e. "5"
if (pc.getUsage() !=
WSPasswordCallback.USERNAME_TOKEN_UNKNOWN) {
throw new UnsupportedCallbackException(callbacks[i],
"Usage code was not USERNAME_TOKEN_UNKNOWN -
value
was "
+ pc.getUsage());
}
// Get the username and password that were sent
String username = pc.getIdentifer();
String password = pc.getPassword();
// Now pass them to your authentication mechanism
authenticate(username, password); // throws
WSSecurityException.FAILED_AUTHENTICATION on failure
} else {
throw new UnsupportedCallbackException(callbacks[i],
"Unrecognized Callback");
}
However, the above scenario can't be implemented without the password
Callback Handler classes being separate (I think so anyway). I'm
assuming that the samples given in the Rampart bistro only implements
the client side of things and doesn't do any password validation on the
service side. BTW, I've only looked at the samples in /basic/samples and
please correct me if I'm wrong about the above assumption. Does the
Policy based config model for Rampart help in this respect? Cheers.
Regards
Sanjay
>-----Original Message-----
>From: Paul Fremantle [mailto:pzfreo@gmail.com]
>Sent: 14 January 2008 12:18
>To: rampart-dev@ws.apache.org
>Subject: Re: Keeping the Password Callback Handler classes separate.
>
>Sanjay
>
>I think this approach would work much better with the Policy
>based config model for Rampart. You should be able to put the
>PWCallback class in the lib directory if you really want to
>separate it from the service code.
>
Re: Keeping the Password Callback Handler classes separate.
Posted by Paul Fremantle <pz...@gmail.com>.
Sanjay
I think this approach would work much better with the Policy based
config model for Rampart. You should be able to put the PWCallback
class in the lib directory if you really want to separate it from the
service code.
Paul
On Jan 14, 2008 12:06 PM, Sanjay Vivek <Sa...@newcastle.ac.uk> wrote:
>
> Hi everyone,
>
> I've a simple EchoService and I would like to keep the Password Callback
> Handler classes separate for both the client and service. So what I did
> was to edit my client.axis2.xml as shown:
>
> <parameter name="OutflowSecurity">
> <action>
> <items>UsernameToken Timestamp</items>
>
> <user>wsuser</user>
>
> <passwordCallbackClass>
> echo.PWHandlerClient
> </passwordCallbackClass>
>
> <!--
> <passwordType>PasswordText</passwordType>
> -->
> </action>
> </parameter>
>
> And I edited my services.xml as shown:
>
> <parameter name="InflowSecurity">
> <action>
> <items>UsernameToken Timestamp</items>
>
> <passwordCallbackClass>
> echo.PWHandlerServer
> </passwordCallbackClass>
> </action>
> </parameter>
>
> How does client.axis2.xml know where to look for the PWHandlerClient
> class? I put both the PWHandlerClient and PWHandlerServer classes in my
> EchoService.aar. However, I'm getting the following exception when I
> attempt to invoke the service:
>
> Exception in thread "main" org.apache.axis2.AxisFault: WSHandler: cannot
> load password callback class: echo.PWCBHandlerClient;
>
> Where should I put the PWHandlerClient class? Any help would be
> appreciated. Cheers.
>
>
> Regards
> --------------
> Sanjay Vivek
> Web Analyst
> Middleware Team
> ISS
> University of Newcastle Upon Tyne
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: Keeping the Password Callback Handler classes separate.
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Sanjay,
How does client.axis2.xml know where to look for the PWHandlerClient
> class? I put both the PWHandlerClient and PWHandlerServer classes in my
> EchoService.aar.
Client's password callback class need to be in client's classpath. So
putting
both in the EchoService.aar doesn't seems the proper solution. Service's
callback
can be in EchoService.aar or if you want it to be separate it from the
service you
can put it in the lib directory.
> However, I'm getting the following exception when I
> attempt to invoke the service:
>
> Exception in thread "main" org.apache.axis2.AxisFault: WSHandler: cannot
> load password callback class: echo.PWCBHandlerClient;
> Where should I put the PWHandlerClient class?
I think the exception is quite correct if the password callback class is
not in the
client's classpath. You should put the client's password callback in the
client's
claspath. But you can even set the username and password using the service
client's API in the client code.
Regards,
Nandana