anonymous wrote : <s:secure> is gone, it's been replaced with EL expressions s:hasRole and s:hasPermission. Does this mean that the "view" will also have servlet container security enabled on it? In my own Seam application I've places only the controller Seam BBs within a security domain. Thus these components can use the @RolesAllowed stuff. I'm using a servlet filter to push the session credentials to the client-login JAAS context. My view has no servlet container security enabled on it, but it can access the current used via #{currentUser} if needed for view purposes only, since that's the only task of the view (SoC). For this I used a simple Tomcat valve configured via context.xml. IMHO the view should not have security enabled on it, since it can only expose data or perform operations via the controller components. Thus placing the controller components inside a security domain does the trick. Servlet container security doesn't bring anything in case of an MVC framework like Seam. And, since Seam 1.1 we can have a nice error page in case of an RBAC exception, thus the view does not need to get access to the RBAC itself. This is also in line with another security aspect: input validation. Via the Hibernate annotations, they've also made the view "dumb" as it comes to input validation. Anyone has opinion on this? Can anyone already shed some light on which direction this is going to take? At JavaPolis someone of JBoss said they where going to use a rules thingy for the Seam security... KISS please... we already have a security system via EJB3, one should be enough. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994418#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...