On 10/31/2012 10:03 AM, Sergey Beryozkin wrote:
> 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
>
Ya, in rereading the servlet spec for FORM auth, the only thing missing
is the ability for the client to know if authentication was successful
or not. Unfortunately, a failed auth results in a redirect to the error
page with a 200 response. Its still something we might want to consider
to support.
As a comparison, I don't think we could ever support OAuth2, at least
the RFC, because the actual authentication and token formats are undefined.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com