12 April, 2020

Liferay 7.3 compatibility matrix

Compatibility Matrix

Liferay's general policy is to test Liferay Portal CE against newer major releases of operating systems, open source app servers, browsers, and open source databases (we regularly update the bundled upstream libraries to fix bugs or take advantage of new features in the open source we depend on).
Nothing has been removed from the matrix, however a couple things have changed.  Liferay Portal 7.3 CE was tested extensively for use with the following Application/Database Servers:
Application Server
  • Tomcat 9.0
  • Wildfly 16.0 (Previously 11.0)
Database
  • HSQLDB 2 (only for demonstration, development, and testing)
  • MySQL 5.7, 8.0
  • MariaDB 10.2
  • PostgreSQL 11.2 (Previously 10)
JDK

  • IBM J9 JDK 8
  • Oracle JDK 8
  • Oracle JDK 11
  • All Java Technical Compatibility Kit (TCK) compliant builds of Java 11 and Java 8

Liferay 7.3

Lets have quick look how Liferay 7.3 looks. 





1) You would have docker ready image provided by liferay now

  docker run -it -p 8080:8080 liferay/portal:7.3.1-ga2

2) Dependency management improved
If some of you have used earlier version 7.0, 7.1 and 7.2 may aware that we had to add many compilation dependencies for liferay library it self which confusion got removed now and can be handle through single compile dependency which is really good.


compileOnly group: "com.liferay.portal", name: "release.portal.api", version: "7.3.1-ga2-3"


New Features


Liferay Portal CE 7.3 GA2 includes several new features mainly in Experience Management and some in Platform improvements.

Experience Management

We are continuing to empower designers and marketers to create user-friendly, beautiful and engaging experiences, without code freeing developers to focus on advanced interactive experiences through modern front-end tooling and APIs. Here are some of the new features you can find in this release.
Nesting layouts and more flexible layouts - The non technical users can now nest a layout into another one, and thus creating sophisticated page layouts using drag and drop. In GA1 the user could create horizontal layouts with multiple columns. But now it is possible to combine, split, nest, duplicate the layouts and thus unleashing the users’ creativity.
More info: LPS-102328


Workflows for Content Pages - Users can now define a workflow process for approval of creation and changes for content pages.  Just like for Web Content articles and other content types, administrators can specify a different workflow process at different levels: virtual instance level, site level and all the other entities (see workflow documentation). Once the workflow is enabled for the Content Pages, every new Content Page will go through the approval process before publication. Thus, the content reviewer can preview a page with pending status and approve, reject or request additional changes.
More info: LPS-103815
Support configuring permissions for Widgets in fragment-based pages - This feature allows users to configure permissions for widgets added to fragment-based pages (including: content pages, master pages, page templates and display pages). This will allow users to control which visitors can view the widget, so that some visitors may see it while for others it's fully hidden. It may also be used to configure other permissions such as allowing certain logged in visitors to configure the widget.
We’ve taken page templates and master pages into account as well. If you create a page based on a page template, all the widget permissions are copied to the page. The permissions in widgets from the master pages are set in the master page, so you cannot change them in the page itself.
More info: LPS-102583
One of our goals with the Rolling Releases is to respond faster to feedback so we want to mention some of the feature requested that we have implemented in this release.  Feature requests are new features our community members and customers would like to see added to our products, and also an opportunity to have your voice heard by using the voting system to support ideas that you would like to see implemented. The following feature requests were implemented in GA2:
Developers and Sysadmins
  • Allowing to enter longer values (255) for category names
  • Adding remote public Layout fetchLayout method
  • Ability to have autocomplete in the fragment editor for variables, taglibs and resources.
Page Designers / Administrators:
  • Visual identification of empty portlet-columns in Widget pages
  • More flexible configuration of the number of items display with RSS Publisher
  • Ability to hide/show portlet controls on the Widget pages
  • Ability to define navigation menus in Global to share them across all sites
  • Ability to store custom information relevant to my sites on the items of a navigation menu
Introducing Asset Libraries - with this new feature, it is possible to create dedicated libraries for content that make sense together and have better-isolated control on them. Asset libraries make it easier to reuse resources across different sites, connecting them only to the sites where you need to provide access.
Asset Libraries support the storage of documents and web content allowing a marketing team to organize collateral used in a campaign in an asset library and connecting it to the sites where the campaign will be run.  While creating a page, or writing a blog post, content authors can access the connected asset libraries and use images or content uploaded.

This feature is experimental, which means that before the launch of the Liferay DXP 7.3 GA1 some features may change, from the way to interact with the libraries, to the types of content that can be stored and reused. Additionally, you may find some differences in behavior that may affect existing applications. If you don’t want the new behavior, or are not interested in Asset Libraries, you can disable the feature in Control Panel -> Configuration -> System settings -> Asset Libraries.  More info on (LPS-102412, LPS-102471, LPS-102496)



