Nic Hobbs wrote:
>The TODO list says "Add the ability to require the current user to be in
>a particular security role before they can execute a particular action" if
>this is wrong let me know and I will review it.
I really like what you've started Nic, but should also mention that I
don't think anyone should take the TODO list as gospel. These are just
suggestions people (like you ;-) made on the list that one of us thought
were both interesting and sensible enough to put on the list. It's not
so much a requirements document as a moderated suggestion box or wish
list.
If something works for you, it can't be "wrong" ;-). If others find it
just as useful, then we could vote it into the distribution. But at
Jakarta, the proof is in the code, and the developers make the
decisions.
Meanwhile ...
Nic Hobbs wrote:
> I agree. This was only a first draft based on the particular requirement in
> the TODO. 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. 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?
I like what Turbine has to say about security and permissions.
< http://jakarta.apache.org/turbine/howto/security-howto.html >
Now, can we apply that to Sun's current Principal, Group, and Permission
interfaces?
One approach would be to have the relevent Struts objects call a library
method for things like userInRole(). The library method could then
either check a session object (for application-based) or check the
request (for container-based).
In a way, it would be like the Generic Connection pool. Give people
something that can use if they want, but implement standard interfaces,
so if they want to use something else later, it's easy to switch.
If we stay in the Security package fold, but also allow people to expand
on what container-based can do right now, we could take some practical
suggestions back to Sun about how the next spec should work. So, our
application-based approach could be a case-study for improvements to the
container-based standard.
Chris Miller wrote:
> Won't combining the users and groups into a single list in the action
> element cause problems if there's a user with the same name as a group?
Perhaps, but the Sun documents say that "Thus, either a Principal or a
Group can be passed as an argument to methods containing a Principal
parameter.", and not following that advice may be a different bad
practice.
(IMHO, the bad practice is implementing a security scheme that allows
group and principal names to overlap.)
Perhaps there could be an additional signature if someone needs to work
around this, but there should still be one that accepts them together.
-Ted.
