Comments below.
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 30, 2001 12:43 PM
Subject: Re: Role-based security
> 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.
>
It sounds from your tone that you think I was offended by something someone
said - this is not the case. Sorry if I came across a little strongly then,
I was not aware I had. I only meant that that is where I had started with
this (i.e. with the TODO) and that it was meant to generate comments. I only
wanted to make the point that the TODO started with the role-based security
for actions and that is what I based my stuff on, and it was not meant to
be, nor is it sufficient to be, a fully fledged security solution. I am
happy to be involved in and work on something more appropriate though.
> If something works for you, it can't be "wrong" ;-). If others find it
Did I imply something was "wrong"? If I did that wasn't my intention.
> 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.
>
Yes I understand how it works ;)
> 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 >
>
This looks like a good basis.
> 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.
>
Sorry, I am probably about to repeat what you have said far more concisely,
but humour me a minute - I'm british! I think what you are saying is have a
"struts security" method that wraps the implementation of the check -
whether it be application based programmatic security or declarative
container-based - but use the standard interfaces (Principal etc.) as the
basic building blocks that are passed around? I think my question (sorry I
had to write all that above to understand what it was I was trying to ask!)
is you say "standard interfaces" in the last paragragh, do you mean standard
struts interfaces (i.e. abstracting the implmentation which can be
substituted with something else later) or standard in the sense of sun's
standard interfaces? Or even a combination of the two. Excuse my
incomprehension - we're not used to the heat we have here at the moment! ;)
> 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.
>
Yes. I probably came over a little strongly on this point earlier. Apologies
:)
>
> 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.
>
Good point.
> (IMHO, the bad practice is implementing a security scheme that allows
> group and principal names to overlap.)
>
As I said before, I agree.
> Perhaps there could be an additional signature if someone needs to work
> around this, but there should still be one that accepts them together.
>
Another good suggestion.
> -Ted.
I still have a question about how we integrate with EJBs. I don't think we
should do anything that enforces those using struts as a front to EJBs to
have to implement their own security and it is not clear to me how we can
map our security to the container's to enforce declarative security at the
EJB level if we go with the Turbine idea of having a completely different
repository for security info. Perhaps this is in some ways container
specific, as the specs don't seem to say much about how the security context
gets propagated, just that it does, but it is a pain in the proverbial with
BEA WLS (as is anything security wise it seems ;).
Thanks for your comments Ted and apologies once again if I came across a
little to strongly!
Nic
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
