See a couple of inserted comments below.
On Mon, 30 Jul 2001, Nic Hobbs wrote:
> Again comments below ;)
>
> Regards,
>
> Nic
> ----- Original Message -----
> From: "Ted Husted" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, July 29, 2001 12:07 PM
> Subject: Re: Role-based security
>
>
> > There are a number of problems with deploying container-based security.
> > It's an important feature, but it doesn't seem like a panacea.
> >
> > What I would suggest is that we look at Nic's proposal from the
> > viewpoint of being able to also implement FORM-based security, using the
> > standard Java packages.
> >
> This is how I envisaged it. I don't think it is possible to come up with a
> solution that is useable on all platforms at the moment if it is not based
> on the way the specs dictate security - however insufficient that is.
>
> > Craig's mentioned that it's not possible to set the role programatically
> > when container-based security is used, presumably because the container
> > does it. But I've been wondering if it is possible to set it
> > programatically when the container does NOT use it. For example, could
> > the controller set the role for every request -- instead of the
> > container.
> >
> I wonder how much of this would be container specific? Can we
> programmatically set the role so that it is accessible from the isUserInRole
> calls to stay standard?
>
In servlet 2.2, the answer is "no". In servlet 2.3, the answer is "yes",
but a few cautions apply.
The reason you cannot do this in 2.2 is that there is no legal way to
"wrap" the request object received from the container before passing it on
to a request dispatcher. (FWIW, this is why the multipart request
handling stuff is so messy in Struts 1.0).
In servlet 2.3, you can legally wrap a request (or response, for that
matter, but it's request that matters for this purpose) before handing it
on via RequestDispatcher. Indeed, you can set up a Filter that gets
control before the servlet does and plays the same game. Therefore, you
can modify what isUserInRole() or getUserPrincipal() will return to the
called servlet.
The caution has to do with the fact that, in a J2EE environment, your user
identity and roles (as far as the EJB layer is concerned) will not be
paying any attention to games you play here. One of the advantages of
using container-managed security is that your user identity (and
roles) propogate across in J2EE environments.
>
> > Roles are helpful, but I think many real-life applications also need to
> > look at groups and permissions. If we had a security framework that
> > worked with or without the container's help, it would be worthwhile to
> > build fine-grained security into other parts of Struts.
> >
Personally, I think of "roles" and "groups" as pretty much the same thing.
If we want to create a security model totally independent of that required
by the container, that's fine ... but it should *not*, IMHO, masquerade as
being container-managed security. That would be confusing to application
developers, as well as being a source of possible portability problems --
you're relying on commonly implemented behavior of some pretty arcane
stuff.
Also, writing such a layer would be enormously simpler in a Servlet 2.3
environment where you can use filters.
> I agree. This was only a first draft based on the particular requirement in
> the TODO.
FWIW, when I wrote the TODO item I was *definitely* thinking of "roles" as
defined in the container-managed security model.
> I wonder though whether those with clout at sun should force a
> rethink in the J2EE security architecture though as most people I speak to
> think it is insufficient and even JAAS has its holes. I think us coming up
> with a struts way of doing things is good for a webapp but when the security
> context has to be propogated across to the EJB layer for standard security
> (or even custom security) at that level we may have problems.
s/may have problems/*will* have problems/ :-)
IMHO, the significant hole in the current container-managed security model
is the lack of a common Service Provider Interface (SPI) so that an
application could plug its own authentication machinery into a
container. If that were possible, then it would be quite easy to write a
completely portable app that relies on container-managed security. As
things stand, your application is still portable -- but the mechanisms by
which the container stores users and roles is container-specific.
During the development of the 2.3 spec, there was substantial discussion
on at least three approaches to dealing with this. Alas, there wasn't
time to complete it ... and, because it relates to EJB security as well,
it's really bigger than just a servlet spec issue. I wouldn't be at all
surprised to see this topic addressed in a complete manner in J2EE 1.4.
> Perhaps we
> should start up a discussion on this separately as this is likely to be a
> big piece of work that many will want to contribute to (ideas of not
> implementations anyway!). Comments?
>
We can if you want ... my personal preference is that we really should
integrate with the container-managed security model, and that anything we
do for an application-managed security model should be based on Servlet
2.3. There are just too many limitations in Servlet 2.2 to pull off
anything elegant and useful.
> Again thanks for your input Ted.
>
Craig
