...
One of the challenges you may face in this integration is the LDAP Users/Groups import. You can connect an LDAP to the Liferay. However, however, to authenticate users to Liferay against the underlying LDAP, it has to import all the users and groups to Liferay's underlying database, which is by default running on Hypersonic.
Since , we you only need to keep the user data in a single LDAP, we wanted to you can avoid this duplication. However, it was not as easy as we thought. If you need to avoid that, then we this is not straightforward as you need to write the complete persistence layer. To understand this better, I guess I need to elaborate more this. Let's take a step back and see how in fact Authentication and Authorization work in Liferay.
Liferay has a chain of authenticators. When you enter your username/password, the chain of authenticators will get are invoked. This is the place where we plugged in WSO2ISAuthenticator.
| Panel |
|---|
auth.pipeline.pre=org.wso2.liferay.is.authenticator.WSO2ISAuthenticator |
The above configuration (which should be in the liferay_home/tomcat/webapps/ROOT/WEB-INF/classes/portal-ext.properties file) tells Liferay to load our custom authenticator. Also, the second entry says, once loaded our authenticator, do not invoke rest in the chain. Otherwise, the default Liferay authenticator will also get invoked. Third entry points to the AuthenticationAdmin service running in WSO2 Identity Server.
...
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 the portal administration side - and much specific to Liferay. But - the second model - is the one that directly deals with the business functions. That is what we wanted to do in a find-grained manner.Let's dig more deep in to this...
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 disadvantages are..
...