I was in charge of implementing application security last year and I think 2EE security model is rather weak.
Where we work we support it but we also use JGuard because of some limitations of the standard model. Usually, the main complains about container-based security are : 1) The form authenfication allows just one general error page without any possibility for customization. Actually, you can't tell what the actual error is and that not very user oriented, 2) Impossible to call the login page directly or embedd it in the application layout (like in a sidebar). 3) Depending of the container used, it can be quite hard to have some pre and post authentification-treatment, wich can be quite important. 4) JEE security is quite static in that it doesn't allow to dynamically add roles or remove users from roles. 5) No standard model defined for the authentification process, but at least most containers use a JAAS-based approach. 6) Adding an identification model (collecting user credentials), like SSO, is not a standardised operation. For example, in Tomcat, I think you have to define a new Authenticator.. 7) No standard way to log off the user. Most containers just need the session to be invalidated but it's quite weird since all the secury-related methods are in the request object. By the way, having those methods in the request can lead to some problems with JSF since most of the times you will want to store the values in a session-scoped bean that can't refer request-scoped values. Well that most of it. I hope it is clear and will give you some pointers because security implementation can be perilous at first in the JEE world. Sorry to publish those informations on the Struts list but I don't want people to find all those *surprises* during the actual development like I did. On 12/30/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Hi bib, > > This isn't a Struts question strictly speaking, but I think I can > help... although I don't have a working example you can look at, I can > answer the second part... > > Container-based security is an "intercept" model, meaning you make a > request for a constrained resource, and doing so causes the request to > be redirected to j_security_servlet. Once the user is authorized, the > original request continues. > > So, let's say you have a welcome page defined in web.xml named > index.jsp. This welcome page immediately redirects to /loadApp.do, the > typical Struts bootstrap model. Maybe /loadApp.do maps to a forward, or > maybe to an Action, it doesn't really matter. The point is, it is meant > to be the *real* starting entry point of your application. > > Now, lets say you configure a constraint on /loadApp.do. (or just *.do > maybe). What happens is that the welcome page is hit, which forwards to > /loadApp.do, which is intercepted by the container, since it is > constrained. Your defined logon page is shown, where your > authentication form is. When the user submits the form, assuming the > user is authorized, the container forwards to /loadApp.do, effectively > continuing the original request. > > I think it is worth noting, because I've seen many people get it wrong, > that this security model is based on the idea of constraining resources. > The important point is that any resource not specifically covered by a > constraint IS UNCONSTRAINED. Remember, a server's job is to serve, and > you have to go out of your way to make it not do that :) > > You may be wondering "what if I want to constrain all resources in the > app and allow the user to come in anywhere"? Well, you can certainly do > that, and you will get your logon page like you expect, but is the > original request URI valid? This is really out of the realm of > security, its something you need to deal with in your application. In > my shop, we have a whole security framework built on top of J2EE > security for dealing with this, and numerous other, issues. We have a > series of filters that looks at the request for specific values (some > from session too). For instance, we can detect, by virtue of a value in > session that is only set in that "real" entry point, that a request for > another URI needs to be redirected to that entry point. This means you > really can't bookmark inside our applications, which is OK for what we > build 99% of the time, but we *can* be sure the user will go through the > main entry point, even if they try and avoid it. > > Hope that helps! > > Frank > > bib_lucene bib wrote: > > Hi All > > > > I am trying to work with role based permissions using tomcat container > > based Authentication. > > > > I am using JDBCRealm and Form Based Authentication. > > > > Problems: > > a) I did not find a good working example (like a .war file that I can > > readily deploy ) and see. > > b) In my struts application how can I specify upon successfull login what > > page it should it go. As action is j_security_check I do not know how to > > specify the next page. > > > > > > Can someone please help me on this. I am stuck on this for a long time. > > > > Thanks > > bib > > > > > > --------------------------------- > > Yahoo! Shopping > > Find Great Deals on Holiday Gifts at Yahoo! Shopping > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > AIM: fzammetti > Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexandre Poitras Québec, Canada --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
