A good overview of JAAS authorization is provided on Sun's web site . At a high level, JAAS authorization leverages:
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);
The
RdbmsPolicy
implements
java.security.Policy
. It leverages the
PermissionManager
to get the permissions associated with a given
Subject
principals.
pms.getPermissions(user.getPrincipals());
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.
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".