Nic Hobbs wrote:
> 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...
The declarative security is going to have the "right of first refusal".
But once you are past that, I'd say there is still room for
finer-grained
programtic security. Here, I'm thinking in terms of the
HttpServletRequeset interface -- I'm not sure where bean-managed
security would fit in this this, or whether it even should.
Anyway, I'm just thinking that if we are going to start breathing
role-based security into the tags and the mappings, is there a way
we can hedge our bets, and call a method from the servlet, or an
application object, rather than call request.isUserInRole() directly.
If container-based security were in place, it could start out as a
wrapper for the HttpServletRequest calls. But if you wanted to extend
that so it made the standard call and then did something else before
returning the final answer you could. Meanwhile, if you wanted to keep
the container out of it, maybe the servlet could keep its own objects
in the session, and use those for servlet.isUserInRole() (and friends)
instead.
> 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.
The Tomcat JDBC Realm approach is fairly generic already.
< http://jakarta.apache.org/tomcat/tomcat-3.3-doc/JDBCRealm-howto.html >
For full cross-applications compatabilty, sign-ons it would probabaly
just be a matter of using the same constant for the single-sign-on
cookie. But that's a very low-level implementation detail.
< http://jakarta.apache.org/tomcat/tomcat-4.0-doc/singlesignon.html >
-Ted.
