Antony Bowesman wrote:
>
> Andy Armstrong wrote:
[snip]
> > I've just been having a look at this. As you say it would be easy enough
> > to implement a JAAS realm -- the main problem being how to provide
> > access to the JAAS Subject. The cleanest route would seem to be just to
> > expose the Subject directly by adding
> >
> > Subject getUserSubject()
> >
> > to HttpServletRequest() leaving the question of how to change the
> > handling of Principals to reflect the fact that there can be more than
> > one under JAAS.
>
> Exactly, I would hope that this is how it will be exposed in Servlet and
> EJB specs with getUser/CallerPrincipal being deprecated in favour of
> getUser/CallerSubject.
Do we know if there's any likelyhood of this happening?
> Another issue is how roles work. The current isUser/CallerInRole
> methods are rather simple. Mapping realm roles to application roles
> needs to be addresses, I see that Alex Roytman's mail to user group
> allows for a role mapping class to map from user realm roles to the J2EE
> roles in the servlet spec. I also have the same concept with my JAAS
> realm so that user realm roles can be mapped to J2EE String roles based
> on the web app context. It seems to make sense that roles would be
> incorporated as Principals inside the Subject so they could then be used
> inside JAAS authorization.
In general JAAS providers do seem to map roles (or groups) to Principals
whenever the concept makes sense.
--
Andy Armstrong, Tagish
