user/roles provider for AAA?

[Kristian Rink]

Folks;

being through deploying a bunch of REST services using
Jersey/Glassfish 3.1 with an apache2 in front of this mess, I am now
into dealing with authentication, authorization, this kind of stuff.
At the moment I am using .htaccess inside the apache2, but somehow I
think making use of facilities provided by Glassfish/Jersey in order to
get things secured. More accurately, I would like to...

- ... set up my applications to enforce (by now) basic HTTP
  authentication _anytime_ any of the REST resources is being accessed,

- ... use @RolesAllowed in order to outline which methods might be used
  by which user in which way.


So far, so good. However, the only documentation I so far found is
about either defining roles and users in web.xml or setting up a
container-sided JAAS (Jdbc, ...) realm for fetching user information.
Both, however, is not what I want / need / can make use of as, in our
environment, user/role information are to be provided by a legacy
backend which just can be reached through a bunch of obscure glue code.

So to ask: Is there any straightforward documentation on how to provide
custom data access services / authenticators to make Glassfish/Jersey
authentication / roles resolution make use of our custom user structure?

TIA and all the best,
Kristian

[Moises Lejter]

A simple answer I think might involve a Jersey (or servlet) filter that calls out to your back end authentication service, then uses the programmatic login features of servlet 3.0.  Once your call has logged in, the @RolesAllowed machinery in Jersey should work ...

Moises

Sent from my iPhone

On Apr 28, 2011, at 8:07 AM, Kristian Rink <[hidden email]> wrote:

> Folks;
>
> being through deploying a bunch of REST services using
> Jersey/Glassfish 3.1 with an apache2 in front of this mess, I am now
> into dealing with authentication, authorization, this kind of stuff.
> At the moment I am using .htaccess inside the apache2, but somehow I
> think making use of facilities provided by Glassfish/Jersey in order to
> get things secured. More accurately, I would like to...
>
> - ... set up my applications to enforce (by now) basic HTTP
>  authentication _anytime_ any of the REST resources is being accessed,
>
> - ... use @RolesAllowed in order to outline which methods might be used
>  by which user in which way.
>
>
> So far, so good. However, the only documentation I so far found is
> about either defining roles and users in web.xml or setting up a
> container-sided JAAS (Jdbc, ...) realm for fetching user information.
> Both, however, is not what I want / need / can make use of as, in our
> environment, user/role information are to be provided by a legacy
> backend which just can be reached through a bunch of obscure glue code.
>
> So to ask: Is there any straightforward documentation on how to provide
> custom data access services / authenticators to make Glassfish/Jersey
> authentication / roles resolution make use of our custom user structure?
>
> TIA and all the best,
> Kristian

[ljnelson]

On Thu, Apr 28, 2011 at 9:10 AM, Kristian Rink [via Jersey] <[hidden email]> wrote:

However, the only documentation I so far found is
about either defining roles and users in web.xml or setting up a
container-sided JAAS (Jdbc, ...) realm for fetching user information.
Both, however, is not what I want / need / can make use of as, in our
environment, user/role information are to be provided by a legacy
backend which just can be reached through a bunch of obscure glue code.

The "proper" way to do it is to set up a JACC provider.  It is a woefully underdocumented pain in the neck, but that's the facility that the Java EE stack provides to bind a @RolesAllowed check to a java.security.Policy, which can serve as the front end to your obscure glue code.

A ServletFilter will not work in this case, if I understand your requirements correctly, because a ServletFilter of any kind cannot programmatically assign roles to a user, which is what you need.

Start the whole JACC mess with implementing a java.security.Policy.  You'll want to override the implies() method.  Once you've got that, then start reading about JACC.

Best,
Laird

[Kristian Rink]

Moises;

first off, thanks a bunch for your comment on that, much appreciated!

Am Thu, 28 Apr 2011 08:14:53 -0500
schrieb Moises Lejter <[hidden email]>:

> A simple answer I think might involve a Jersey (or servlet) filter
> that calls out to your back end authentication service, then uses the
> programmatic login features of servlet 3.0.  Once your call has
> logged in, the @RolesAllowed machinery in Jersey should work ...

Well yes, I was thinking about servlet filters here and login() as
well. However so far either I completely got something wrong or I
didn't so far figure out how to correctly put things together. Isn't
login() just making use of the preconfigured security mechanisms in
order to do what needs to be done? If so, how can I "override" this
kind of behaviour in a filter? Loading some kind of (custom) principal
and assigning this to the security context? Asides this, would this
also work with (programmatic) clients that make use of HTTP basic
authentication headers?

Oh well, guess I got some more reading to do...
Thank you very much nevertheless... :)
Kristian

[Kristian Rink]

Hi Laird;

and thanks very much for your thoughts on that... :

