Since many of the old J2EE techniques and patterns are no longer applicable with Seam/JSF/EJB3/etc., I'm curious about what folks are doing for application permissions.
BTW, I'm not referring to login security, but rather to the use of permissions to control access to parts of the application (and provide error messages indicating the missing permission). Most app servers implement a two-level system of users and groups. However, this doesn't fit my personal view of an application. In my model, you have a fixed set of Permissions that are required to either access particular pages or enable pieces of functionality within a page. Users and Roles (a.k.a. Groups) are business entities defined and managed by the application's administrator(s). That is, Users have one or more Roles, and Roles are a grouping of permissions that can change daily as the business needs change (now we need the AccountManager role to be able to XYZ). To be clear, I don't want ANY hard-coded (or configured in XML) Roles, as those are defined by the changing needs of the business. I've never had much luck using the app server's permission logic, for a couple of reasons: 1. My Permissions equate to the app server's Groups, creating a logical mismatch. 2. There is not always a clear entry point for the app server to control. That is, I don't want to control access to EJBs or methods, it's really the logical entity of a page that I want to control. More to the point, I hate configuring security in my web.xml file. This is where I get mixed up about where to start in this brave new world of JSF and Seam. In my Struts confort zone, I implemented the permission check in my base Struts action. Each logical page consisted of an Action/JSP pair, and this made it simple to control at the entry point. Now, in the world of listeners, I've lost my equilibrium. I don't have a clear entry point for a page, because I don't have a good feel for what the "logical page" consists of. I could control access at the JSP level, but that seems to mean that the server side code will execute even if the user doesn't have permission, and I'd be blocking access to the view itself. Argh - I'm sure there's a simple solution: I just don't have solid ground underfoot right now. This seems like a job for Interceptor Man! But again, what am I intercepting, and how to I implement it? Aside from hardcoded permission checks within a page implementation (e.g. show the delete button if they have permission), I prefer to store the mapping of "pages" to "permissions" in the database. That gives me the most flexibility in terms of redefining dynamic behavior [for example, allowing particular customers to define their own permission mappings, or perhaps add to a fixed set]. Any ideas out of all of this rambling? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964380#3964380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964380 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
