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

From: Sergey Beryozkin <>
Date: Wed, 31 Oct 2012 10:32:11 +0000

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.

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.

Cheers, Sergey