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.