I guess the question is:  what do you WANT to happen if the authentication 
fails?

An incoming custom interceptor really could do anything you want.   You can 
validate the user and if it's not correct, pause/stop the current chain, grab 
the response conduit, and write out any type of response you want.

Dan



On Tuesday 02 September 2008 9:55:00 am Karthik Abram wrote:
> Resending without the cert .
>
> I'm implementing a web service with security authentication (using plain
> text password passed in and a custom password handler callback). Everything
> works fine except for the fact that when a login/password fails
> authentication, the only resort is to throw a WSSecurityException or
> SoapFault. Given that the clients of the service are going to be using a
> GUI into which they explicitly login, getting username/password wrong is
> going to be a very common issue and shouldn't really result in a
> server-side exception. The only workaround I can think of is to:
>
>
>
> -          Introduce some sort of interceptor on the service side to add
> header params for the username/password in the WSDL without necessarily
> defining a @WebParam() annotation in every single method. I saw something
> about this in the FAQ but if someone can give me a concrete example, that
> would be swell.
>
> -          Have a custom interceptor that processes the username/password
> in the incoming header params, does the auth and sets some kind of result
> (lets say in a thread-local). Have the service invoker bypass the method
> execution and return without throwing an exception.
>
>
>
> Does this even make sense? Are there any alternate routes for achieving the
> basic goal of not throwing exceptions to signal client auth failure?
>
>
>
> Also, the PasswordDigest handler mechanism in some ways seems useless. The
> handler expects one to retrieve a plain text password given a user
> identity. That assumes people have access to plain-text passwords in the
> first place! We store one-way hashed passwords and I suspect this is very
> common and also recommended. So the digest service would be rather useless
> in this scenario.
>
>
>
> Thanks
>
>
>
> Karthik Abram



-- 
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Reply via email to