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. Neither does
OAuth2. But, its more than authorization. Any JAx-RS 2.0 client that
wants to talk HTTPS will require some kind of trust-manager configuration.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com