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)?
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com