----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 30, 2001 3:31 PM
Subject: Re: Role-based security
> Ted Husted wrote:
> > 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.
>
> Nic Hobbs wrote:
> > 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!
;)
>
> Standard in the sense of the Sun interfaces the containers are expected
> to use.
>
> I'm just thinking that we may be able to implement a finer grained use
> of the Sun security package within the application layer. And if we are
> careful, and the container-based implementations catch up with us later,
> switching back may not be problematic.
>
Sounds good.
> > 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 ;).
>
> +1.
>
> This would be an optional package. The idea is that if a Struts
> component calls the equivalent of userInRole(), and container-based
> security is being used, then they get the container-based answer.
>
But does this make it all or nothing? Either I use the struts security and
have to write my own EJB security or I use the EJB declarative security and
have to rely on the container stuff or write my own? I don't know whether
there is a way to harness both...
> Likewise, if application-based security is being used, they would get
> the same answer (at least at first), but using Principal and Group and
> Permission objects that the application has stored (instead of the
> container).
>
> Configuring the application would still differ based on whether the
> developer choose to use the container or the application, but we could
> extend Struts-config to accept the same type of security parameters you
> can put into the web.xml.
>
> Tomcat supports specifying a JDBC:DBMS table for storing the principals,
> credentials, and roles. We could build on that and provide better
> support for groups and permissions (a la Turbine), without worrying
> about whether a given container supported the same mechanism (yet). The
As long as we don't rely on anything specfic to Tomcat i.e. make it generic,
this would seem like a good approach to take. I will do some thinking in
this area.
> problem here is that how the container gets the principals and
> credentials is still implementation-dependant.
>
Too true.
> >
> > Thanks for your comments Ted and apologies once again if I came across a
> > little to strongly!
>
> If anyone here was coming across too strongly, it was probably me. ;-0
>
Not at all.
> I just wanted to point-out that product development at Jakarta is about
> individual developers doing what works for their own projects and
> sharing it with the group. Lately, it seems like some people are trying
> to frame work around the TODO list, rather than looking the TODO list to
> see if anything there can be taken from their own work, or made part of
> their project. But maybe that's just me. Individual mileage may differ.
>
Although you're probably right, and I myself am probably guilty, IMHO I
don't think it should be exclusively for people who have done things on
their own projects. If 'users' see something they need they may suggest it
and it may end up on the TODO but if no-one develops it on their own project
it will never get done under that scenario and the project will be the
weaker for it. I think there is a middle way, which is probably what we are
finding here - that a suggestion on the TODO has lead us to find out that we
probably require something slightly different that we will probably have to
start from scratch (apart from ideas from Turbine etc.) rather than have
donated by someone who has already done it. I don't consider this a bad
thing...
Just my ha'penny's worth!
Nic
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
