users@jax-rs-spec.java.net

[jax-rs-spec users] Re: JAX-RS Security

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Sat, 13 Dec 2014 01:37:04 +0100

Hi,

On Fri, Dec 12, 2014 at 11:45 PM, Markus KARG <markus_at_headcrashing.eu>
 wrote:

> Casey,
>
> I am not a security guy at all, so please don't mind if the question is
> dumb, but doesn't JAAS already define interfaces for authentication
> providers? If so, we could use those instead of reinventing the wheel.
>

It depends on what's exactly meant with "authentication provider". The
terminology here is not always used consistently.

What I think you're referring to in JAAS is the LoginModule interface. This
is basically a "repository" of users and their groups/roles, but not really
a "mechanism" via which to interact with a user in order to obtain their
credentials.

For this latter thing Java EE has defined the ServerAuthModule and
ClientAuthModule interfaces. Implementations of ServerAuthModule are used
for interactions between a client and a server. For instance the well known
Servlet mechanisms FORM and BASIC can be implemented by a ServerAuthModule,
as is OAuth1/2 for use cases such as implementing a "login with Facebook"
facility for a website.

Since the question was about the client API, maybe the ClientAuthModule
would be applicable here, but I know little about that.

p.s. JAAS is also probably not the universal standard that you think it is
;) See
http://arjan-tijms.omnifaces.org/2014/02/jaas-in-java-ee-is-not-universal.html

Kind regards,
Arjan Tijms

On Fri, Dec 12, 2014 at 11:45 PM, Markus KARG <markus_at_headcrashing.eu>
wrote:

> Casey,
>
> I am not a security guy at all, so please don't mind if the question is
> dumb, but doesn't JAAS already define interfaces for authentication
> providers? If so, we could use those instead of reinventing the wheel.
>
> Regards
> -Markus
>
> -----Original Message-----
> From: Casey Lee [mailto:cplee_at_nektos.com]
> Sent: Freitag, 12. Dezember 2014 17:53
> To: jsr370-experts_at_jax-rs-spec.java.net
> Subject: JAX-RS Security
>
> I have some opinions on opportunities for adding security to JAX-RS.
> First, on the client side I'd love to see a method added to
> Invocation.builder to add an implementation of a new interface named
> AuthorizationProvider. This would allow implementations of
> AuthorizationProvider to be created for specific types of authz...like
> OAuth2AuthorizationProvider or BasicAuthorizationProvider. These providers
> would be responsible for applying necessary Authorization header (or query
> params?) to the invocation. What are the thoughts on adding some standard
> providers to the API? OAuth 2.0 for example is something that has become
> ubiquitous, but has a steep learning curve for developers to use properly.
>
> On the server side aren't the JSR-250 security annotations supported by
> JAX-RS? Or is that only implemented by some specific vendors?
> Seems that those solve course grained security (by role). We have chosen
> to leverage those annotations and treat OAuth 2.0 scopes as roles. Would
> it make sense to have a more OAuth 2.0 specific solution (@ScopesAllowed)?
>
> -Casey
>
>