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 Stefan Lischke <li...@apache.org> on 2008/05/07 17:39:02 UTC
PasswordCallBackHandler in client
Hi,
Can someone please enlighten me why the PasswordCallBackHandler must also be available at the
clientside?
Why can this handler be used to get the password with the hack:
pwcb.setPassword("bobPW");
Isn't there any other possibility to set the password that will be submitted by the client?
In my opinion it is a security matter to deliver the PasswordCallBackHandler class to the customers
that use a client library. They can disassemble the class and see the logic how the password is
checked at serverside.
Another Problem, i have to make the jars available at clientside that are needed at serverside in
the PasswordCallBackHandler.
Did i missed something to understand this?
Please enlighten me
thx in advance
Stefan
Re: PasswordCallBackHandler in client
Posted by Paul Fremantle <pz...@gmail.com>.
You don't need the PWCB in the client. As of Axis2 1.3 you can simply call:
stub._getServiceClient().getOptions().setUsername()/setPassword()
Paul
On Wed, May 7, 2008 at 4:39 PM, Stefan Lischke <li...@apache.org> wrote:
> Hi,
>
> Can someone please enlighten me why the PasswordCallBackHandler must also be available at the
> clientside?
>
> Why can this handler be used to get the password with the hack:
>
> pwcb.setPassword("bobPW");
>
> Isn't there any other possibility to set the password that will be submitted by the client?
>
> In my opinion it is a security matter to deliver the PasswordCallBackHandler class to the customers
> that use a client library. They can disassemble the class and see the logic how the password is
> checked at serverside.
>
> Another Problem, i have to make the jars available at clientside that are needed at serverside in
> the PasswordCallBackHandler.
>
> Did i missed something to understand this?
>
> Please enlighten me
>
> thx in advance
>
> Stefan
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: PasswordCallBackHandler in client
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Stefan,
Next question, is it possible to get the username in the
> ServiceImplementation to check for rights
> to call a method?
Yes, this is how to do it [1]. And we will be listing all these tutorials
and articles about Rampart in Rampart site very soon so people can find
answers to their questions quickly.
> IMaybe adding a parameter to the messageContext in the PWCBHandler and
> reading it in the Service Impl?
I agree. This was discussed sometime back in the list but never implemented
due to time constraints. I agree that it is good to set the authentication
details as a parameter in message context so that service impl can access it
easily. Please feel free to open a JIRA for this. But I am not sure whether
we can get this in to Rampart 1.4 release.
thanks,
nandana
[1] - http://wso2.org/library/169
<https://issues.apache.org/jira/browse/AXIS2-3366>
> Nandana Mihindukulasooriya wrote:
> > Hi Stefan,
> >
> > Can someone please enlighten me why the PasswordCallBackHandler must also
> be
> >> available at the
> >> clientside?
> >
> >
> > Having a password callback at the client is NOT a MUST. You can use
> clients
> > options to provide more information. Please look at this tutorial [1].
> >
> >
> >> Isn't there any other possibility to set the password that will be
> >> submitted by the client?
> >
> >
> > Yes, this can be done with the options approach.
> >
> >
> >> In my opinion it is a security matter to deliver the
> >> PasswordCallBackHandler class to the customers
> >> that use a client library. They can disassemble the class and see the
> logic
> >> how the password is
> >> checked at serverside.
> >
> >
> > Actually, as you may have already noticed, you don't need to hard code
> the
> > passwords in the password callback. You can take them from a database,
> LDAP
> > ( we do have some limitations here ) and do the authentication logic in
> the
> > password callback.
> >
> > Another Problem, i have to make the jars available at clientside that are
> >> needed at serverside in
> >> the PasswordCallBackHandler.
> >> Did i missed something to understand this?
> >>
> >
> > I think you are mislead by the samples here. Usually client and the
> service
> > uses two different password callbacks. So the client only need to have
> it's
> > password callback in it's classpath. For the service, it is the same. It
> > only needs have it's password callback class in it's class path.
> >
> > thanks,
> > nandana
> >
> >
> > [1] -
> >
> http://wso2.org/library/3190#Step_3._Engaging_Rampart_and_setting_authentication_information
> >
>
>
Re: PasswordCallBackHandler in client
Posted by Stefan Lischke <li...@apache.org>.
Thanks,
Great information also for people on axis2-dev[1]!
Next question, is it possible to get the username in the ServiceImplementation to check for rights
to call a method?
Is there a best practise on how to do this?
Maybe adding a parameter to the messageContext in the PWCBHandler and reading it in the Service Impl?
Thanx again in advance
Stefan
[1] https://issues.apache.org/jira/browse/AXIS2-3366
Nandana Mihindukulasooriya wrote:
> Hi Stefan,
>
> Can someone please enlighten me why the PasswordCallBackHandler must also be
>> available at the
>> clientside?
>
>
> Having a password callback at the client is NOT a MUST. You can use clients
> options to provide more information. Please look at this tutorial [1].
>
>
>> Isn't there any other possibility to set the password that will be
>> submitted by the client?
>
>
> Yes, this can be done with the options approach.
>
>
>> In my opinion it is a security matter to deliver the
>> PasswordCallBackHandler class to the customers
>> that use a client library. They can disassemble the class and see the logic
>> how the password is
>> checked at serverside.
>
>
> Actually, as you may have already noticed, you don't need to hard code the
> passwords in the password callback. You can take them from a database, LDAP
> ( we do have some limitations here ) and do the authentication logic in the
> password callback.
>
> Another Problem, i have to make the jars available at clientside that are
>> needed at serverside in
>> the PasswordCallBackHandler.
>> Did i missed something to understand this?
>>
>
> I think you are mislead by the samples here. Usually client and the service
> uses two different password callbacks. So the client only need to have it's
> password callback in it's classpath. For the service, it is the same. It
> only needs have it's password callback class in it's class path.
>
> thanks,
> nandana
>
>
> [1] -
> http://wso2.org/library/3190#Step_3._Engaging_Rampart_and_setting_authentication_information
>
Re: PasswordCallBackHandler in client
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Stefan,
Can someone please enlighten me why the PasswordCallBackHandler must also be
> available at the
> clientside?
Having a password callback at the client is NOT a MUST. You can use clients
options to provide more information. Please look at this tutorial [1].
> Isn't there any other possibility to set the password that will be
> submitted by the client?
Yes, this can be done with the options approach.
> In my opinion it is a security matter to deliver the
> PasswordCallBackHandler class to the customers
> that use a client library. They can disassemble the class and see the logic
> how the password is
> checked at serverside.
Actually, as you may have already noticed, you don't need to hard code the
passwords in the password callback. You can take them from a database, LDAP
( we do have some limitations here ) and do the authentication logic in the
password callback.
Another Problem, i have to make the jars available at clientside that are
> needed at serverside in
> the PasswordCallBackHandler.
> Did i missed something to understand this?
>
I think you are mislead by the samples here. Usually client and the service
uses two different password callbacks. So the client only need to have it's
password callback in it's classpath. For the service, it is the same. It
only needs have it's password callback class in it's class path.
thanks,
nandana
[1] -
http://wso2.org/library/3190#Step_3._Engaging_Rampart_and_setting_authentication_information