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.
> 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.
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
problem here is that how the container gets the principals and
credentials is still implementation-dependant.
>
> 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
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.
-Ted.
