3 Replies Latest reply on Aug 22, 2006 5:31 PM by Pete Muir

    Application Permissions

    Todd Main Newbie

      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?

        • 1. Re: Application Permissions
          Pete Muir Master

          Permissions/Roles/Users

          Isn't this just a semantic mismatch? If you consider a JAAS role as a Permission, then have Group(s) of Permission(s) (JAAS roles), and place in a User in a group then IMO you have solved the mismatch.

          Hard-coding in web.xml

          It depends how you want to control access to views. I find more often than not that I want to control access to sections of view, not the whole thing (e.g. for a bog standard user don't display password reset control, display username but with no change permission, allow editing on email address). In this case you can use something like isUserInRole provided by Seam. You can of course deny or allow access to a view with this as well.

          The only security constraint I put in web.xml is that only authenticated users can access the 'secure' area - which then pops up a login for when they try to go there.

          You can of course use JAAS roles (Permissions) to allow/deny access at the method level as well.

          Solution?

          Define security in the view itself, and only render those components that can be seen by this user. Take a look at the JAAS example on the wiki, its a bit nasty to set up, but does work.

          Just my tuppence ha'penny's worth :)

          • 2. Re: Application Permissions
            milestone Newbie

             

            "petemuir" wrote:

            Isn't this just a semantic mismatch? If you consider a JAAS role as a Permission, then have Group(s) of Permission(s) (JAAS roles), and place in a User in a group then IMO you have solved the mismatch.


            Ok, so I have groups of roles, and groups of users, how would I define which user has which group of roles.

            Users, Groups and Roles are a loose coupling. They have nothing to do with each other. A User can have as many groups of roles in and be in as many groups as he wants to.



            • 3. Re: Application Permissions
              Pete Muir Master

              Well somewhere along the line you need to map the user to a permission (e.g. Peter is allowed to view the credit card details of all users). So we group the permission information somehow (e.g. credit-card-viewers are allowed to list the users of the system), this is the JAAS role. Then we think about users 'business roles' (e.g. Sales & Accounts, both of whom are allowed to view credit card details). Finally we assign users to business roles (e.g. Peter is the sales director so is a member of Sales and of Management Team).

              So, each user can be a member of a number of business roles. Each business role has an associated set of permissions (a permission can be assigned to multiple business roles), and permissions map directly to JAAS roles. The rest is SQL :)

              But I'm not sure I understand your requirement. Have you got an ER diagram that describes the relationship between Users, Groups and Roles?