jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: security is a big hole in client API

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 30 Oct 2012 16:49:33 -0400

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.





-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com