Am Thu, 28 Apr 2011 06:29:06 -0700 (PDT)
schrieb ljnelson <[hidden email]>:
> The "proper" way to do it is to set up a JACC provider.  It is a
> woefully underdocumented pain in the neck, but that's the facility
> that the Java EE stack provides to bind a @RolesAllowed check to a
> java.security.Policy, which can serve as the front end to your
> obscure glue code.

Aaah. Looking at our earlier trips to JAAS / JACC world, I already
feared it would boil down to doing this kind and amount of work. Oh
well... :)

> Start the whole JACC mess with implementing a java.security.Policy.
> You'll want to override the implies() method.  Once you've got that,
> then start reading about JACC.

I'll have a look at it and see how far I get, following this road.
Hope I'll not end up learning that implementing a custom apache2
authentication module is the more sane thing to do... ;)

Thanks anyway for your help, all the best.
Kristian

[ljnelson]

On Thu, Apr 28, 2011 at 9:35 AM, Kristian Rink [via Jersey] <[hidden email]> wrote:

Well yes, I was thinking about servlet filters here and login() as
well. However so far either I completely got something wrong or I
didn't so far figure out how to correctly put things together. Isn't
login() just making use of the preconfigured security mechanisms in
order to do what needs to be done?

Jumping in here, yes, that's exactly right--unless you use JACC, you won't be able to tie your security system's notion of authorization into Glassfish's notion of authorization.  You can of course bypass Glassfish's notion of authorization by handling security yourself and not messing around with @RolesAllowed at all, but if you want to accomplish role-based security by using the standard annotations, you really don't have any choice.  :-(

The other thing about JACC is that your Policy ends up being the One True Policy for the entire JVM, not just for your web application.  So you need to write a Policy that wraps another and delegates to it as necessary.  JACC looks like it was pulled out of the oven waaaaay too early.

Best,
Laird

[Kristian Rink]

Am Thu, 28 Apr 2011 07:26:07 -0700 (PDT)
schrieb ljnelson <[hidden email]>:

> The other thing about JACC is that your Policy ends up being the One
> True Policy for the entire JVM, not just for your web application.
> So you need to write a Policy that wraps another and delegates to it
> as necessary.  

Yes, exactly this is what so far pretty much scared me off messing with
java.security.Policy altogether - it seems way too low-level and too
global to actually deal with it. But if this is the only way, I guess
there's not much to choose from... :/

Cheers,
Kristian

[Kristian Rink]

Am Thu, 28 Apr 2011 06:29:06 -0700 (PDT)
schrieb ljnelson <[hidden email]>:
> Start the whole JACC mess with implementing a java.security.Policy.
> You'll want to override the implies() method.  Once you've got that,
> then start reading about JACC.

As another thought, couldn't I somehow make use of JAAS and map JAAS
principals to (application specific) roles for use with @RolesAllowed
in some way? I know dealing with JAAS also is painful at times but at
least it seems less "invasive" than messing with java.security.Policy,
and it seems a bit more well-documented...

Cheers,
Kristian

[ljnelson]

On Thu, Apr 28, 2011 at 10:59 AM, Kristian Rink [via Jersey] <[hidden email]> wrote:

As another thought, couldn't I somehow make use of JAAS and map JAAS
principals to (application specific) roles for use with @RolesAllowed
in some way?

Well, JACC is a specification that governs how JAAS is to be used in a Java EE environment.

Ultimately, JAAS uses a Policy.  JACC formalizes what kinds of Permissions get handed to a Policy in the world of a Java EE application.

L

[Kristian Rink]

Am Thu, 28 Apr 2011 08:02:38 -0700 (PDT)
schrieb ljnelson <[hidden email]>:

> > As another thought, couldn't I somehow make use of JAAS and map JAAS
> > principals to (application specific) roles for use with
> > @RolesAllowed in some way?
> >
>
> Well, JACC is a specification that governs how JAAS is to be used in
> a Java EE environment.
> Ultimately, JAAS uses a Policy.  JACC formalizes what kinds of
> Permissions get handed to a Policy in the world of a Java EE
> application.

Ah, thanks for clarifying and sorry for the mess-up. Looking at the
state of APIs and technologies in Java EE > 1.4, I have to say that
this is not (yet?) on par with servlets and friends from an ease-of-use
point of view, which eventually is not a good thing as we're talking
about security. ;)

Anyway: At the moment I try evaluating which solutions are at hand to
be used in our case. This is how I see things at the moment:

* Use the @RolesAllowed and, ultimately, JACC and java.security.Policy.
  This is a tedious bunch of work which would not be too difficult, but
  from my point of view this goes too deep into the whole rest of the
  infrastructure as, as pointed out before, it is effective not just on
  application- or application server but even on VM level. Given our
  current lack of experience with this technology, from my point of
  view this is too risky to be a real option.

