Page Comparison

...

Liferay has a chain of authenticators. When you enter your username/password, the chain of authenticators are invoked. This is the place where we plugged in the 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 authenticatorindicates that once the authenticator is loaded, do not invoke the rest in the chain. Otherwise, the default Liferay authenticator will is also get invoked. Third entry points to the AuthenticationAdmin service running in WSO2 Identity Server.

Now, the username /password go in to and password goes into the WSO2ISAuthenticator and it will talk to communicates with WSO2 Identity Server over SOAP to authenticate the user. Once authentication is done, the control is once again will be passed in to into the Liferay container.

Now is the tricky part. Liferay has it's own permission model - who should be able to see portlets, who should be able to add portlets likewisewhich enables you to view or add portlets depending on your permissions. For this, it needs to find which Liferay roles are attached to the logged in user or which Liferay roles are attached to any group the logged in user belongs to. To get these details, it needs to talk to communicate with the underlying persistence layer - which will load loads details from Liferay's underlying database. This is why we wanted it is useful to have users imported here from the LDAP.

Even - though it 's is possible, we it was decided not to write a persistence layer - but only to override authentication and authorization as that is sufficient for this scenario.

Even in the case of authorization - ; there are two types. The authorization model governed by Liferay to display/add portlets to the portal. The authorization model used within the Portlet it self itself to display content within the portlet.

...