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