[security-dev] Resteasy authentication

[Anil Saldhana]

Pedro/Bill,
   sasl has custom auth mechanisms.

Regards,
Anil

On 11/26/2012 03:56 PM, Pedro Igor Silva wrote:
> 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 at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: security-dev at lists.jboss.org, "Jay Balunas" <jbalunas at redhat.com>, "Douglas Campos" <qmx at qmx.me>, abstractj at 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 at redhat.com>
>> To: security-dev at lists.jboss.org, "Jay Balunas" <jbalunas at redhat.com>, "Douglas Campos" <qmx at qmx.me>, abstractj at 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-security/
>>
>>
>> I should have something by Christmas that everybody can try out.
>> Probably sooner.
>>
>> Have a nice Thanksgiving everybody.
>>
>> Bill
>>