Page Comparison

...

Even in the case of authorization; there are two types.

1. The authorization model governed by Liferay to display/add portlets to the portal.
2. The authorization model used within the Portlet itself to display content within the portlet.

The first type is done by assigning portlet management permissions to a given Liferay role and assigning members [(groups/users] ) to that role from the underlying LDAP. We did not want to do that . Because, that is very much on as that has more to do with the portal administration side - and as a result, much more specific to Liferay. But - However, the second model - is the one that directly deals with the business functions. That is what we wanted to do in a findIt was decided that this is a better option and it is used in a finn-grained manner.

Even the second model can be done with Liferay's roles and permission. Whenever you want to render something in the portlet that requires some restricted audience, then before rendering that you need to call req.isUserInRole("roleNme"). This is compliant with the JSR too. But The following are the disadvantages are..:

1. Our business functionalities in an SOA deployment should not be governed by Liferay roles. Liferay could only be a single channel to access the business functions.
2. We can achieve only the role based access control with this model.

Liferay, also has it's own way of permission checking, which is within a portlet via the PermissionChecker API. See here for further more details on the PermissionChecker.

Our approach was to write a utility function called hasPermission(). If you extend your portlet from org.wso2.liferay.xacml.connector.SecuredGenericPortlet then this is automatically available for to you. Alternatively you can directly call it through AuthzChecker.hasPermission(). These functions are available from the org.wso2.liferay.xacml.connector.jar file.

...