Overview of JAAS Authorization

A good overview of JAAS authorization is provided on Sun's web site . At a high level, JAAS authorization leverages:

  • Permission that associates actions to resources.
  • Principal that represents an entity in the system. In Jetspeed 2, 3 principals are used to represent users, roles and groups.
  • Policy that associates principals to permissions.

Jetspeed 2 provides a custom policy implemention that allow the portal to secure resources as follow:

                    
grant principal o.a.j.security.UserPrincipal "theUserPrincipal" {
  permission o.a.j.security.PagePermission "mypage", "view";
  permission o.a.j.security.PortletPermission "myportlet", "view,edit,minimize,maximize";
  permission o.a.j.security.TabPermission "mytab", "view";
};

grant principal o.a.j.security.RolePrincipal "theRolePrincipal" {
  permission o.a.j.security.PagePermission "mypage", "view";
  permission o.a.j.security.PortletPermission "myportlet", "view,edit,minimize,maximize";
  permission o.a.j.security.TabPermission "mytab", "view";
};   

grant principal o.a.j.security.GroupPrincipal "theGroupPrincipal" {
  permission o.a.j.security.PagePermission "mypage", "view";
  permission o.a.j.security.PortletPermission "myportlet", "view,edit,minimize,maximize";
  permission o.a.j.security.TabPermission "mytab", "view";
};
                

The custom security policy provides a java.security.Policy implementation that stores the association between principals and permissions in a relational database as opposed to leveraging the default JDK policy. In the case of Sun's JDK, the default policy is sun.security.provider.PolicyFile a file based policy.

In the code sample above, the UserPrincipal identify with the Principal.getName() "theUserPrincipal" has permission to "view" the page called "mypage", to "view,edit,minimize,maximize" the portlet portlet called "myportlet"

The AccessController validates a Subject permissions. For instance, a page permission check would perform the following check:

                    
PagePermission permission = new PagePermission(path, actions);
AccessController.checkPermission(permission);                
                
                

Jetspeed JAAS Policy

The RdbmsPolicy implements java.security.Policy . It leverages the PermissionManager to get the permissions associated with a given Subject principals.

                    
pms.getPermissions(user.getPrincipals());
                
                
The class diagram below illustrate the association between the RdbmsPolicy and the PermissionManager .

A good article on custom policies implementation is available on IBM web site .

To get more detail about the implementation of the PermissionManager , see PermissionManager Overview .

Note: The current RdbmsPolicy manages the policies to apply. It applies RdbmsPolicy in conjunction with the default policy configured in the runtime environment. Jetspeed 2 should explore providing JACC adapters for its custom policy for specific application servers.

Authorization Provider and Policy Configuration

The AuthorizationProvider configures the authorization policies to be used by Jetspeed 2 and keeps the list of such policies in the SecurityPolicies singleton. The RdbmsPolicy when getting the permissions for access control will execute its policy as well as all the policies configured in SecurityPolicies . If the AuthorizationProvider was constructed with useDefaultPolicy set to true, the default JDK or application server policy will be applied when getting the permissions.

Note: The RbmsPolicy permission check is concerned about the principals associated to the Subject, therefore where performing an access control check, the check should be performed with the following call: doAsPrivileged(theSubject, anAction, null). By passing a null AccessContolContext, the caller is essentially saying: "I don't care who called me, the only important thing is whether I have permission when associated with the given subject".