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:
Either approach is fine for me, I do not mind.
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 APIsJAAS is the server side thing. At the client side, what can be
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...
to introduce a property (as Bill suggested), something like
"client.authenticator" which will map to ClientAuhenticator
and JAX-RS will offer few well-known imlpementations, I would
to BasicClientAuhenticator for a start. and the runtime would do:
String authorizationHeader =
I really do not want to define a security SPI. IMO, we don't need
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
based authentication. I prefer a simple property-based approach, but
would support a more type-safe interface as long as it didn't
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
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
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
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.
[jsr339-experts] Re: [jax-rs-spec users] security is a big hole in client API
[jsr339-experts] Re: [jax-rs-spec users] Re: security is a big hole in client API