Skip to main content

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

  • From: Sergey Beryozkin <sberyozkin@...>
  • To: <jsr339-experts@...>
  • Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: security is a big hole in client API
  • 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





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

(continued)

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

Bill Burke 10/29/2012

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

Marek Potociar 10/29/2012

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

Sergey Beryozkin 10/30/2012

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

Marek Potociar 10/30/2012

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

Sergey Beryozkin 10/30/2012

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

Bill Burke 10/30/2012

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

Sergey Beryozkin 10/30/2012

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

Bill Burke 10/30/2012

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

Sergey Beryozkin 10/31/2012

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

Bill Burke 10/31/2012

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

Sergey Beryozkin 10/31/2012

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

Bill Burke 10/31/2012

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

Sergey Beryozkin 10/31/2012

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

Bill Burke 10/31/2012
 
 
Close
loading
Please Confirm
Close