On 10/31/2012 9:28 AM, Sergey Beryozkin wrote:
> On 31/10/12 13:18, Bill Burke wrote:
>>
>>
>> On 10/31/2012 6:32 AM, Sergey Beryozkin wrote:
>>> On 30/10/12 20:49, Bill Burke wrote:
>>>>
>>>>
>>>> On 10/30/2012 2:23 PM, Sergey Beryozkin wrote:
>>>>> On 30/10/12 18:16, Bill Burke wrote:
>>>>>>
>>>>>>
>>>>>> On 10/30/2012 6:28 AM, Sergey Beryozkin wrote:
>>>>>>> On 29/10/12 21:27, Marek Potociar wrote:
>>>>>>>> Yes, I meant specifically SSLContext and the related APIs
>>>>>>>> (KeyManager,
>>>>>>>> TrustManager ...)
>>>>>>>>
>>>>>>>> I did not have any specific APIs in mind when it comes to auth
>>>>>>>> modes
>>>>>>>> in general - there may be something more in JAAS, but i'm not
>>>>>>>> extremely familiar with it...
>>>>>>> JAAS is the server side thing. At the client side, what can be
>>>>>>> handy, is
>>>>>>> to introduce a property (as Bill suggested), something like
>>>>>>>
>>>>>>> "client.authenticator" which will map to ClientAuhenticator
>>>>>>> interface,
>>>>>>> and JAX-RS will offer few well-known imlpementations, I would
>>>>>>> limit it
>>>>>>> to BasicClientAuhenticator for a start. and the runtime would do:
>>>>>>>
>>>>>>> String authorizationHeader =
>>>>>>> get("client.authenticator").toAuthorizationHeader();
>>>>>>>
>>>>>>
>>>>>> I really do not want to define a security SPI. IMO, we don't need
>>>>>> one as
>>>>>> filters/interceptors can pretty much implement anything. I just
>>>>>> want a
>>>>>> simple portable way to connect to and interact with Java EE servlet
>>>>>> containers, i.e. support for HTTPS, Basic, Digest, Client-cert, and
>>>>>> Form
>>>>>> based authentication. I prefer a simple property-based approach, but
>>>>>> would support a more type-safe interface as long as it didn't
>>>>>> impose an
>>>>>> implementation constraints.
>>>>> Either approach is fine for me, I do not mind.
>>>>>
>>>>> Now, as far as Form is concerned, how interoperable is that, and what
>>>>> exactly a client can do about if it is cookie based (this is what I
>>>>> know
>>>>> about it)?
>>>>>
>>>>
>>>> The servlet spec defines the form parameters the login.html form must
>>>> have. It also defines the name of the cookie if that is the tracking
>>>> mechanism.
>>>>
>>>>> Actually, the point about SPI, it does not have to be SPI, just simple
>>>>> optional registration from the code only. Whatever the client chooses,
>>>>> it all ends up in HTTP Authorization, as far as the authentication is
>>>>> concerned
>>>>>
>>>>
>>>> I just didn't like your example of defining an authorization header
>>>> method. I think many of us delegate to Apache Client 4 for auth.
>>>>
>>>
>>> Sure, let the individual implementations decide how the authentication
>>> is managed, I just don't want the fact that some stacks may prefer to
>>> delegate to some embedded HTTP one affect the overall approach.
>>>
>>
>> That's my point. With properties, or config objects, you don't care how
>> it is implemented.
>>
>>> I guess the question is, if we were to go the untyped way, how to group
>>> the properties correctly, given that every authentication scheme has its
>>> own requirements/rules. Should we go half-way and offer a support for
>>> Basic/Digest or offer a mechanism to get Spnego supported, etc.
>>>
>>> AFAIK, Apache HTTP client offers a superior support for NTLM, but most
>>> other mechanisms can be managed without it, as I said, ultimately it is
>>> about populating Authorization header.
>>>
>>
>> Client-cert does not involve authorization headers.
>
> Agreed, it is at a lower level though, so support for populating
> Authorization headers is orthogonal
>
Its not orthogonal, its irrelevant. If you want to write your own
protocol, then write a filter that sets the appropriate authorization
headers. Its pretty much how we support things like Openstack's
Keystone protocol.
What we're talking about here is providing built-in support for the HTTP
authentication mechanisms defined and supported in Java EE: Basic,
Digest, Form, client-cert. And also HTTPS.
>> Neither does OAuth2.
>
> It does
>
I''m pretty sure OAuth 2 uses form parameers and query parameters to
transmit information. As...it is totally a browser-based protocol. I
know you know OAuth 1 has headers, :)
>> But, its more than authorization. Any JAx-RS 2.0 client that wants to
>> talk HTTPS will require some kind of trust-manager configuration.
>
> Agreed, but again, it is an orthogonal issue
>
I'll write up a more detailed proposal later this week.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com