You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Brian Bonner <bk...@gmail.com> on 2006/05/04 21:51:29 UTC
WSHandler's CallbackHandler
I've been looking at WSHandler's CallbackHandler. My understanding
from reading the javadoc for WSPasswordCallback, WSHandler, and is
that this is primarily used to call back into the application to get a
password from the user application.
However, II'm unclear as to how this interacts with the server side
portion of the webservice to authenticate the user request.
Can someone help describe how this is supposed to work?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: WSHandler's CallbackHandler
Posted by "Tim K. (Gmane)" <tk...@idpax.com>.
There are 2 ways to do it:
1) If you can get the password (sometimes it's not possible) and use
password type "PasswordDigest", you retrieve it from your password store
(LDAP, database, etc.) and you set it on the WSPasswordCallback you get
in your callback handler by calling WSPasswordCallback.setPassword()
WSS4J should then take care of verifying the password for it. If the
verification fails, you won't get an exception, a fault will be sent to
the client. The usage code for the callback is USERNAME_TOKEN.
2) If you cannot get the password from your password store and you want
to use your own password verification, then I think you need to use a
password type "PasswordText" and the password will be passed to your
callback handler via a WSPasswordCallback object on which you can call
getPassword(). Then you can verify it yourself and throw an exception if
it fails. The usage code for the handler in this case will be
USERNAME_TOKEN_UNKNOWN. Here's what the javadoc for WSPasswordCallback says:
"USERNAME_TOKEN_UNKNOWN - either an not specified password type or a
password type passwordText. In these both cases only the password
variable is set. The callback class now may check if the username and
password match. If they don't match the callback class must throw an
exception. The exception can be a UnsupportedCallbackException or an
IOException"
I hope my explanation is correct and I'm not confusing anyone here. I
only used #1 above and ran into #2 by accident.
Tim
Brian Bonner wrote:
> Let me add, one of my points of confusion is that after I get the
> password (hashed or not) from my application, where does the checking
> of this looked up password to the password sent in the WS:Security
> information take place? i.e. who's is responsible for validating the
> password info? I guess I was expecting to see WSDoAllReceiver to
> throw a WSSecurityException if the values didn't match.
>
> Thanks.
>
> On 5/4/06, Brian Bonner
> <bk...@gmail.com> wrote:
>> I've been looking at WSHandler's CallbackHandler. My understanding
>> from reading the javadoc for WSPasswordCallback, WSHandler, and is
>> that this is primarily used to call back into the application to get a
>> password from the user application.
>>
>> However, II'm unclear as to how this interacts with the server side
>> portion of the webservice to authenticate the user request.
>>
>> Can someone help describe how this is supposed to work?
>>
>> Thanks.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSHandler's CallbackHandler
Posted by "Tim K. (Gmane)" <tk...@idpax.com>.
There are 2 ways to do it:
1) If you can get the password (sometimes it's not possible) and use
password type "PasswordDigest", you retrieve it from your password store
(LDAP, database, etc.) and you set it on the WSPasswordCallback you get
in your callback handler by calling WSPasswordCallback.setPassword()
WSS4J should then take care of verifying the password for it. If the
verification fails, you won't get an exception, a fault will be sent to
the client. The usage code for the callback is USERNAME_TOKEN.
2) If you cannot get the password from your password store and you want
to use your own password verification, then I think you need to use a
password type "PasswordText" and the password will be passed to your
callback handler via a WSPasswordCallback object on which you can call
getPassword(). Then you can verify it yourself and throw an exception if
it fails. The usage code for the handler in this case will be
USERNAME_TOKEN_UNKNOWN. Here's what the javadoc for WSPasswordCallback says:
"USERNAME_TOKEN_UNKNOWN - either an not specified password type or a
password type passwordText. In these both cases only the password
variable is set. The callback class now may check if the username and
password match. If they don't match the callback class must throw an
exception. The exception can be a UnsupportedCallbackException or an
IOException"
I hope my explanation is correct and I'm not confusing anyone here. I
only used #1 above and ran into #2 by accident.
Tim
Brian Bonner wrote:
> Let me add, one of my points of confusion is that after I get the
> password (hashed or not) from my application, where does the checking
> of this looked up password to the password sent in the WS:Security
> information take place? i.e. who's is responsible for validating the
> password info? I guess I was expecting to see WSDoAllReceiver to
> throw a WSSecurityException if the values didn't match.
>
> Thanks.
>
> On 5/4/06, Brian Bonner
> <bk...@gmail.com> wrote:
>> I've been looking at WSHandler's CallbackHandler. My understanding
>> from reading the javadoc for WSPasswordCallback, WSHandler, and is
>> that this is primarily used to call back into the application to get a
>> password from the user application.
>>
>> However, II'm unclear as to how this interacts with the server side
>> portion of the webservice to authenticate the user request.
>>
>> Can someone help describe how this is supposed to work?
>>
>> Thanks.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: WSHandler's CallbackHandler
Posted by Brian Bonner <bk...@gmail.com>.
Let me add, one of my points of confusion is that after I get the
password (hashed or not) from my application, where does the checking
of this looked up password to the password sent in the WS:Security
information take place? i.e. who's is responsible for validating the
password info? I guess I was expecting to see WSDoAllReceiver to
throw a WSSecurityException if the values didn't match.
Thanks.
On 5/4/06, Brian Bonner <bk...@gmail.com> wrote:
> I've been looking at WSHandler's CallbackHandler. My understanding
> from reading the javadoc for WSPasswordCallback, WSHandler, and is
> that this is primarily used to call back into the application to get a
> password from the user application.
>
> However, II'm unclear as to how this interacts with the server side
> portion of the webservice to authenticate the user request.
>
> Can someone help describe how this is supposed to work?
>
> Thanks.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: WSHandler's CallbackHandler
Posted by Brian Bonner <bk...@gmail.com>.
Let me add, one of my points of confusion is that after I get the
password (hashed or not) from my application, where does the checking
of this looked up password to the password sent in the WS:Security
information take place? i.e. who's is responsible for validating the
password info? I guess I was expecting to see WSDoAllReceiver to
throw a WSSecurityException if the values didn't match.
Thanks.
On 5/4/06, Brian Bonner <bk...@gmail.com> wrote:
> I've been looking at WSHandler's CallbackHandler. My understanding
> from reading the javadoc for WSPasswordCallback, WSHandler, and is
> that this is primarily used to call back into the application to get a
> password from the user application.
>
> However, II'm unclear as to how this interacts with the server side
> portion of the webservice to authenticate the user request.
>
> Can someone help describe how this is supposed to work?
>
> Thanks.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org