CXF security without throwing exceptions

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

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

[Glen Mazza <gl...@gmail.com>]

Karthik Abram wrote:
> 
> 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.
> 

I think the error is with our example here[1], when we say
"setPassword("password")" (see the second shaded block).  I think the
example should really say "setPassword("sdklfjhasdf");"--i.e., you want to
feed it the *encrypted* password, not the unencrypted one.  (Dan, am I
correct here?  I'll update the docs if that's the case.)

I book I had recently read, however, mentions other problems with this
mechanism--namely, that the client-side password encryption method used and
the server-side encryption method is rarely the same--stated another way, it
is strange for the client to need to know the encryption method of the
passwords on the server, so it can store the passwords in the same manner.

Glen

[1]
http://cwiki.apache.org/CXF20DOC/ws-security.html#WS-Security-UsernameTokenAuthentication

-- 
View this message in context: http://www.nabble.com/CXF-security-without-throwing-exceptions-tp19227328p19229365.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF security without throwing exceptions

[Glen Mazza <gl...@gmail.com>]

Karthik Abram wrote:
> 
> Does this even make sense? Are there any alternate routes for achieving
> the
> basic goal of not throwing exceptions to signal client auth failure? 
> 

Rather than circumvent the usual exception-based functionality of using
WS-Security directly, I would look at implementing a web service called
validateUser or whatever that returns true/false based on successful or
failed authentication.

Glen

-- 
View this message in context: http://www.nabble.com/CXF-security-without-throwing-exceptions-tp19227328p19228698.html
Sent from the cxf-user mailing list archive at Nabble.com.