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

From: Sergey Beryozkin <>
Date: Wed, 31 Oct 2012 13:28:36 +0000

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

> Neither does OAuth2.

It does

> 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

Cheers, Sergey