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 <kawazu428_at_googlemail.com> 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