Sunday, 20 November 2011


  For my latest task I’ve been looking into re-implementing the persistence layer of Liferay permissions to authenticate users and obtain authorization data from a client identity and access management engine. In the process I thought I’d explain a little bit about the details of Liferay permissions and in this first post more specifically the PermissionChecker. How it’s implemented and where the integration points are.

So how does the portal determine what permissions to grant each user? In Liferay, permissions can be associated with a user in a few different ways. The permission can be assigned directly to a user or it can be inherited through the hierarchy of groups (with the assigned permission of course) that the user belongs to. Permissions can also be assigned to a role which then passes it on to whichever user or group has that role. Yes, quite verbose but very powerful. The PermissionChecker is where all this heavy lifting occurs and where we actually determine whether a user “has permissions” to perform certain actions. A PermissionChecker is created or borrowed from a pool and placed in the thread local and themeDisplay object on every request.
The implementation can be swapped out for your own class by extending and overriding the necessary methods to implement your own functionality. Remember to specify your class name in for the property permissions.checker.
Now let’s look at an example of how the PermissionChecker is used in a simple case where we want to add a new page to a community layout set. We start this explanation from within the Communities Portlet lifecycle.  We’re adding a new layout to the layout set of a Community group so a process action request gets served by EditPagesAction which is just a struts action class. The first thing that happens is a check permissions call which uses the PermissionChecker to determine whether the user has the rights to perform the action MANAGE_LAYOUTS on targeted layout set of the community group. You will see permission checks like this all over Liferay’s view and service layer classes whenever we try to perform an action on a portal object. An example of what this check might look like:

GroupPermissionUtil.contains(permissionChecker,group.getGroupId(), ActionKeys.MANAGE_LAYOUTS)

As mentioned earlier, a user can inherit a permission from a hierarchy of groups that the user belongs to or a role that is directly or indirectly associated with the user. This hierarchical complexity is handled by a class within the PermissionChecker called the PermissionCheckerBag. So what’s in the bag? On first call to perform an action the bag is actually empty (null to be technically correct). Based off the user id we grab all the Organizations and UserGroups that the user belongs to along with the corresponding Groups since all these “containers” are also represented as Groups. We also obtain and throw in the roles as well. You can think of the PermissionCheckerBag as a container for all the user’s Group and Role associations per community and also contains helper (permission shortcut) methods that determine whether a user is a community owner or admin. This object is stored for the remainder of the request and discarded when the PermissionChecker is returned to the pool. (For performance reasons we should cache this object for the entire user session. This issue is now This class can also be extended as the implementation class is only used in PermissionChecker.
Now that we have the PermissionCheckerBag inside the PermissionChecker we are ready for the next step of the process, checking the bag's groups and roles for the permission to perform the action MANAGE_LAYOUTS. As with all service calls in Liferay this one begins with a *ServiceUtil helper class, in this case PermissionServiceUtil which is used to obtain the proper service via Spring. This service class can be easily swapped out in portal-spring.xml if so desired. The utility uses PermissionServiceFactory to get the PermissionService bean and its default implementation com.liferay.portal.service.impl.PermissionServiceImpl or a class that you implement yourself. In our example for adding a layout to the community layout set we first need to start by getting a list of resources scoped for Individual, Group, Group Template and Company through another service helper ResourceLocalServiceUtil (lets leave this service alone unless you are planning to offload resource management to another datastore). Resources identify the target object that you are trying to “MANAGE_LAYOUTS” on. Now with this list of resources and the PermissionCheckerBag we can do a check for the permissions we are looking for. The actual call looks like this:

PermissionLocalServiceUtil.hasUserPermissions(user.getUserId(), groupId, actionId, resourceIds, bag)

This PermissionService contains the bulk of the logic for Liferay permissions and brings together all the data gathered up to this point to perform the required queries. This call is made from the PermissionChecker and can also be customized to implement your own authorization logic if required. Again, just swap out the service implementation.
Let’s look at some of the SQL calls used to figure out permissions for a user to add a layout. First we want to find all the Permissions for the action we are performing on the resource.

SELECT {Permission_.*} FROM Permission_ WHERE (actionId = ?) AND (resourceId = ? OR resourceId = ? OR resourceId = ? OR resourceId = ?)  

Once we have all the Permissions for the action and resource we want to check to see if any of the user associations either directly or inherently has the permission. We do this via the PermissionFinder which is helper class for performing custom SQL calls for permissions. The PermissionFinder performs a custom SQL based on the permissions.user.check.algorithm specified in and returns true if the user has an association to the permission. Of course these SQL calls are made once before they are cached in the portal for subsequent requests.
So there you have it. PermissionChecker Explained. In case anyone was wondering.

Contributed by

1 comment: