[security-dev] Resteasy authentication

[Bill Burke]

On 11/29/2012 11:13 AM, Darran Lofthouse wrote:
> 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.
>

Sweet!  You learn something new every day.  Especially if you're pretty 
much a security noob to begin with like me!

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

Ya, take my proclamation with a 60% probability it is true.  I just 
remember setting up JBossWeb to "WANT" and my browser doing nothing when 
I connected.  Maybe its because my browser didn't have any certs 
installed, so it didn't bother prompting me.

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

I don't think you need to know the identity of the application at 
connection establishment. Just have JBossWeb accept all certificates, 
dispatch the request,  then verify the certificate with the bound 
Security Domain.  Am I wrong here?


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