* Go for a "proprietary" way and make use of a servlet filter wrapped
  around the JAX-RS endpoints to take care of auth and access control.
  This is not a really clean way but it seems the least painful in
  terms of overall scope of changes as it just affects the resources to
  be protected.

* Find another option on a level not as low/general as
  java.security.Policy to just take care of the features we need. Given
  in most cases there are many ways of how to extend or hook into
  existing technologies, I really am surprised to see this ain't
  possible here. After reading through [1], I stumbled across [2] in
  order to write a custom (Glassfish) realm to provide just what we
  need here - domain-specific user and group names to then be mapped to
  application specific roles, but, given our elaborations on JACC, I am
  unsure whether this would really do what we need here.

Thoughts on that, anyone? Would the custom-realm approach (a) work and
(b) do? Any pitfalls, ... to expect here?

TIA and all the best,
Kristian


[1]http://download.oracle.com/javaee/5/tutorial/doc/bnbxj.html
[2]http://blogs.sun.com/nithya/entry/groups_in_custom_realms

[Moises Lejter]

Well - I think there are a couple ideas...

- Jersey (the JAX-RS runtime built into Glassfish) supports
@RolesAllowed on methods of JAX-RS POJO resources.  
To use this, it is enough that the web container can authenticate
the caller, and have mappings from authenticated user ids to
groups (in sun-web.xml, in Glassfish), which Jersey will then
map to the roles in @RolesAllowed (with the help of the
role-ref mappings in web.xml?).  This would not require
that you mess with java.security.Policy.

- You would need to provide a way for the request.login()
method to interact with your authentication infrastructure.
(I had not thought this through, before :-( ).  But you should not
need to mess with JACC, since it will in turn  call on JAAS to
authenticate login() requests - so you just need to
write logic to have JAAS invoke your authentication service.

- You could interact with your authentication service in a
filter, then implement a JAAS provider that will simply accept
on faith calls to logic() from your application - which you would
carefully only call from your filter, after you've already authenticated
users directly yourself.  However, I don't think that writing a JAAS
provider for your authentication service should be that hard...

Moises

On Apr 28, 2011, at 1:26 PM, Kristian Rink wrote:

> Ah, thanks for clarifying and sorry for the mess-up. Looking at the
> state of APIs and technologies in Java EE > 1.4, I have to say that
> this is not (yet?) on par with servlets and friends from an ease-of-use
> point of view, which eventually is not a good thing as we're talking
> about security. ;)
>
> Anyway: At the moment I try evaluating which solutions are at hand to
> be used in our case. This is how I see things at the moment:
>
> * Use the @RolesAllowed and, ultimately, JACC and java.security.Policy.
> This is a tedious bunch of work which would not be too difficult, but
> from my point of view this goes too deep into the whole rest of the
> infrastructure as, as pointed out before, it is effective not just on
> application- or application server but even on VM level. Given our
> current lack of experience with this technology, from my point of
> view this is too risky to be a real option.
>
> * Go for a "proprietary" way and make use of a servlet filter wrapped
> around the JAX-RS endpoints to take care of auth and access control.
> This is not a really clean way but it seems the least painful in
> terms of overall scope of changes as it just affects the resources to
> be protected.
>
> * Find another option on a level not as low/general as
> java.security.Policy to just take care of the features we need. Given
> in most cases there are many ways of how to extend or hook into
> existing technologies, I really am surprised to see this ain't
> possible here. After reading through [1], I stumbled across [2] in
> order to write a custom (Glassfish) realm to provide just what we
> need here - domain-specific user and group names to then be mapped to
> application specific roles, but, given our elaborations on JACC, I am
> unsure whether this would really do what we need here.

[Martin Matula-3]

Other option is to handle it yourself and override the default
SecurityContext in the Jersey request. That way the @RolesAllowed
annotations applied to your resource methods will still work. You can
look at how this is done in the oauth-server module to do the
oauth-based authentication - see the filter() and getSecurityContext()
methods here:
http://java.net/projects/jersey/sources/svn/content/trunk/jersey/contribs/jersey-oauth/oauth-server/src/main/java/com/sun/jersey/oauth/server/api/OAuthServerFilter.java?rev=4895
Martin

On 28.4.2011 16:38, Kristian Rink wrote:

> Am Thu, 28 Apr 2011 07:26:07 -0700 (PDT)
> schrieb ljnelson<[hidden email]>:
>
>> The other thing about JACC is that your Policy ends up being the One
>> True Policy for the entire JVM, not just for your web application.
>> So you need to write a Policy that wraps another and delegates to it
>> as necessary.
> Yes, exactly this is what so far pretty much scared me off messing with
> java.security.Policy altogether - it seems way too low-level and too
> global to actually deal with it. But if this is the only way, I guess
> there's not much to choose from... :/
>
> Cheers,
> Kristian