9 Replies Latest reply on Jul 24, 2006 12:02 PM by Anil Saldanha

    Authorization framework

    Anil Saldanha Master

      With JACC being the only J2EE spec mandated support for authorization and the emergence of standards like XACML and WS-Policy that deal with various aspects of Authorization and the ever growing needs for authorization with the various JEMS technologies, I am thinking a Policy based pluggable authorization framework may be worth trying out.

      It will give the users the opportunity to plug in authorization providers based on jacc, xacml, ws-policy etc to cater to the needs to provide authorization much more advanced than those provided by J2EE Security.

      Thoughts/Comments on this?


      Some examples of where J2ee authorization is inadequate are:
      a) Portal needs to secure resources that do not conform to the web.xml semantics.
      b) Want to secure resources on a time basis - 9 to 5, business days etc. [Semantic built into xacml]
      c) JACC requires mapping all authorization decisions to java permissions which can be complex and non-intuitive.

      An interesting image of the authorization world in WSphere.
      http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1//topic/com.ibm.websphere.base.doc/info/aes/ae/images%5Cauthz.gif

        • 1. Re: Policy Abstraction framework
          Paul Andrews Newbie

          I'm in the early stages of designing a security framework for an app that, amongst other things, uses JBoss. Whilst authentication seems to be pretty much pegged these days I remain continually annoyed that authorization is still left to application developers to implement.

          I guess I should clarify that: EJB defines a class method authorization mechanism and J2EE defines a resource-based authorization mechanism. In my experience, they both just get used to enforce acess to the application as a whole, rather than anything finer-grained.

          Yesterday I read an article that stated that what we all need is an authorization mechanism that allows you to specify access controls on instances too (in the context of EJBs that is). They then gave an example similar to the following: An account holder can withdraw funds from an account only if it is their account and the account holds sufficient funds. So something like:

          account.withdraw(200)

          You could write an authorization rule something like:
          account.owner == securityContext.subject.name &&
          account.balance > requestedAction.args['amount'] &&
          requestedAction.name == withdraw &&
          targetObjectType == 'Account'

          Leaving aside the question as to whether or not this is a business rule or an authorization rule I think there are several things to note about it:

          1. The rule uses arbitrary information from the target object.
          2. It also uses information from the requested action.
          3. It uses information from the securityContext.

            I could probably add that it might also use information from the 'environment', e.g. time-of-day (can you tell I've been indoctrinated by XACML?).

            So, generalizing from this one example (!) it would seem that those four things would need to be made available to a policy decision point - at least for EJB method access!

            The authorization rule itself obviously doesn't fit with how authorization rules are currently specified for EJBs - in fact I would like to remove authorization data from the deployment descriptors anyhow. I believe that such information belongs in a company-wide repository with all of the other company authorization data. This does kind of beg the following questions though:

            1. How does an application define for the repository and the admins the set of actions and resources it supports (i.e. the vocabulary of verbs and nouns that can be used in authorization rules)?
            2. How does the initial set of rules get provisioned to the repository?

              Maybe these aren't anything to do with the JBoss server, as such, but they are something a developer should have tools to help with. Furthermore I would like that the regular EJB authorization mechanism be supported in the same manner - so if a developer chooses to use the standard EJB authorization declarations, I would like that those rules be populated into a company repository and then accessed from there by the JBoss framework (i.e. by an interceptor that I provide).

              As for how the decision is requested and enforced: I was thinking of using AOP to intercept method calls. This would require that the Advice/Pointcut could gain access to the security context and the 'environment'. More traditionally I could provide an interceptor that fits into some general interceptor framework. However I would like to be able to use this mechanism in the brave new world of EJB3 and access to POJOs too.

              I might also use annotations as a way marking pointcut targets and/or attributes of the targets that can be used in an authorization decision. This might assist in providing a possible vocabulary to the authorization engine.


          • 2. Re: Policy Abstraction framework
            Anil Saldanha Master

            There will be a discussion on the new authorization framework at the JBoss World Presentation in Las Vegas next week. I am guessing that it will take care of your concerns.

            Here are the slides from JBW, Las Vegas. Try to make it to the next JBW in Europe.
            http://jbossworld.com/core.htm
            http://jbossworld.com/core_infrastructure/SALDHANA_JBossSecurityForJEMS.pdf

            • 3. Re: Policy Abstraction framework
              chris griffith Expert

              dear gang,

              I wish I could have been at JBW LV to hear this presentation. Even though I have not, your discussion, judge2005, has prompted me to respond with my thoughts.

              Your comment...


              Leaving aside the question as to whether or not this is a business rule or an authorization rule I think there are several things to note about it.

              unfortunately can not be left aside. As I see it, these are business rules, not authorization rules. If I were an EJB, and some object A has requested access to my method, I have to ask, do you object A have the right to access my method. That is subject based authorization. Meaning, I am making my access decision on who you (object A) are. If I choose to not let object A access my method because it is past noon(and I am at luch :)) , then that is a business rule.

              That said, I do believe that there is a great need to be able to plug in rules like those you have mentioned to restrict access. However, I am just saying that I do not think they belong in the JAAS/JACC specs because those specifications are to authenticate/authorize subjects to resources.

              I look forward to any futher discussion. Thanks, cgriffith

              • 4. Re: Authorization framework
                Anil Saldanha Master

                Scott, could you give a glance at the following combination of module behavior and assert that the results derived are correct.

                /**
                 * Test the AuthorizationModules combination behavior
                 */
                 public void testCombinationBehavior() throws Exception
                 {
                 assertNotNull("PolicyConfig != null", policyConfig);
                
                 int result = getResult("required-deny-sufficient-permit-policy");
                 assertTrue("DENY?", AuthorizationContext.DENY == result);
                
                 result = getResult("required-permit-sufficient-deny-policy");
                 assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
                
                 result = getResult("required-permit-required-deny-policy");
                 assertTrue("DENY?", AuthorizationContext.DENY == result);
                
                 result = getResult("required-permit-required-permit-policy");
                 assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
                
                 result = getResult("required-permit-required-permit-sufficient-deny-policy");
                 assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
                
                 result = getResult("required-permit-required-permit-requisite-deny-policy");
                 assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
                
                 result = getResult("required-permit-required-permit-optional-deny-policy");
                 assertTrue("PERMIT?", AuthorizationContext.PERMIT == result)
                
                 result = getResult("required-permit-required-deny-requisite-permit-policy");
                 assertTrue("DENY?", AuthorizationContext.DENY == result);
                
                 result = getResult("requisite-permit-requisite-permit-sufficient-deny-policy");
                 assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
                 }
                


                The combination of the module control flag can be derived from the name.

                For example:
                <jbsx:application-policy name="requisite-permit-requisite-permit-sufficient-deny-policy">
                 <jbsx:authorization>
                 <jbsx:policy-module code="org.jboss.security.authorization.modules.AllPermitAuthorizationModule" flag="requisite" />
                 <jbsx:policy-module code="org.jboss.security.authorization.modules.AllPermitAuthorizationModule" flag="requisite" />
                 <jbsx:policy-module code="org.jboss.security.authorization.modules.AllDenyAuthorizationModule" flag="sufficient" />
                 </jbsx:authorization>
                 </jbsx:application-policy>
                

                Here two modules (requisite) permit and one module(sufficient) denies. The overall decision should be PERMIT.

                Since the combination of the module control flag can be a large space, I cannot completely test all the combinations.

                Can you think of any complex combinations that may be crucial?

                • 5. Re: Authorization framework
                  Scott Stark Master

                  For reference, the jaas definitions of the control flag:


                  1) Required - The LoginModule is required to succeed.
                  If it succeeds or fails, authentication still continues
                  to proceed down the LoginModule list.

                  2) Requisite - The LoginModule is required to succeed.
                  If it succeeds, authentication continues down the
                  LoginModule list. If it fails,
                  control immediately returns to the application
                  (authentication does not proceed down the
                  LoginModule list).

                  3) Sufficient - The LoginModule is not required to
                  succeed. If it does succeed, control immediately
                  returns to the application (authentication does not
                  proceed down the LoginModule list).
                  If it fails, authentication continues down the
                  LoginModule list.

                  4) Optional - The LoginModule is not required to
                  succeed. If it succeeds or fails,
                  authentication still continues to proceed down the
                  LoginModule list.


                  Those tests results look correct. We need to test with sufficient at the start:

                   result = getResult("sufficient-permit-required-deny-policy");
                   assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
                   result = getResult("sufficient-permit-sufficient-deny-policy");
                   assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
                   result = getResult("optional-deny-sufficient-permit-required-deny-policy");
                   assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
                  


                  and that if nothing deterministically succeeds that we deny:
                   result = getResult("sufficient-deny-optional-deny-policy");
                   assertTrue("DENY?", AuthorizationContext.DENY == result);
                  



                  • 6. Re: Authorization framework
                    Anil Saldanha Master

                    This has been added to the testcase that drove the culmination of this important JIRA feature request:
                    http://jira.jboss.com/jira/browse/JBAS-3324

                    • 7. Re: Authorization framework
                      Anil Saldanha Master

                      For the web layer, currently we have multiple JBoss realms namely JBossSecurityMgrRealm, JaccAuthorizationRealm (maybe more in future??) that have a variance in how they do authorization only.

                      I would like to unify these realms into a single realm called as JBossRealm in which the authorization decisions for (hasResourcePermission, hasRole and hasUserDataPermission) will be delegated to the authorization framework(Authorization Modules that do default web behavior, jacc behavior, xacml behavior or custom authz behavior will drive the decision).

                      To this end, I am planning to define a separate security domain for the realm (not to mix with the application defined realm). The authentication process still happens based on the app specified security domain, via the security manager obtained through the jndi binding.

                      This separate security domain will have the authorization module that defines the default tomcat authorization logic (replacable with a module that does jacc).

                      Questions:
                      1) Any issues in unification of the realm?
                      2) Will the separate security domain confuse the user? If not, we will have to force them to add the default web authorization module to their security domain.
                      3) Is it better to upgrade the JBossSecurityMgrRealm to use the authorization framework (and deprecate the JaccAuthorizationRealm)?

                      • 8. Re: Authorization framework
                        Anil Saldanha Master

                        I have a new realm called as JBossWebRealm that unifies the two realms (JBossSecurityMgrRealm and JaccAuthorizationRealm) plus makes the callout to the Authorization Framework for the authorization decisions.

                        A default WebAuthorizationModule (always authorizes because the RealmBase makes the final decision) and a JaccAuthorizationModuleDelegate for the web layer does the jacc decisions.

                        This is on test run with the jacc suite of tests.

                        Need feedback:
                        Currently the Application Policy can contain (mandatory authentication info and optional authorization info) as defined in the security_config_5_0.xsd.

                        I am wondering if the authentication info should also be made optional and require that atleast one auth or authorization info is always present.

                        Does it make sense to define an applicaiton policy(security domain) with just authorization context and no authenticaion context?

                        • 9. Re: Authorization framework
                          Anil Saldanha Master

                          Latest Questions:

                          1) Shall we retire the old custom Sun parser parsed login-config.xml in the conf directory to a JBossXB based login-config.xml (security_config_5_0.xsd)?

                          2) Should we update the 5.0 schema such that there is always atleast an authentication element or an authorization element? Currently, we have mandatory authentication element, with an optional authorization element.