Thanks for the info, Craig. It looks like SecurityFilter won't work with EJB apps, now or in the future, with current server implementations.
My feedback about what I find lacking in current container managed security are these items: 1) The inability to submit "unsolicited" login requests (when the container didn't force you to the login form) 2) Lack of a standard realm interface (though this is becoming a non-issue with JAAS, LDAP adapters, etc.) -Max ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > > Max, > > I'm very glad to hear that you've covered this issue in the docs already > ... it is a very obvious place that people might make mistaken > assumptions. However, I can't hold out much hope that you will be able to > find a portable solution to working for EJBs in the short term. > > The key problem you're facing is that you need to convince the container > to trust an application's assertions about security -- and that just isn't > going to fly in current generation containers, because it would lead to > a raft of security attacks by maliciously coded applications. (If we want > that kind of thing, we can just use .NET, thank you :-). I'm personally > adamant about Tomcat *never* trusting a user application for this kind of > thing, until there is a safe way to do so. I can't imagine that any other > app server would be any less stringent about managing something this > fundamental either. > > The current reality of J2EE security APIs is that there is no portable > mechanism to support several commonly-desired features (such as setting up > new users and auto-logging-in in a portal type environment). These sorts > of problems need to be solved at the container level, so that applications > don't need to worry about them. > > In my day-job role (at Sun) as the Web Layer Architect for the entire J2EE > platform, this is one of my priority concerns. Unfortunately, providing > the appropriate solution is going to take a while. In the mean time, > things like SecurityFilter serve a very valid need for non-EJB webapps, > and I'm happy to see that you've taken on the effort to provide a general > purpose solution in this problem space. > > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
