[security-dev] Resteasy authentication

[Darran Lofthouse]

On 11/29/2012 04:00 PM, Bill Burke wrote:
>
>
> 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.

Yes if you are combining the two you need to set it to "WANT", that way 
a client can provide it if it can or use username/password auth if it can't.

>> 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.

And SPNEGO.

Maybe not the MD5 variant but the enhanced variants of Digest could 
offer a lot for browser based apps as you potentially gain the addition 
of integrity protection - although for that we do need to wait to see if 
the RFC is finalised and the browsers implement it.

>>> * 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.

Last time I tried this I did have reasonable coverage of the browsers - 
I would need to test again to verify if it applies to all browsers.

> 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.

Yes that is a general problem as until the connection is established it 
is not possible to identify which application is being accessed.

>
>