CXF security without throwing exceptions

[Karthik Abram <ka...@neovera.com>]

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

Re: CXF security without throwing exceptions

[Daniel Kulp <dk...@apache.org>]

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
dkulp@apache.org
http://www.dankulp.com/blog