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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> >Sent: 14 January 2008 12:18
> >To: [email protected]
> >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
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
