On 31/10/12 13:37, Bill Burke wrote:
>
>
> 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.
>
I'd still question 'Form' - I think the 'responsibility' of the spec is
to ensure that the solutions known to work in the Java universe only are
not promoted if there's no evidence that 'Form' is supported well by
windows servers for example, after the client written in JAX-RS 2.0 does
not know how the server is implemented. But if it is known to be
supported across the server stacks, then +1
>>> 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.
>
Look forward to it :-)
Cheers, Sergey