Hi Bill, What do you think about having something like the SASL Mechanism Negotiation for JAX-RS ? For example, we can have a Authentication Service (JAX-RS Endpoint) that knows how to negotiate the different supported authentication mechanisms using JSON objects during this interaction. Example: 1) Client requests authentication (possibly implicitly by connecting to the server) 2) Server responds with a list of supported mechanisms using a specific JSON format. The JSON tells which mechanisms are supported and also details about how to use them. 3) Client chose one of the mechanisms. 4) Client uses the information returned by the server to send an authentication request based on the expected format for the mechanism he did choose. Maybe the format can be mapped to a specific credential type (like we have in PicketBox 5). 5) Client and server then exchange data, one round-trip at a time, until authentication either succeeds or fails. Regards. Pedro Igor ----- Original Message ----- From: "Bill Burke" <bburke(a)redhat.com&gt; To: security-dev(a)lists.jboss.org, "Jay Balunas" <jbalunas(a)redhat.com&gt;, "Douglas Campos" <qmx(a)qmx.me&gt;, abstractj(a)redhat.com Sent: Wednesday, November 21, 2012 7:49:30 PM Subject: [security-dev] Resteasy authentication Here's what I'm doing for a Restasy authentication solution (and how it relates to Picketlink). http://bill.burkecentral.com/2012/11/21/scoping-out-resteasy-skeleton-key... I should have something by Christmas that everybody can try out. Probably sooner. Have a nice Thanksgiving everybody. Bill

Share the same feeling regarding browser-based clients. But I think we can focus on how applications/developers can use that. I agree, for now we should go with our own/specific negotiation protocol. Try to think something that later can be integrated. Going to follow your suggestion (paint, implement, integrate), write a requirement/proposal doc (that we can use to discuss) and code something around that. Thanks. Pedro Igor ----- Original Message ----- From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: security-dev(a)lists.jboss.org, "Jay Balunas" <jbalunas(a)redhat.com&gt;, "Douglas Campos" <qmx(a)qmx.me&gt;, abstractj(a)redhat.com Sent: Monday, November 26, 2012 7:38:24 PM Subject: Re: [security-dev] Resteasy authentication Don't know anything about SASL. I do like the idea of negotiation, but am not sure it can work. There's just so many parts to consider: * Browser-based clients can't negotiate * 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 * Any negotiation protocol sounds like it would be proprietary, so why not define our own auth protocols to begin with? IMO, we paint a vision, implement something very specific for that vision, then, later on worry about the ugly-soup of protocols that would need to be integrated. On 11/22/2012 8:48 AM, Pedro Igor Silva wrote: > Hi Bill, > > What do you think about having something like the SASL Mechanism Negotiation for JAX-RS ? > > For example, we can have a Authentication Service (JAX-RS Endpoint) that knows how to negotiate the different supported authentication mechanisms using JSON objects during this interaction. > > Example: > > 1) Client requests authentication (possibly implicitly by connecting to the server) > 2) Server responds with a list of supported mechanisms using a specific JSON format. The JSON tells which mechanisms are supported and also details about how to use them. > 3) Client chose one of the mechanisms. > 4) Client uses the information returned by the server to send an authentication request based on the expected format for the mechanism he did choose. Maybe the format can be mapped to a specific credential type (like we have in PicketBox 5). > 5) Client and server then exchange data, one round-trip at a time, until authentication either succeeds or fails. > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: security-dev(a)lists.jboss.org, "Jay Balunas" <jbalunas(a)redhat.com&gt;, "Douglas Campos" <qmx(a)qmx.me&gt;, abstractj(a)redhat.com > Sent: Wednesday, November 21, 2012 7:49:30 PM > Subject: [security-dev] Resteasy authentication > > Here's what I'm doing for a Restasy authentication solution (and how it > relates to Picketlink). > > http://bill.burkecentral.com/2012/11/21/scoping-out-resteasy-skeleton-key... > > > I should have something by Christmas that everybody can try out. > Probably sooner. > > Have a nice Thanksgiving everybody. > > Bill >

* Browser-based clients can't negotiate

* 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

* Any negotiation protocol sounds like it would be proprietary, so why not define our own auth protocols to begin with? IMO, we paint a vision, implement something very specific for that vision, then, later on worry about the ugly-soup of protocols that would need to be integrated.

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.

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?