(courtesy by https://liferay.dev/blogs/-/blogs/liferay-portal-7-3-ce-ga2-release )

SAML

The Liferay DXP’s SAML (Security Assertion Markup Language) adapter lets you execute Single Sign On (SSO) and Single Log Off (SLO) in your deployment. Each Liferay DXP instance serves as either the Service Provider (SP) or the Identity Provider (IdP). This article provides the conceptual framework for Liferay DXP’s SSO solution.
  • Single Sign On
    • Identity Provider initiated SSO
    • Service Provider initiated SSO
  • Single Log Off
    • Identity Provider initiated SLO
    • Service Provider initiated SLO
Below is background on how SAML works. To jump right to its configuration, see the next article on Setting Up SAML for instructions on using the SAML adapter. Use the instructions to make the conceptual magic from this article come to life!

Important SAML URLs

For reference, here are a few important SAML URLs.
This URL is the default location of Liferay DXP’s metadata XML file:
[host]:[port]/c/portal/saml/metadata
Note that when configuring SAML for Liferay DXP, no importing of SAML certificates is required. Liferay DXP reads certificates from the SAML metadata XML file. If you want a third-party application like Salesforce to read a Liferay SAML certificate, you can export the Liferay DXP certificate from the keystore. The default keystore file is [Liferay Home]/data/keystore.jks. The exported certificate can be imported by a third-party application like Salesforce.

Single Sign On

Both the IdP and the SP can initiate the Single Sign On process, and the SSO flow is different depending on each one. Consider IdP initiated SSO first.

Identity Provider Initiated SSO

Sometimes a user enters the SSO cycle by sending a request directly from the browser to the IdP.
saml-idp-initiated-sso.png
Figure 1: Identity Provider Initiated SSO

The SSO Request to the IdP

If Liferay DXP is the IdP, the IdP initiated SSO URL
  • Must specify the path as /c/portal/saml/sso.
  • Must include the entityId parameter which is the identifier to a previously configured Service Provider Connection (SPC).
  • May include a RelayState parameter which contains a URL encoded value to which the user will be redirected upon successful authentication. This URL should point to a location on the desired SPC (according to the SAML 2.0 standards section 3.4.3, this value must not exceed 80 bytes in length). It is useful to specify a landing page after SSO has been executed.
For non-Liferay DXP IdPs (Siteminder, ADFS, etc.), consult the vendor’s documentation on constructing IdP initiated SSO URLs.
If the IdP determines that the user isn’t authenticated, it prompts the user with the appropriate login screen.

The SSO Response from the IdP

Upon successful authentication the IdP constructs a SAML Response. It includes attribute statements configured in the designated Service Provider Connection (SPC; see the next article on setting up the SPC in Liferay DXP’s SAML adapter).
The IdP sends the response to the Assertion Consumer Service URL using HTTP-POST or HTTP-Redirect. HTTP-POST is preferred because it reduces the risk that the URL is too long for a browser to handle. Using HTTP-POST, the request contains two parameters:
SAMLResponse
and
RelayState

The SP Processes the SSO Response

The SP validates and processes the SAML Response. Liferay DXP’s SAML solution requires SAMLResponse messages to be signed. This signature process ensures proper identification for the IdP and prevents potential SAML Response spoofing.
  • If one Liferay DXP instance is the IdP and another is the SP, make sure the SAML metadata XML file imported into the Liferay DXP SP contains the IdP’s certificate.
  • If Liferay DXP is the IdP and another application is the SP, export the certificate from the Liferay DXP IdP and import it into the SP’s certificate store.
If a RelayState is included in the SAML Response, the user is redirected to it. Otherwise the home page of the SP is served.

Service Provider Initiated SSO

saml-sp-initiated-sso.png
Figure 2: Service Provider Initiated SSO

The SSO Request to the SP

When the user’s browser requests a protected resource or sign on URL on the SP, it triggers the SP initiated SSO process. When Liferay DXP is the SAML SP, SSO is initiated either by requesting /c/portal/login URL or a protected resource that requires authentication (for example, a document that is not viewable by the Guest role). If the user requests a protected resource, its URL is recorded in the RelayState parameter. If the user requested /c/portal/login, the RelayState can be set by providing the redirect parameter. Otherwise, if the portal property auth.forward.by.last.path is set to true, the last accessed path is set as the RelayState. For non-Liferay DXP SPs, consult the vendor documentation on initiating SSO.

The AuthnRequest to the IdP

The SP looks up the IdP’s Single Sign On service URL and sends an AuthnRequest. When Liferay DXP is the SP it looks up the configured SAML Identity Provider Connection and sends a SAML AuthnRequest to the IdP’s Single Sign On service URL as defined in the SAML metadata XML document. Liferay DXP supports sending and receiving the AuthnRequest using HTTP-Post or HTTP-Redirect binding. HTTP-Post is preferred.
If the user doesn’t have an active session or if ForceAuthn was requested by the SP, the user must authenticate by providing his or her credentials. When Liferay DXP is the IdP, authentication occurs in the Login Portlet. Liferay DXP decodes and verifies the AuthnRequest before requesting the user to authenticate.

The SSO Response from the IdP

After authentication a SAML Response is constructed, sent to the Assertion Consumer Service URL of the SP, and verified.
When Liferay DXP is configured as the IdP, any attributes configured on the Service Provider Connection are included in the response as attribute statements. The Assertion Consumer Service URL is looked up from the SAML metadata XML of the SP. The response is sent using HTTP-Post or HTTP-redirect binding. The IdP automatically makes this choice based on the SP metadata. HTTP-Post binding is preferred and used when available. HTTP-Redirect binding is fragile because the signature and included assertions often make the URL too long for browsers.
When Liferay DXP is configured as the SP, any response and assertion signatures are verified. Liferay DXP requires the sender to be authenticated. This is done via whole message signature from the issuing IdP. Any responses missing the signature are considered unauthenticated and the response is rejected. The Response can be received via HTTP-Post binding or HTTP-redirect binding. HTTP-Post binding is preferred for the reasons mentioned in the previous section. For non-Liferay DXP SP or IdP vendors, consult their documentation.
The user is redirected to the requested resource or to the URL contained in the RelayState parameter (for example, the last page the user accessed before initiating SSO).

Single Log Off

The Single Log Off request is sent from the user’s browser to either the IdP or to a SP, and the SLO flow differs in each case. First consider IdP initiated SLO.

Identity Provider Initiated SLO

saml-idp-initiated-slo.png
Figure 3: Identity Provider Initiated SLO

The SLO Request to the IdP

An IdP initiated SLO request is a SLO request sent directly to the IdP by the user’s browser. When Liferay DXP serves as the IdP, the IdP initiated SSO URL must specify the URL path as
/c/portal/logout
If the user is signed on to any configured SP, the SAML plugin takes over the logout process, displaying all the signed on services. The single logout screen displays the authentication status of each SP and whether any SPs can’t be logged out of (for example, if the SP is down or doesn’t support SLO). For non-Liferay DXP IdPs (Siteminder, ADFS, etc.) consult the vendor’s documentation on constructing IdP initiated SLO URLs.
The IdP sends a SAML LogoutRequest to the SP.
  • When Liferay DXP is configured as the IdP, the LogoutRequest is sent using either HTTP-Post, HTTP-Redirect, or SOAP binding. HTTP-Post binding is preferred but in its absence, the first available SLO endpoint with supported binding is selected.
  • When Liferay DXP is configured as the SP, supported bindings for LogoutRequest are HTTP-Post, HTTP-Redirect, or SOAP.
  • For other IdPs or SPs, please consult the vendor’s documentation.

The SLO Response from the SP

The SP delivers a LogoutResponse to the IdP. When Liferay DXP is configured as the SP, the LogoutResponse is delivered using either HTTP-Post, HTTP-Redirect, or direct response to SOAP request. HTTP-Post binding is preferred but in its absence, HTTP-Redirect is used. SOAP is only used to respond to the LogoutRequest over SOAP binding.
The IdP sends a SAML LogoutRequest to the second SP using either HTTP-Post, HTTP-Redirect, or SOAP binding.
The second SP then delivers the LogoutResponse to the IdP using HTTP-Post, HTTP-Redirect, or direct response to SOAP request. The process is repeated for all SPs the user is logged into. When Liferay DXP is the IdP, Liferay DXP logs the user out after the last SP has delivered its LogoutResponse or has timed out.

Service Provider Initiated SLO

saml-sp-initiated-slo.png
Figure 4: Service Provider Initiated SLO

The SLO Request to the SP

In SP initiated SLO, user’s browser requests logout directly to the SP. When Liferay DXP is configured as the SP, the SLO is initiated by requesting the logout URL
/c/portal/logout
For other SPs, consult the vendor’s documentation on initiating SLO.
A SAML LogoutRequest is sent to the Single Log Out service URL of the IdP.
  • If Liferay DXP serves as the SP, the LogoutRequest is sent to the IdP configured by the IdP Connection tab of the SAML provider (see the next article to set up the IdP Connection) and the SLO service URL defined in the SAML metadata. The request is sent using HTTP-POST or HTTP-Redirect binding.
  • When Liferay DXP is the IdP, if the user has logged on to other SPs the user is presented with a single logout screen with the status of each SP logout, flagging any that can’t be looged out of (some SPs might not support SLO or are currently down). If there are no other SPs to log out of, the SAML session terminates and the IdP destroys its session.

The SLO Response from the SP

If the user is logged in to additional SPs (beyond just the initiating SP), the IdP sends the SAML LogoutRequest to each one. When Liferay DXP is the IdP, the LogoutResponse is sent using either HTTP-Post, HTTP-Redirect, or SOAP binding.
Each SP delivers its LogoutResponse to the IdP. When Liferay DXP is the SP, the LogoutResponse is sent using either HTTP-Post, HTTP-Redirect or direct response to SOAP request.
After all additional SPs deliver their LogoutResponses to the IdP, the IdP destroys its SSO session. When Liferay DXP is the IdP, once the last SP has delivered its LogoutResponse or has timed out, the IdP destroys the Liferay DXP session, logging out the user.
Finally, the IdP sends a LogoutResponse to the SP that initiated SLO. The initiating SP terminates its SAML session and logs the user out.

SAML Setup

SAML is an XML-based open standard data format for exchanging authentication and authorization data between parties known as an identity provider and a service provider. For more fundamental information on SAML and Liferay DXP, refer to the SAML introduction.
An identity provider is a trusted provider that provides single sign-on for users to access other websites. A service provider is a website that hosts applications and grants access only to identified users with proper credentials. SAML is maintained by the [OASIS Security Services Technical Committee](https://www.oasis-open.org/ committees/security/). for more information. Liferay Portal 6.1 EE and later versions support SAML 2.0 integration via the Liferay SAML 2.0 Provider application. It is provided from Liferay Marketplace and allows Liferay DXP to act as a SAML 2.0 identity provider or as a service provider.
Important: You can set Liferay DXP up as an Identity Provider or as a Service Provider. Each single Liferay DXP instance can serve as an identity provider or as a service provider, but not both. Both configurations are covered in this article.

Setting up Liferay DXP as a SAML Identity Provider

To set Liferay DXP up to act as a SAML Identity Provider, follow these steps:
  1. Install the Liferay SAML 2.0 Provider app. To access the SAML Admin interface, click on Control PanelConfiguration and then on SAML Admin.
  2. To begin configuring Liferay DXP to use SAML, select a SAML role for Liferay DXP and choose an entity ID.
    saml-initial-config.png
    Figure 1: Select a SAML role for Liferay and enter an entity ID.
    Select the Identity Provider SAML role. Enter liferaysamlidp if you’re setting up an example Liferay DXP instance. Alternatively, choose your own entity ID. Then click Save. A new Certificate and Private Key section appears.
  3. The Certificate and Private Key section lets you create a keystore for SAML. Enter the following information:
    • Your common name (your first and last name)
    • The name of your organization
    • The name of your organizational unit
    • The name of your city or locality
    • The name of your state or province
    • The name of your country
    • The length in days that your keystore will remain valid (how long before the keystore expires)
    • The key algorithm (RSA is the default)
    • The key length in bits (2048 is the default)
    • The key password
    If you’re making a test configuration, use the password liferay. When you enter all the required information, click Save.
    Note that the SAML keystore is created by the SAML plugin’s keystore manager. This keystore has two storage options:
    • In the file system
    • In the Documents and Media library
    File system storage is used by default:
    saml.keystore.manager.impl=com.liferay.saml.credential.FileSystemKeyStoreManagerImpl
    
    The default location is the [Liferay Home]/data directory.
    To use the Documents and Media library, use this property:
    saml.keystore.manager.impl=com.liferay.saml.credential.DLKeystoreManagerImpl
    
    The great thing about the Docs and Media storage is that you can use any number of back end file stores. These are protected not only by the system in which you’re storing the key, but also by Liferay DXP’s permissions system.
  4. After you click Save, you can click Replace Certificate at any time to replace the current certificate with a new one if your old one has expired or if you want to change the key’s password.
    saml-keystore-info.png
    Figure 2: The General tab of the SAML Admin portlet displays information about the current certificate and private key and allows administrators to download the certificate or replace the certificate.
    Three more tabs now appear:
    • General This tab enables or disables SAML IdP and manages the required keystore.
    • Identity Provider
      This tab contains other required configurations such as whether to enable SSL. If SSL has been enabled, then SAML requests are not approved unless they are also encrypted.
    • Service Provider Connections
      This tab manages any Service Providers connected to this Liferay DXP instance. See below for more information.
  5. After you save your certificate and private key information, check the Enabled box at the top of the General tab and click Save. You successfully set Liferay DXP up as a SAML Identity Provider!

Changing the Identity Provider Settings

To configure Liferay DXP’s SAML Identity Provider Settings, navigate to the Identity Provider tab of the SAML Admin Control Panel entry.
The Identity Provider tab includes these options:
Sign Metadata: When this box is checked, the metadata XML file that’s produced is signed.
SSL Required: When this box is checked, any SAML messages that are not sent over SSL are rejected. This does not affect how URLs are generated.
Authn Request Signature Required: When this box is checked, each Authn Request must be signed by the sending Service Provider. In most cases, this should be enabled.
Session Maximum Age: Specify the maximum duration of the SAML SSO session in seconds. If this property is not set or is set to 0, the SSO session has an unlimited duration. The SSO session maximum duration can be longer than the portal session maximum duration. If the portal session expires before the SSO session expires, the user is logged back in to Liferay DXP automatically. SSO session expiration does not trigger a single logout from all service providers. You can use the session maximum age, for example, to force users to sign in again after a certain period of time.
Session Timeout: Specify the maximum idle time of the SAML SSO session. Even if the session maximum age is unlimited, the SSO session expires whenever the user’s idle time reaches the limit set by the session timeout property.
Service Provider Defaults: The options in this section set defaults that are used when adding new service provider connections.

Checkpoint

Before adding a Service Provider (SP), verify you’ve completed these tasks:
  1. A SAML keystore has been generated. It can be stored in one of two locations: the data folder or in the Documents and Media library.
  2. On the Identity Provider tab, the following settings have been set:
    a. Sign Metadata has been checked.
    b. SSL Required - checked if SSL is active elsewhere. SSL is disabled by default.
    c. Authn Request Signature Required: has been checked.
    d. Session Maximum Age: has been set. If set to 0, then the SSO has an unlimited duration.
    e. Session Timeout: Specify the maximum idle time of the SAML SSO session.
  3. Once the Enabled checkbox has been checked, the IdP is now live, and you can generate the required metadata. This URL is the default location of Liferay DXP’s metadata XML file:
    [host]:[port]/c/portal/saml/metadata 
    
If this URL does not display correctly, then the SAML instance has not been enabled. Use the URL or click Save in the browser to generate an actual XML file.

Adding a SAML Service Provider

Of course, setting up Liferay DXP as a SAML Identity Provider is only useful if you can connect to one or more SAML Service Providers. Navigate to the Service Provider Connections tab of the SAML Admin Control Panel entry and click the Add Service Provider button to add a SAML Service Provider.
The New Service Provider page includes these options:
Name: The name of the Service Provider with which to connect.
Entity ID: The Service Provider’s entity ID. This value must match the entity ID declared in the Service Provider metadata.
Enabled: When this box is checked, the Service Provider connection is active.
Assertion Lifetime: Defines the number of seconds after which the SAML assertion issued by the Identity Provider should be considered expired.
Metadata: You can either provide a URL to the Service Provider metadata XML file or you can manually upload the Service Provider metadata XML file. If you provide a URL, the XML file is automatically retrieved and periodically polled for updates. The update interval can be configured in portlet.properties with the saml.metadata.refresh.interval property which specifies a number of seconds. If fetching the metadata XML file by URL fails, you can’t enable the Service Provider connection. If the Identity Provider server cannot access the metadata via URL, you can upload the XML file manually. In this case, the metadata XML file is not updated automatically.
Name Identifier Format: Choose the Name Identifier Format used in the SAML Response. This should be set according to what the Service Provider expects to receive. For Liferay Service Providers, any selection other than email address indicates that the Name Identifier refers to screen name. The formats don’t have any special meaning to Liferay Identity Providers. The NameID value is defined by the Name Identifier attribute. See the next option.
Name Identifier Attribute Name: This specifies which attribute of the Liferay DXP User object to use as the NameID value. Possible values include emailAddress, screenName and uuid. Additionally, you can prefix the name with static: or expando:. If you use the prefix static, the value is whatever comes after static:. If you use the prefix expando, the value is whatever custom field is specified after expando:. For example, expando:SSN would look up the User custom field with the name SSN.
Attributes Namespace Enabled: When this box is checked, the attribute names are namespaced like this:
urn:liferay:user:expando:
urn:liferay:user:
urn:liferay:groups:
urn:liferay:organizationRole:
urn:liferay:organization:
urn:liferay:roles:
urn:liferay:siteRole:
urn:liferay:userGroupRole:
urn:liferay:userGroups:
Note that the full namespace depends on the attribute name. The namespaces are useful; for example, when you have an Expando attribute that might otherwise create an attribute with the same name as some other attribute.

Checkpoint

If a Liferay DXP instance is the SAML IdP, it can connect to multiple SPs. The converse, however, is not true: SPs connect to only one IdP. Verify that your settings are correct for the first SP before proceeding to add more SPs.
  1. Provide a general name for the SP.
  2. The Entity ID name must be identical to the one declared in the Service Provider metadata.
  3. Check the Enabled checkbox.
  4. Set a value for the Assertion Lifetime.
  5. Make sure the SP’s metadata has been provided either as a URL or an XML file has been uploaded.
  6. Make sure Name Identifier Format and Name Identifier Attribute Name have been set.
  7. Make sure Attributes Namespace Enabled has been set.
If you don’t have a Service Provider to add right now, that’s fine. In the next section, you’ll learn how to set Liferay DXP up as a SAML Service Provider. After you set up another Liferay DXP instance as a Service Provider, come back to this Liferay DXP installation and add the Service Provider: Control PanelSAML AdminService Provider ConnectionsAdd Service Provider.

Setting up Liferay DXP as a SAML Service Provider

Many of these steps are similar to configuring Liferay DXP as a SAML Identity Provider. As a reminder, a single Liferay DXP installation can be configured as a SAML Identify Provider or as a SAML Service Provider but not as both. If you already set up one Liferay DXP installation as a SAML Identity Provider, use a different Liferay DXP installation as a SAML Service Provider.
  1. Install the Liferay SAML 2.0 Provider app. To confirm that the app was successfully deployed, look for the SAML Admin entry in the Configuration section of the Control Panel.
  2. To begin configuring Liferay DXP to use SAML, you must select a SAML role for Liferay DXP and you need to choose an entity ID. Select the Service Provider SAML role. Enter liferaysamlsp if you’re setting up an example Liferay DXP installation. Alternatively, choose your own entity ID. Then click Save and a new section entitled Certificate and Private Key appears.
  3. The Certificate and Private Key is for creating a keystore for SAML. Enter the following information:
    • Your common name (your first and last name)
    • The name of your organization
    • The name of your organizational unit
    • The name of your city or locality
    • The name of your state or province
    • The name of your country
    • The length in days that your keystore will remain valid (how long before the keystore expires)
    • The key algorithm (RSA is the default)
    • The key length in bits (2048 is the default)
    • The key password
    If you’re configuring an example setup, use the password liferay. When you enter all the required information, click Save.
  4. After you clicked Save, check that you can view information about your certificate or download your certificate. If you can, you successfully created a keystore. After you create a keystore, additional options appear. There are three tabs:
    • General This tab enables or disables SAML IdP and manages the required keystore.
    • Service Provider (not Identity Provider!)
      This tab manages basic and advanced configurations for the SP.
    • Identity Provider Connection (not Service Provider Connections!) This tab manages connections to the IdP. There can be only one IdP connection.
    Note that these options are different than if you were setting up Liferay DXP as an Identity Provider.
  5. Next, you need to configure an Identity Provider connection. Click on the Identity Provider Connection tab. Enter a name for the Identity Provider, enter its entity ID, and enter its metadata URL. If you have already followed the previous instructions and configured a separate Liferay DXP installation as an Identify provider, you’d enter the following information:
    Important: The Liferay SAML 2.0 Provider plugin supports using either a URL to a SAML IdP metadata file or an actual (uploaded) SAML metadata XML file. The value entered in the Metadata URL field will only be persisted to the database when there is one entered metadata URL and there is no specified metadata XML file. Otherwise, Liferay DXP keeps the original metadata URL in the database. This behavior ensures that once a metadata URL has been specified, there will always be a metadata URL saved in the database. This way, if a portal administrator forgets the previously entered metadata URL or its format, he or she can simply look at the displayed metadata URL and either choose to modify the displayed metadata URL or to overwrite the previously saved metadata URL by specifying a metadata XML file.
    Currently, the SAML Provider plugin does not provide a way to “clear” the SAML IdP metadata URL or metadata XML file fields using the Control Panel UI. If you really need to clear these fields, it’s possible (but not recommended) to delete the contents of the SAML IdP metadata URL and metadata XML file columns of the SamlSpIdpConnection table of Liferay DXP’s database.
  6. Finally, after you save your certificate and private key information and configure an Identity Provider connection, check the Enabled box at the top of the General tab and click Save. Liferay DXP is now a SAML Service Provider!
Note that the SAML Service Provider session is tied to the normal session on the application server. Session expiration on the application server terminates the session on the Service Provider but does not initiate single logout.

Checkpoint


  1. A SAML keystore has been generated.
  2. Verify the connection to the IdP.
    a. Name: generic name for the IdP.
    b. Entity ID: the same name of the IdP. If the IdP is another Liferay DXP instance, then it is the same name as the above example.
    c. Metadata URL: The IdP’s metadata as a URL or as an XML file.
  3. On the General tab, the Enabled checkbox has been checked.
  4. Once Enabled checkbox has been checked, the service provider’s metadata becomes available:
    [host]:[port]/c/portal/saml/metadata
    

Changing the SAML Service Provider Settings

If you’d like to configure Liferay DXP’s SAML Service Provider Settings, navigate to the Service Provider tab of the SAML Admin portlet.
The Service Provider tab includes these options:
Assertion Signature Required: When this box is checked, SAML assertions must be individually signed in addition to the entire SAML message.
Clock Skew: Clock skew is a tolerance in milliseconds used by the Service Provider for verifying expiration of messages and assertions. This can be used to mitigate time differences between the clocks of the Identity Provider and the Service Provider. This usually only matters when assertions have been made to expire very quickly.
LDAP Import Enabled: When this box is checked, user information is imported from the configured LDAP connection based on the resolved NameID. LDAP connections can be configured from Portal Settings.
Sign Authn Requests: When this box is checked, the AuthnRequest is signed even if the Identity Provider metadata indicates that it’s not required.
Sign Metadata: When this box is checked, the metadata XML file is signed.
SSL Required: When this box is checked, any SAML messages that are not sent over HTTPS are rejected. This does not affect how URLs are generated.
The Identity Provider Connection page includes these options:
Name: The name of the Identity Provider with which to connect.
Entity ID: The Identity Provider’s entity ID. This value must match the entity ID declared in the Identity Provider metadata.
Clock Skew: Clock skew is a tolerance in milliseconds used by the Service Provider for verifying expiration of messages and assertions. This can be used to mitigate time differences between the clocks of the Identity Provider and the Service Provider. This usually only matters when assertions have been made to expire very quickly.
Force Authn: When this box is checked, the Service Provider asks the Identity Provider to re-authenticate the user before verifying the user.
Metadata: You can either provide a URL to the Identity Provider metadata XML file or you can manually upload it. If you provide a URL, the XML file is automatically retrieved and periodically polled for updates. You can change the update interval in portlet.properties by modifying the saml.metadata.refresh.interval property which specifies a number of seconds. If fetching the metadata XML file by URL fails, you can’t enable the Identity Provider connection. If the metadata is inaccessible via URL, you can upload the XML file manually. In this case, the metadata XML file is not updated automatically.
Attribute Mapping: The attribute mapping is done from the attribute name or friendly name in the SAML Response to the Liferay DXP attribute name. For example, if you want to map a response attribute named mail to the Liferay DXP attribute emailAddress, you’d enter the following mapping:
mail=emailAddress
Available Liferay DXP attributes are: emailAddress, screenName, firstName, lastName, modifiedDate, and uuid.
Save your changes when you are finished configuring the Liferay DXP instance as a service provider. There is no need to restart the server and the changes will be applied immediately.
The previous two sections explained how to use the SAML 2.0 Provider EE plugin’s Control Panel interface to configure Liferay DXP as an Identity Provider or as a Service Provider. Such configurations should only be made through the SAML Control Panel interface and not via properties. Some features of the Liferay SAML 2.0 Provider plugin are not available as properties.

Setting Up Liferay DXP as a SAML Service Provider in a Clustered Environment

If you want to use the Liferay SAML 2.0 Provider app as an SSO solution for a clustered Liferay DXP environment, follow the steps in this section. Before proceeding, make sure that the following assumptions apply to your scenario.
Suppose that your clustered Liferay DXP environment consists of multiple Liferay DXP nodes that sit behind a load balancer. Your Liferay DXP nodes could be Liferay DXP Tomcat bundles, for example. Your load balancer could be software like Apache web server or hardware like F5 BIG-IP. Suppose further that you want want the nodes of your Liferay DXP cluster to serve as SAML Service Providers. And suppose that you have a third-party participating as the SAML Identity Provider. (For testing purposes, you could create a separate Liferay DXP installation to serve as the SAML IdP.)
If your situation fits the scenario described above, follow these steps:
  1. Configure each node of your Liferay DXP cluster as a SAML service provider using the instructions of the previous section.
  2. Copy the keystore file ([Liferay Home]/data/keystore.jks, by default) from the first Liferay DXP node to the remaining Liferay DXP nodes. This file is the Java keystore that’s created by the SAML Provider plugin. The keystore contains the valid or self-signed certificate managed by the SAML Provider plugin.
    Note: The keystore file and its default location can vary according to the keystore manager defined by the saml.keystore.manager.impl property. Here’s the relevant section of the Liferay SAML 2.0 Provider plugin’s portlet.properties file:
    #
    # Set the name of a class that implements
    # com.liferay.saml.credential.KeyStoreManager. This class is used to load and
    # save the keystore.
    #
    #saml.keystore.manager.impl=com.liferay.saml.credential.DLKeyStoreManagerImpl
    saml.keystore.manager.impl=com.liferay.saml.credential.FileSystemKeyStoreManagerImpl
    
  3. Verify that the service provider metadata has been generated to be used either as a URL or an XML file. The metadata is the same for all nodes because of the same database back-end. The IdP’s request goes through the load balancer.
  4. At this point, all the Liferay DXP nodes have the same SAML SP configuration and each of them can respond to web requests and handle the SAML protocol. To test your SSO solution, sign into Liferay DXP via your load balancer, navigate to a few pages of a few different sites, and then log out.
Now you know how to configure Liferay DXP either as a SAML identity provider or a service provider. You also know how to configure SAML in a clustered environment.

-------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------

How to Generate Liferay SAML Environment's metadata.xml

Description

This article describes how to generate Liferay SAML metadata from a web browser. SAML metadata in an XML file is configuration data required to automatically negotiate agreements between system entities, comprising identifiers, binding support and endpoints, certificates, keys, cryptographic capabilities and security and privacy policies. (See SAML V2.0 Metadata Guide.)

If a Liferay Portal or Digital Enterprise 7.0 instance has SAML enabled as either the SP or IdP, then the following steps can be performed to generate the metadata XML file.

Resolution

Any of the articles in the Additional Information section will contain specific steps on how to configure and enable SAML on your platform.
1. After this has been completed, open a web browser and navigate to the following URL:
  • <{IP_ADDRESS} or {virtual host name}>/c/portal/saml/metadata
2. Save the file as an XML file from the browser (Click Save as...). Remember to use the same file name in the third party IdP or SP.
Below is a test example SAML metadata in XML format:

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="samlsp" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>OeS/FZEebCaJfq980NVrIWnEoLA=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>bPBGfa7w40jHtab52olVr0wBST0RGbUx3QpJ/6Ivs8no42iuhDv790Cijc3UN5kjwr1SBLYo/1nl7ANTO5LBjd3TXMAASWydHbcgzYzqXA5Gx9F9BUlQx6rLZAK7GJWjHEU+zVqNSY51qHg3vKKsYXCXnfuxpr7huWfDu1qacOiIsN3qDHJ2ldchcs82BsBNqAmi5uDhppr2KSVNaodBk6FrrNyvrkZgMm+8JA52otipT1vYkoEz+32cqKWrbDVhSQvyqj0P3biU4N3ltJYBd/2wbkY/jUphWEuQ1LQPnWH7sGDvKdADO1AgIZK/ZNzxPDoeYeE3qPZrNkak83/klQ==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIC3zCCAccCBgFFLbHcqzANBgkqhkiG9w0BAQUFADAzMREwDwYDVQQDDAhkZWF0aHJheTERMA8G A1UECgwIZGVhdGhyYXkxCzAJBgNVBAYTAlVTMB4XDTE0MDQwNDE3MDMyMloXDTE1MDMyNjE3MDMy MlowMzERMA8GA1UEAwwIZGVhdGhyYXkxETAPBgNVBAoMCGRlYXRocmF5MQswCQYDVQQGEwJVUzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIPGFtPxD7NwveZVuTRurSEdwZUfhIl5QfHv P+V2dVpltIaN09fiUJPDwDWdq7FYYkIfJC/Xe+t2beRuceCc9kfIpP05xrTxLHDER3uFlGBXPe7o M92ea0kwrA39vS3HQI92IZ5OjS8LIdQpZcK3SJBDQRpjVyNCxJtGPZA1tA0F3KMHIAwxIBXvtQgN iRXPQifnB4XRSE45G3InyM3nPrZuEcfD06sL5JLkc2q1hD0jMWpRxMNepQA7fq+8eXSF4xsxsdvY jfbzllrXiMKlJwnxP8J+yN+Iw9rQsBeBzJpC6I3eN3aiFCvSXucJ6Ue2ayINuQWyDzKnCODGSEKc Fj8CAwEAATANBgkqhkiG9w0BAQUFAAOCAQEAOwuBUnI38pHn+h2/2S9KGG+MOcbZ+UuobezCW7sv bFnSpojMQvTabl0iVMWcSxQsbvWlPS3BAR8apwDGZNGJlMS+WPCX4MmvBitpaQQTiWj3HnuAo8jI URKa9i9XUrsQDXOP8LrXwizOgglUc5KMcVdX9ygQNAZPMbSJZ3XWtrqMbPNH+UlTbpAIP5e4ND1i nbyvcaF+hLfI5Sysz4cVxOc1i12KmKhJDl7pZp4kiviXLx6GurXn73IxYINVtEu83eEmJkabL5Ge vekdRnSaAmBeFyKgDLOz/ovapL5bBIgDIC5EmgP3+WHYLl7IMrl0HjZtdRQsGxrpGZf4EZ1XRg==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><md:SPSSODescriptor AuthnRequestsSigned="true" ID="samlsp" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><md:KeyDescriptor use="signing"><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC3zCCAccCBgFFLbHcqzANBgkqhkiG9w0BAQUFADAzMREwDwYDVQQDDAhkZWF0aHJheTERMA8G A1UECgwIZGVhdGhyYXkxCzAJBgNVBAYTAlVTMB4XDTE0MDQwNDE3MDMyMloXDTE1MDMyNjE3MDMy MlowMzERMA8GA1UEAwwIZGVhdGhyYXkxETAPBgNVBAoMCGRlYXRocmF5MQswCQYDVQQGEwJVUzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIPGFtPxD7NwveZVuTRurSEdwZUfhIl5QfHv P+V2dVpltIaN09fiUJPDwDWdq7FYYkIfJC/Xe+t2beRuceCc9kfIpP05xrTxLHDER3uFlGBXPe7o M92ea0kwrA39vS3HQI92IZ5OjS8LIdQpZcK3SJBDQRpjVyNCxJtGPZA1tA0F3KMHIAwxIBXvtQgN iRXPQifnB4XRSE45G3InyM3nPrZuEcfD06sL5JLkc2q1hD0jMWpRxMNepQA7fq+8eXSF4xsxsdvY jfbzllrXiMKlJwnxP8J+yN+Iw9rQsBeBzJpC6I3eN3aiFCvSXucJ6Ue2ayINuQWyDzKnCODGSEKc Fj8CAwEAATANBgkqhkiG9w0BAQUFAAOCAQEAOwuBUnI38pHn+h2/2S9KGG+MOcbZ+UuobezCW7sv bFnSpojMQvTabl0iVMWcSxQsbvWlPS3BAR8apwDGZNGJlMS+WPCX4MmvBitpaQQTiWj3HnuAo8jI URKa9i9XUrsQDXOP8LrXwizOgglUc5KMcVdX9ygQNAZPMbSJZ3XWtrqMbPNH+UlTbpAIP5e4ND1i nbyvcaF+hLfI5Sysz4cVxOc1i12KmKhJDl7pZp4kiviXLx6GurXn73IxYINVtEu83eEmJkabL5Ge vekdRnSaAmBeFyKgDLOz/ovapL5bBIgDIC5EmgP3+WHYLl7IMrl0HjZtdRQsGxrpGZf4EZ1XRg==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></md:KeyDescriptor><md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://www.bravo.com:9443/c/portal/saml/slo_redirect"/><md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://www.bravo.com:9443/c/portal/saml/slo_soap"/><md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.bravo.com:9443/c/portal/saml/acs" index="1" isDefault="true"/></md:SPSSODescriptor></md:EntityDescriptor>


Setup SAML on Liferay DXP

Description

This article serves as a guide is for deploying SAML on Liferay DXP both as an Identity provider and Service provider

Table of Contents

  1. Introduction
  2. Setting Up Liferay SAML as an IdP
  3. Setting Up Liferay SAML as an SP
  4. Use Case #1: Salesforce Integration
  5. Use Case #2 Liferay as Both IdP and SP
  6. Use Case #3: User Attributes Other Than Email Address
  7. Use Case #4: Connecting Through a Secure Proxy Connection
  8. Troubleshooting

Introduction
SAML (Security Assertion Markup Language) is an XML-based open standard data format for exchanging authentication and authorization data between identity providers and service providers. SAML is a form of Single Sign On / Single LogOut (SSO / SLO) authentication. It was developed by OASIS in 2001 (SAML 1.0) with the latest update to the standard coming in 2005 (SAML 2.0). From a Liferay perspective, SAML 2.0 is available as an EE plugin. The plugin supports two operation modes: identity provider and service provider. The plugin is built on OpenSAML, is platform neutral, and is supported by many Saas applications. For credentials, a java keystore is used.
Liferay SAML offers two different configurations: as an Identity Provider (abbrev. as IdP) and as a Service Provider (abbrev. as SP). Developers can also connect Liferay SAML in either configuration to third party technologies such as an ADFS, another SSO/SLO protocol like Shibboleth, or to Salesforce. Liferay SAML plugin version 3.0 is specific to Liferay DXP. Please see the release notes or the change log to see more details about the changes in the latest SAML plugin version 3.0.
Using SAML requires two different IP addresses, or two different virtual hosts, or two different ports. In the Windows environment, admins can go to the etc/hosts file and create several virtual hosts. The examples below will use a combination of different settings as illustrations.

Resolution

Liferay SAML as IdP
The following steps describe how to setup SAML as an IdP.
  1. Start Liferay DXP on default port 8080.
  2. Sign in and do not flag "Remember Me". (Otherwise this will invalidate SAML.)
  3. Deploy the latest SAML plugin available on Liferay Marketplace.
  4. Once the plugin has been successfully deployed, navigate to the Control Panel > Configuration> SAML Admin
  5. On the General tab, enter the following:
    1. SAML Role: Identity Provider
    2. Entity ID: samlidp
  6. Click the Save button.
  7. Users now have to generate the certificate. In the past, this was done all in a command line. The latest SAML versions beginning with 6.1 EE GA3 allows developers to generate the certificate in the Control Panel.
    1. Common Name: liferayidp
    2. Organization: liferay
    3. Country: USA
    4. Validity: 356
    5. Key Algorithm: RSA (leave the default value)
    6. Key Length: 2048 (leave the default value)
    7. Key Password: liferayidp
  8. Click the Save button.
  9. Check the Enabled check box.
    The completed configuration should look like this:
  10. Click the Identity Provider tab.
  11. Click the Sign Metadata.
  12. Check the Authn Request Signature Required check box.
  13. Click Save.
At this point, the basic IdP configuration is complete. To add a Service Provider, the Service Provider must already be active because the IdP authenticates the SP's metadata URL. To add a Service Provider, go to the Service Provider Connections tab and click "Add Service Provider". At this point, anything can serve as the Service Provider, especially other third party technologies. Follow the configuations required to connect with Liferay; Salesforce (see below) is one good example.

Liferay SAML as SP
The following steps are on how to set up SAML as an SP. For demonstration purposes and to differentiate between the IdP and SP, the SP will be using a virtual host called www.alpha.com with Apache Tomcat port number 9080. If users wish to connect two Liferay bundles, go through this pre-start checklist:
  • The SP instance runs on a different database.
  • The SP instance uses a different port number or a different virtual host name.
  • The IdP and SP uses the same method for authentication. By default it is the user's email address but it could also be the screen name or another method such as a role.
  • The same users are on both databases.
  • The SP runs on a different OSGi console port number. This can be set in the portal-ext.properties:
    module.framework.properties.osgi.console=localhost:11312
Once the pre-start checklist is completed, start Liferay DXP and follow the steps below to configure Liferay SAML as a Service Provider (SP).
  1. Start Liferay DXP using the virtual host www.alpha.com on default port 9080 (http://www.alpha.com:9080).
  2. Sign in and do not flag "Remember Me". (Otherwise this will invalidate SAML.)
  3. Deploy the latest SAML plugin available on Liferay Marketplace.
  4. Once the plugin has been successfully deployed, navigate to the Control Panel > Configuration> SAML Admin
  5. On the General tab, enter the following:
    1. SAML Role: Service Provider
    2. Entity ID: samlidp
  6. Click the Save button.
  7. Users now have to generate the certificate. In the past, this was done all in a command line. The latest SAML versions beginning with 6.1 EE GA3 allows developers to generate the certificate in the Control Panel.
    1. Common Name: liferaysp
    2. Organization: liferay
    3. Country: USA
    4. Validity: 356
    5. Key Algorithm: RSA (leave the default value)
    6. Key Length: 2048 (leave the default value)
    7. Key Password: liferaysp
  8. Click the Save button.
    The initial configuration should look something like this:
  9. Do not flag the Enabled check box yet. The SP requires an active IdP. Users can set another Liferay instance as the SP; this is not portal version specific. Or users can set other non-Liferay technology as the IdP. The following configuration uses another Liferay instance as the IdP.
  10. Click the Identity Provider Connection tab.
  11. Enter the following:
    1. Name: samlidp
    2. Entity ID: samlidp
    3. Metadata URL: http://localhost:8080/c/portal/saml/metadata
    4. Name Identifier Format: Email Address
  12. Click the Save button.
  13. Once the configurations have been saved, click the General tab.
  14. Check the Enabled check box.
  15. Click the Save button.
  16. At this point, the SP has been enabled. To verify, administrators can view the metadata by appending /c/portal/saml/metadata to the end of the host URL (e.g. http://localhost:8080/c/portal/saml/metadata).


Use case #1: Salesforce Integration: Salesforce as a SP.
Administrators can execute a SSO request to Salesforce. To do so, Liferay DXP must be configured as an IdP (see the section on configuring Liferay DXP with SAML as an IdP).
  1. Start up Liferay DXP with the SAML app deployed.
  2. Navigate to Control Panel > Configuration > SAML Admin
  3. Verify that the IdP enabled check box is flagged.
  4. Click Download Certificate (Certificate and Private Key section).

    Save the .pem file. This file is needed on Salesforce to generate the Salesforce metadata.xml.
  5. Navigate to the Control Panel > Users.
  6. Create a new user with the same email address as the one used to sign into Salesforce. Do not use the default test@liferay.com.
    1. First Name: Salesforce
    2. Last Name: Admin
    3. Password: samlidp1
  7. Grant full Administrator roles to this new user.
The next series of steps is to generate the metadata file from Salesforce.
  1. Navigate to http://developer.force.com
  2. Create an account using the same valid email address. This will also serve as the user account. Use samlidp1 as the password for the Salesforce account.
  3. After signing in, go to salesforce.com, log in and then click Setup
  4. Click Security Controls > Single Sign on Settings
  5. Click Edit and check the SAML Enabled checkbox.
  6. Click Save
  7. Click New
  8. Enter the following:
    • Name: samlsp
    • Issuer: samlidp
    • Entity ID: https://saml.salesforce.com
    • Identity Provider Certificate: Upload the samlidp.pem file
    • Identity Provider Login URL: http://localhost:8080/c/portal/saml/sso
    • Identity Provider Logout URL: http://localhost:8080/c/portal/logout
    • SAML Identity Type: "Assertion contains User's salesforce.com username"
    • SAML Identity Location: "Identity is in the NameIdentifier element of the Subject statement"

  9. Click the Save button.
  10. Download the metadata xml file and rename it salesforce-metadata.xml.
The next steps complete the set up:
  1. In Liferay DXP, navigate to the Control Panel > Configuration >SAML Admin.
  2. Click the Service Provider Connections tab.
  3. Click the Add Service Provider button
  4. Enter the following:
    • Name: salesforce
    • Entity ID: https://saml.salesforce.com
    • Check the Enabled checkbox.
    • Click Upload Metadata XML
    • Upload the salesforce-metadata.xml
    • Select Unspecified from the Name Identifier Format drop down
    • Enter static: {email address used to sign up for Salesforce without the braces of course} in the Name Identifier Attribute Name field
    • Check the Attributes Enabled box
  5. Click the Save button
Execute SSO to Salesforce
  1. In Liferay DXP, Click Menu > Liferay DXP site
  2. Make sure that the user are signed in as the user created above (e.g Salesforce Admin). If not, sign out and sign in again with the correct credentials.
  3. Click Navigation
  4. Click the three dot icon next to Public Pages > Add Public Page
  5. Enter Salesforce in the Name field.
  6. Select Link to URL from the Type dropdown.
  7. Enter in the URL field: http://localhost:8080/c/portal/saml/sso?entityId=https://saml.salesforce.com
  8. Click the Add Page button
  9. The system will redirect back to the main page. Click on the Salesforce page. It should redirect to the salesforce.com site without having to reauthenticate.


Liferay as both IdP and as SP

Add a SP to the IdP instance.
In this use case, Liferay is able to serve as both an IdP and a SP. Furthermore, users can have multiple SPs. Every SP must be added individually to the IdP. Follow the steps below to add a SP to the IdP.
  1. Ensure that every SP instance has been started. This is important because there will be an error message that the endpoint is invalid.
  2. Ensure that the user is sign in without "Remember Me" checked.
  3. Navigate to the Control Panel > Configuration > SAML Admin.
  4. Click the Service Provider Connections tab.
  5. Click Add Service Provider.
  6. Enter the following:
    • Name: samlsp
    • Entity ID: samlsp
    • Enabled: checked
    • Metadata URL: http://www.alpha.com:9080/c/portal/saml/metadata
    • Name Identifier Format: Email Address
    • Name Identifier Attribute Name: emailAddress

  7. Click the Save button.
  8. Repeat these for every unique SP to be added.

Once all the SPs have been added, Liferay SAML offers two different ways to execute SSO/SLO.
IdP-initiated SSO/SLO
  1. Follow the steps to configure the first Liferay DXP bundle as an IdP. The example SP's virtual host name is www.alpha.com:9080
  2. Ensure that the user is sign in without "Remember Me" checked.
  3. In the IdP browser URL, enter the following:
    http://localhost:8080/c/portal/saml/sso?entityId=samlsp&RelayState=http://www.alpha.com:9080
  4. Watch the IdP redirecting to the SP. If the same users with the same email address are present on both instances, it will authenticate and show the SP. If users are found in only one instance whether it is an ADFS or a Liferay instance but not the other, authentication will fail. SAML can authenticate across major portal versions, that is, the IdP can be Portal 6.1 EE GA3 or Liferay Portal 6.2 EE and the SP can be Portal 6.2. EE GA1 or Liferay DXP. For testing purposes, it is obvious if the authentication succeeds or fails if the IdP and SP are different portal versions.
  5. On the SP, there is no need to sign in a separate time.
  6. Open a new browser window showing the IdP. Click Sign Out.
  7. There is a javascript that runs to execute SLO on all instances. Once the IdP has been logged out, go to the SP instance. Refresh the browser window on the SP instance.
  8. The SP will have signed out as well.

SP-initiated SSO/SLO
  1. In the SP browser window on www.able.com:9080, click the Sign In link at the top right. Do not use the Sign In portlet.
  2. The browser will redirect to the IdP instance's Sign In portlet.
  3. Sign In. Do not check "Remember Me".
  4. The system will redirect back to the SP.
  5. Open a new browser window to the IdP. In this case: localhost:8080.
  6. The IdP will already have been signed in.
  7. Go to the SP instance.
  8. Click Sign Out.
  9. Go to the IdP instance. Refresh the browser window. The IdP will be signed out.


Use Case #3: User Attributes Other Than Email Address

Users can use other attributes beside email addresses to authenticate. For example, the use case involving Salesforce integration requires users to change the Name Identifier to Unspecified and enter other values (e.g. static:${salesforce-user-name} or static:${user-email-address}.
Another example where other attributes is integrating with Shibboleth. There are use cases where the IdP is ADFS or Shibboleth and the SP is Liferay. Depending on how the ADFS is configured, other attributes such as first name or last name can be used. Shibboleth can use screen names to authenticate. In the SP, change the Name Identifier Format from Email Address to Unspecified.

Use Case #4: Connecting through a Secure Proxy Connection

Often, in a typical Liferay Digital Enterprise 7.0 environment, there are more than just the two IdP and SP servers communicating with each other. The environment might also have a load balancer server (this is very strongly suggested if not actually required) in a clustered environment and a web server to handle web requests. For additional security, administrators will use the https protocol instead of the default http. The SAML plugin deployed on Liferay Digital Enterprise 7.0 will still be able to execute both an IdP initiated SSO and a SP initiated SSO as long as the Assertion process has been configured to redirect from HTTP to HTTPS.

While each application server is different in how it enables and configures redirecting to secure ports 443, there is only one change required in Liferay Digital Enterprise 7.0's portal-ext.properties:

portal.instance.protocol=https
web.server.protocol=https

Once these properties have been added to the portal-ext.properties file, the portal now recognizes the HTTPS message being sent and then sends it successfully through the SAML Assertion process.
Lastly, administrators must ensure that SSL Required is activated in the SAML Admin Control Panel. To do so:
  1. Navigate to the Control Panel > Configuration > SAML Admin
  2. If this instance of Liferay Digital Enterprise 7.0 is configured as a SAML IdP server, then check the SSL Required check box in the Identity Provider tab.
  3. The same is true for Liferay Digital Enterprise 7.0 instances configured as a SAML SP server. Check the SSL Required check box in the Service Provider tab.
  4. Click Save.


Troubleshooting

SAML issues are often configuration issues. Users might have skipped a step or entered a value incorrectly. Nevertheless, some of the more commonly found questions are adressed here.
1. I cannot execute SLO on either instance!
Usually, this is caused by one or more of the following scenarios:
  1. Users cannot flag "Remember Me in the Sign In portlet.
  2. SAML timeout must be shorter than Liferay timeout. In this second scenario, if the SAML timeout is longer than the Liferay timeout, the system will act as if "Remember Me" has been checked. The solution is to set the SAML timeout to 180 seconds.
  3. Users defined something other than slo_redirect in their portal settings. Navigate to the Control Panel > Portal Settings and change the settings to c/portal/saml/slo_redirect.

2. What if an IdP does not support metadata downloading? Does Liferay SP support installing a certificate (similar to Salesforce)?

Answer: SAML Metadata XML must be provided. It can be provided either through url or file. If the IdP does not support SAML metadata, then the XML file must be manually created.
3. What are session timeout and assertion lifetime? How are they different?

Session timeout refers to how long the SAML IdP will remain connected to the SP. In the context of Liferay Portal, ensure that the SAML session timeout is shorter than the portal's or else SLO will not work. If the session ends due to user inactivity, users will have to re-authenticate.
Assertion lifetime refers to how long the assertion between IdP and SP is valid. Assertions can expire or otherwise not recognized if the server times are out of sync. Usually, this is measured in seconds. To fix this, adjust the clock skew feature accordingly.

Liferay 7.3 compatibility matrix

Compatibility Matrix Liferay's general policy is to test Liferay Portal CE against newer major releases of operating systems, open s...