2 Replies Latest reply on Sep 19, 2003 9:02 AM by pharaohh

    JAAS Dynamic Policies

    pharaohh

      An application that I'm working on requires dynamically associating Permissions to roles during runtime.

      Example.

      Lets say we have two roles, one called "admin_level_1" and another called "admin_level_2".

      All admin_level_2's can create a user account, but
      admin_level_1's can only edit them (not create them).

      Now lets say that we don't care which administrators create user accounts...all of them should be able to.

      I want to be able to visit a web page, and (under the hood, in a servlet) designate that admin_level_1's now have the "create" action of the my.domain.UserAccountPermission.

      We store the users to roles and roles to permissions mappings in the database. So, in time sequence, the following should be possible without restart of the server or redeploy of the ear:

      admin_level_1 tries to create an account --> failure
      admin_level_2 gives admin_level_1 user account create permission.
      admin_level_1 tries to create an account --> success.

      All this should happen in realtime, without admin_level_1 having to log out and log back in to acquire the new permissions.

      Can JAAS in a J2EE environement support such dynamic requirements and dynamic ACLs?

      I've _thoroughly_ read all the purchased JBoss docos as well as nearly every Google resource I could find, and things are very vague when it comes to addressing dynamic policies in a J2EE environment.

      It seems that dynamic Policies are not supported in J2EE, or perhaps, not by JBoss.

      If they are, how can I tell JBoss to use this dynamic policy implementation (which would go to the database, instead of say, a JAAS policy file)? Can I do this without messing with the system SecurityManager?

      Can anyone help clarify this issue?

      Thanks so much,

      Les

        • 1. Re: JAAS Dynamic Policies
          jkressin

          Hi,

          I cannot give you an out - of - the - box solution, but I was messing with authentication / authorization issues in combination with servlets myself, so maybe I can give you some hints.

          First of all, there is a rather straight - forward article on JAAS - based authorization / authentication in combination with struts on theserverside:
          http://www.theserverside.com//resources/articles/JAAS/article.html
          I would recommend to read it. The article is based on struts, but the general techniques can be applied to any servlet, filter etc.

          Second, I think you cannot really avoid working with the SecurityManager, invoked indirectly by Subject.doAsPrivileged. I was able to make a working example with JBoss LoginModules and authorization based on a JAAS - policy - file and the standard JAAS authorization methods.
          If you do not want to work with policy files, you can implement your own policy provider which is responsible for reading the principals permissions. Quote from the article:

          'Note: Example 8 is an example of a file based implementation of the policy. It canbe replaced with a RDBMS implementation by changing the value of the auth.policy.provider variable in the java.security file.'

          But I have not tried that myself, so I cannot give you more details on this specific issue.

          hope it helped,

          Jochen

          • 2. Re: JAAS Dynamic Policies
            pharaohh

            Jochen,

            Thanks very much for the reply.

            I've read the article to which you refer many times, as I'm using Struts ;)

            I'm aware that I can change the policy provider as a command line argument to java (by editing the run.sh file in the $JBOSS_HOME/bin directory). The problem that I have with that, is it bypasses the JBoss configuration for JAAS.

            I was hoping JBoss (or any other J2EE server) would have some sort of hook that allowed a developer to specify a dynamic policy implementation. This would allow developers/deployers to specify that information in a jboss.xml file in an ear, deploy, and have everything work.

            The approach you recommend does not allow pure ear-based deployment...you have to mess with JBoss internals (run.sh) before even starting up the server. That just adds to configuration issues for every machine I have to deploy to, which I _really_ want to avoid if possible.

            Anyone know if there is a solution out there?

            Les