[security-dev] Resteasy authentication

Bill Burke bburke at redhat.com
Thu Nov 29 11:00:36 EST 2012



On 11/28/2012 10:01 AM, Darran Lofthouse wrote:
> Just catching up on some threads before getting back to some HTTP
> authentication myself.
>
> On 11/26/2012 09:38 PM, Bill Burke wrote:
>> * Browser-based clients can't negotiate
>
> That is not completely true - there is a limited level of negotiation
> within browsers as HTTP already supports multiple mechanisms concurrently.
>

There's not many protocols that the browser supports for 
WWW-Authenticate challenges.  (Basic and Digest?)  An SSL connection set 
up to "NEED" a client-cert will force the browser to prompt the user for 
a cert.  But this isn't negotiation, its, provide me a cert or you are 
not allowed to connect.

> Within AS7 and Remoting for SASL we provide the client with a list of
> supported mechanism, the client chooses one mechanism - tries to auth,
> fails and then tries the next mechanism on the list.  It is true that
> this sequence is not possible within HTTP.
>
> However for the HTTP authenticators I am currently working instead of
> sending the client the simple list we send them a response containing a
> challenge for each supported mechanism - the browser then chooses which
> mechanism it supports and uses it to respond to the challenge.
>

I think browsers can just handle basic and digest auth. That's it. Both 
protocols are not really used for browser-based apps.


>> * client-cert auth is just completely different than other auth
>> mechanisms as is part of the socket connection set up, and nothing to do
>> with HTTP
>
> Combining client-cert auth with other http mechanisms is more about
> prioritising the order we make the decisions regarding authenticating so
> checking if there is a client certificate available on the connection
> that we can use to authenticate before we make the decision to send the
> challenges.
>

This is problematic too for a couple of reasons.  YOu can set up your 
socket layer (in JBoss) to NEED a client cert, but unfortunately, this 
will be for *EVERY* web app.  If you change SSL to "WANT" client-cert, 
I'm not sure every browser will prompt you for a client cert.

Another thing that sucks is that JBossWeb pretty much requires you to 
plug in a global truststore for client-certs when you configure SSL for 
it.  So, you can't have different truststores for different apps and 
have the security domain handle the verification of the client certificate.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the security-dev mailing list