Where Liferay Fits In

Where Liferay Fits In

You may be wondering where Liferay fits into your existing ecosystem. The key thing to remember is this: Liferay is a Java web

application, running on a standard Java servlet container or application server. Since the choice of app server does not matter for IdM,

we will use Liferay on Apache Tomcat as an example.

Here is a typical Liferay installation:

Figure 1

In Figure 1, it is apparent that Liferay thrives in this ecosystem. In this example, Liferay is relying on its own authentication mechanism.

Here is a typical Liferay installation, with LDAP:

Figure 2

In Figure 2, Liferay is using LDAP as its one true source of authentication. The portal no longer relies on the user information in the

Liferay database but on the user credentials stored in the LDAP server. For Microsoft Active Directory, Figure 2 applies as well. In this

setup, the user ID and passwords are managed from the LDAP server along with the tools that are associated with it. Many organizations

either have a separate password reset or administration page or need to call their IT departments to reset or administer their password.

In either case, Liferay does not know anything about these tools. It simply binds to the LDAP server and verifies whether the user has

provided valid credentials in the portal.

LDAP Authentication

LDAP Import

Liferay

Database

LDAP

API

Database

Liferay

Authentication

By default, once authenticated and the user’s session is created, the user’s basic credentials (username, password, email address, first

name, last name, title) are all imported into the Liferay database in a one-way sync. This happens every time a user performs a login.

There is also the option to configure Liferay Portal to do a two-way sync (export). The two-way sync allows users to change their

information from within the portal and have it sync outwardly to the LDAP server. The synchronizations can happen real-time or be set

to a time interval. If you wish to have the LDAP server be the central point of administration, it is recommended that you do not turn on

the two-way sync, allowing the LDAP server to remain as the one true source of authentication at all times.

Here is a typical Liferay Installation, with SS O and LDAP:

Figure 3

In Figure 3, Liferay Portal is relying on the SS O server to broker the authentication, with LDAP storing the user data. Figure 3

demonstrates that even though the SS O server is responsible for authentication, that user’s identity is still stored in the LDAP server. The

SS O server will use one of a variety of authentication mechanisms. These include cookies, tokens, and agents. Whatever implementation

is used, the SS O server will simply authenticate and allow you a session. It will not give complete user identity to the portal. In Figure 3,

the user is authenticated by the SS O server, but after authentication, the user’s information is imported into the portal from LDAP. In this

sort of system, other applications can leverage your SS O server without requiring LDAP on those systems. In Figure 2, if you wanted to use LDAP as your central IdM server, this would require that all your web applications are able to connect to your LDAP server.