Our documentation has been relocated here, the Liferay Developer Network. Please update your bookmarks!

Integrating Liferay Users into Your Enterprise

LDAP

You can use the LDAP tab of the Authentication page to connect Liferay to an LDAP directory. There are two places for you to configure the LDAP settings: here in the control panel or in the portal-ext.properties file (which is covered in chapter 20). We recommend you use the control panel since your configuration settings will be stored in the database. Note that if you use both, the settings in the database will be merged with the settings in portal-ext.properties. If there’s a conflict or overlapping data, the LDAP servers set in the control panel take precedence over the servers set in portal-ext.properties. Configuring the LDAP settings from the control panel is easier and does not require a restart of Liferay. The only compelling reason to use the portal-ext.properties file is if you have many Liferay nodes which will be configured to run against the same LDAP directory. In that case, for your initial deployment, it may be easier to copy the portal-ext.properties file to all of the nodes so the first time they start up, the settings are correct. Regardless of which method you use, the available settings are the same.

You configure the global values from the LDAP tab of the Authentication page.

Enabled: Check this box to enable LDAP Authentication.

Required: Check this box if LDAP authentication is required. Liferay will then not allow a user to log in unless he or she can successfully bind to the LDAP directory first. Uncheck this box if you want to allow users with Liferay accounts but no LDA accounts to log in to the portal.

LDAP Servers: Liferay supports connections to multiple LDAP servers. You can you the Add button beneath this heading to add LDAP servers. We explain how to configure new LDAP servers below.

Import/Export: You can import and export user data from LDAP directories using the following options:

  • Import Enabled: Check this box to cause Liferay to do a mass import from your LDAP directories. If you want Liferay to only synchronize users when they log in, leave this box unchecked. Definitely leave this unchecked if you are working in a clustered environment. Otherwise, all of your nodes would try to do a mass import when each of them starts up.

  • Import on Startup Enabled: Check this box to have Liferay run the import when it starts up. Note: This box only appears if you check the Import Enabled box above.

  • Export Enabled: Check this box to enable Liferay to export user accounts from the database to LDAP. Liferay uses a listener to track any changes made to the User object and will push these changes out to the LDAP server whenever the User object is updated. Note that by default on every login, fields such as LastLoginDate are updated. When export is enabled, this has the effect of causing a user export every time the user logs in. You can disable this by setting the following property in your portal-ext.properties file:

    users.update.last.login=false

Use LDAP Password Policy: Liferay uses its own password policy by default. This can be configured on the Password Policies page of the control panel. Check the Use LDAP Password Policy box if you want to use the password policies defined by your LDAP directory. Once this is enabled, the Password Policies tab will display a message stating you are not using a local password policy. You will now have to use your LDAP directory’s mechanism for setting password policies. Liferay does this by parsing the messages in the LDAP controls returned by your LDAP server. By default, the messages in the LDAP controls that Liferay is looking for are the messages returned by the Fedora Directory Server. If you are using a different LDAP server, you will need to customize the messages in Liferay’s portal-ext.properties file, as there is not yet a GUI for setting this. See below for instructions describing how to do this.

Once you’ve finished configuring LDAP, click the Save button. Next, let’s look at how to add LDAP servers.

Adding LDAP Servers

The Add button beneath the LDAP servers heading allows you to add LDAP servers. If you have more than one, you can arrange the servers by order of preference using the up/down arrows. When you add an LDAP Server, you will need to provide several pieces of data so Liferay can bind to that LDAP server and search it for user records. Regardless of how many LDAP servers you add, each server has the same configuration options.

Server Name: Enter a name for your LDAP server.

Default Values: Several leading directory servers are listed here. If you are using one of these, select it and click the Reset Values button. The rest of the form will be populated with the proper default values for that directory.

Connection: These settings cover the basic connection to LDAP.

  • Base Provider URL: This tells the portal where the LDAP server is located. Make sure the machine on which Liferay is installed can communicate with the LDAP server. If there is a firewall between the two systems, check to make sure the appropriate ports are opened.

  • Base DN: This is the Base Distinguished Name for your LDAP directory. It is usually modeled after your organization. For a commercial organization, it may look similar to this: dc=companynamehere,dc=com.

  • Principal: By default, the administrator ID is populated here. If you have removed the default LDAP administrator, you will need to use the fully qualified name of the administrative credential you use instead. You need an administrative credential because Liferay will be using this ID to synchronize user accounts to and from LDAP .

  • Credentials: This is the password for the administrative user.

This is all you need to make a regular connection to an LDAP directory. The rest of the configuration is optional. Generally, the default attribute mappings provide enough data to synchronize back to the Liferay database when a user attempts to log in. To test the connection to your LDAP server, click the Test LDAP Connection button.

If you are running your LDAP directory in SSL mode to prevent credential information from passing through the network unencrypted, you will have to perform extra steps to share the encryption key and certificate between the two systems.

For example, assuming your LDAP directory happens to be Microsoft Active Directory on Windows Server 2003, you would take the following steps to share the certificate:

Click StartAdministrative ToolsCertificate Authority. Highlight the machine that is the certificate authority, right-click on it, and click Properties. From the General menu, click View Certificate. Select the Details view, and click Copy To File. Use the resulting wizard to save the certificate as a file. As with the CAS install (see the below section entitled Single Sign-On), you will need to import the certificate into the cacerts keystore. The import is handled by a command like the following:

keytool -import -trustcacerts -keystore /some/path/jdk1.5.0_11/jre/lib/security/cacerts -storepass changeit -noprompt -alias MyRootCA -file /some/path/MyRootCA.cer

The keytool utility ships as part of the Java SDK.

Once this is done, go back to the LDAP page in the control panel. Modify the LDAP URL in the Base DN field to the secure version by changing the protocol to https and the port to 636 like the following:

ldaps://myLdapServerHostname:636

Save the changes. Your Liferay Portal will now use LDAP in secure mode for authentication.

Users: This section contains settings for finding users in your LDAP directory.

  • Authentication Search Filter: The search filter box can be used to determine the search criteria for user logins. By default, Liferay uses users’ email addresses for their login names. If you have changed this setting, you will need to modify the search filter here, which has been configured to use the email address attribute from LDAP as a search criterion. For example, if you changed Liferay’s authentication method to use screen names instead of the email addresses, you would modify the search filter so it can match the entered log in name:

    (cn=@screen_name@)

  • Import Search Filter: Depending on the LDAP server, there are different ways to identify the user. Generally, the default setting (objectClass=inetOrgPerson) is fine but if you want to search for only a subset of users or users that have different object classes, you can change this.

  • User Mapping: The next series of fields allows you to define mappings from LDAP attributes to Liferay fields. Though your LDAP user attributes may be different from LDAP server to LDAP server, there are five fields Liferay requires to be mapped for the user to be recognized. You must define a mapping to the corresponding attributes in LDAP for the following Liferay fields:

    • Screen Name
    • Password
    • Email Address
    • Full Name
    • First Name
    • Middle Name
    • Last Name
    • Job Title
    • Group

The control panel provides default mappings for commonly used LDAP attributes. You can also add your own mappings if you wish.

  • Test LDAP Users: Once you have your attribute mappings set up (see above), click the Test LDAP Users button and Liferay will attempt to pull LDAP users and match them with their mappings as a preview.

server-configuration-testing-ldap-users.jpg

Figure 15.15: Testing LDAP Users

Groups: This section contains settings for mapping LDAP groups to Liferay.

  • Import Search Filter: This is the filter for finding LDAP groups you want to map to Liferay. Enter the LDAP group attributes you want retrieved for this mapping. The following attributes can be mapped:

    • Group Name
    • Description
    • User
  • Test LDAP Groups: Click the Test LDAP Groups to display a list of the groups returned by your search filter.

Export: This section contains settings for exporting user data from LDAP.

  • Users DN: Enter the location in your LDAP tree where the users will be stored. When Liferay does an export, it will export the users to this location.

  • User Default Object Classes: When a user is exported, the user is created with the listed default object classes. To find out what your default object classes are, use an LDAP browser tool such as JXplorer to locate a user and view the Object Class attributes stored in LDAP for that user.

  • Groups DN: Enter the location in your LDAP tree where the groups will be stored. When Liferay does an export, it will export the groups to this location.

  • Group Default Object Classes: When a group is exported, the group is created with the listed default object classes. To find out what your default object classes are, use an LDAP browser tool such as Jxplorer to locate a group and view the Object Class attributes stored in LDAP for that group.

server-configuration-mapping-ldap-groups.jpg

Figure 15.16: Mapping LDAP Groups

Once you’ve set all your options and tested your connection, click Save. From here, you can add another LDAP server or set just a few more options that apply to all of your LDAP server connections.

LDAP Options Not Available in the GUI

Although most of the LDAP configuration can be done from the control panel, there are several configuration parameters that are only available by editing portal-ext.properties. These options will be available in the GUI in future versions of Liferay Portal but for now they can only be configured by editing the properties file.

If you need to change any of these options, copy the LDAP section from the portal.properties file into your portal-ext.properties file. Note that since you have already configured LDAP from the GUI, any settings from the properties file that match settings already configured in the GUI will be ignored. The GUI, which stores the settings in the database, always takes precedence over the properties file.

ldap.auth.method=bind
#ldap.auth.method=password-compare

Set either bind or password-compare for the LDAP authentication method. Bind is preferred by most vendors so you don’t have to worry about encryption strategies. Password compare does exactly what it sounds like: it reads the user’s password out of LDAP, decrypts it and compares it with the user’s password in Liferay, syncing the two.

ldap.auth.password.encryption.algorithm=
ldap.auth.password.encryption.algorithm.types=MD5,SHA

Set the password encryption to used to compare passwords if the property ldap.auth.method is set to password-compare.

ldap.import.method=[user,group]

If you set this to user, Liferay will import all users from the specified portion of the LDAP tree. If you set this to group, Liferay will search all the groups and import the users in each group. If you have users who do not belong to any groups, they will not be imported.

ldap.error.password.age=age
ldap.error.password.expired=expired
ldap.error.password.history=history
ldap.error.password.not.changeable=not allowed to change
ldap.error.password.syntax=syntax
ldap.error.password.trivial=trivial
ldap.error.user.lockout=retry limit

These properties are a list of phrases from error messages which can possibly be returned by the LDAP server. When a user binds to LDAP, the server can return controls with its response of success or failure. These controls contain a message describing the error or the information that is coming back with the response. Though the controls are the same across LDAP servers, the messages can be different. The properties described here contain snippets of words from those messages and will work with Red Hat’s Fedora Directory Server. If you are not using that server, the word snippets may not work with your LDAP server. If they don’t, you can replace the values of these properties with phrases from your server’s error messages. This will enable Liferay to recognize them. Next, let’s look at the Single Sign-On solutions Liferay supports.

SSO

Single Sign-On solutions allow you to provide a single login credential for multiple systems. This allows you to have people authenticate to the Single Sign-On product and they will be automatically logged in to Liferay and to other products as well.

Liferay supports several single sign-on solutions. Of course, if your product is not yet supported, you may choose to implement support for it yourself by use of the extension environment. Alternatively, your organization can choose to sponsor support for it. Please contact sales@liferay.com for more information about this.

Authentication: Central Authentication Service (CAS)

CAS is an authentication system originally created at Yale University. It is a widely-used open source single sign-on solution and was the first SSO product to be supported by Liferay.

Please follow the documentation for CAS to install it on your application server of choice.

Your first step will be to copy the CAS client .jar file to Liferay’s library folder. On Tomcat, this is in [Tomcat Home]/webapps/ROOT/WEB-INF/lib. Once you’ve done this, the CAS client will be available to Liferay the next time you start it.

The CAS Server application requires a properly configured Secure Socket Layer certificate on your server to work. If you wish to generate one yourself, you will need to use the keytool utility that comes with the JDK. Your first step is to generate the key. Next, you export the key into a file. Finally, you import the key into your local Java key store. For public, Internet-based production environments, you will need to either purchase a signed key from a recognized certificate authority (such as Thawte or Verisign) or have your key signed by a recognized certificate authority. For Intranets, you should have your IT department pre-configure users’ browsers to accept the certificate so they don’t get warning messages about the certificate.

To generate a key, use the following command:

keytool -genkey -alias tomcat -keypass changeit -keyalg RSA

Instead of the password in the example (changeit), use a password you will remember. If you are not using Tomcat, you may want to use a different alias as well. For First and Last names, enter localhost or the host name of your server. It cannot be an IP address.

To export the key to a file, use the following command:

keytool -export -alias tomcat -keypass changeit -file server.cert

Finally, to import the key into your Java key store, use the following command:

keytool -import -alias tomcat -file %FILE_NAME% -keypass changeit -keystore $JAVA_HOME/jre/lib/security/cacerts

If you are on a Windows system, replace $JAVA_HOME above with %JAVA_HOME%. Of course, all of this needs to be done on the system on which CAS will be running.

Once your CAS server is up and running, you can configure Liferay to use it. This is a simple matter of navigating to the Settings → Authentication → CAS tab in the control panel. Enable CAS authentication and then modify the URL properties to point to your CAS server.

Enabled: Check this box to enable CAS single sign-on.

Import from LDAP: A user may be authenticated from CAS and not yet exist in the portal. Select this to automatically import users from LDAP if they do not exist in the portal.

The rest of the settings are various URLs, with defaults included. Change localhost in the default values to point to your CAS server. When you are finished, click Save. After this, when users click the Sign In link, they will be directed to the CAS server to sign in to Liferay.

Authentication: Facebook

Liferay Portal also enables users to log in using their Facebook accounts. To enable this feature, you simply need to select the Enable box and enter the Application ID and Application Secret which should have been provided to you by Facebook. Facebook SSO works by taking the primary Facebook email address and searching for the same email address in Liferay’s User_ table. If a match is found, the user is automatically signed on (provided the user clicked allow from the Facebook dialog). If there isn’t a match, the user is prompted in Liferay to add a user from Facebook. Once selected, a new user is created by retrieving four fields from Facebook (first name, last name, email address and gender).

Authentication: NTLM

NTLM is a Microsoft protocol that can be used for authentication through Microsoft Internet Explorer. Though Microsoft has adopted Kerberos in modern versions of Windows server, NTLM is still used when authenticating to a workgroup. Liferay Portal now supports NTLM v2 authentication. NTLM v2 is more secure and has a stronger authentication process than NTLMv1.

Enabled: Check this box to enable NTLM authentication.

Domain Controller: Enter the IP address of your domain controller. This is the server that contains the user accounts you want to use with Liferay.

Domain: Enter the domain / workgroup name.

Service Account: You need to create a service account for NTLM. This account will be a computer account, not a user account.

Service Password: Enter the password for the service account.

Authentication: OpenID

OpenID is a new single sign-on standard which is implemented by multiple vendors. The idea is multiple vendors can implement the standard and then users can register for an ID with the vendor they trust. The credential issued by that vendor can be used by all the web sites that support OpenID. Some high profile OpenID vendors are AOL http://openid.aol.com/screenname, LiveDoor http://profile.livedoor.com/username and LiveJournal http://username.livejournal.com. Please see the OpenID site http://www.openid.net for a more complete list.

A main benefit of OpenID for the user is he or she no longer has to register for a new account on every site in which he or she wants to participate. Users can register on one site (the OpenID provider’s site) and then use those credentials to authenticate to many web sites which support OpenID. Many web site owners often struggle to build communities because end users are reluctant to register for so many different accounts. Supporting OpenID makes it easier for site owners to build their communities because the barriers to participating (i.e., the effort it takes to register for and keep track of many accounts) are removed. All of the account information is kept with the OpenID provider, making it much easier to manage this information and keep it up to date.

Liferay Portal can act as an OpenID consumer, allowing users to automatically register and sign in with their OpenID accounts. Internally, the product uses OpenID4Java http://code.google.com/p/openid4java/ to implement the feature.

OpenID is enabled by default in Liferay but can be disabled here.

Atlassian Crowd

Atlassian Crowd is a web-based Single Sign-On product similar to CAS. Crowd can be used to manage authentication to many different web applications and directory servers.

Because Atlassian Crowd implements an OpenID producer, Liferay works and has been tested with it. Simply use the OpenID authentication feature in Liferay to log in using Crowd.

Authentication: OpenSSO

OpenSSO is an open source single sign-on solution that comes from the code base of Sun’s System Access Manager product. Liferay integrates with OpenSSO, allowing you to use OpenSSO to integrate Liferay into an infrastructure that contains a multitude of different authentication schemes against different repositories of identities.

You can set up OpenSSO on the same server as Liferay or a different box. Follow the instructions at the OpenSSO site http://opensso.dev.java.net to install OpenSSO. Once you have it installed, create the Liferay administrative user in it. Users are mapped back and forth by screen names. By default, the Liferay administrative user has a screen name of test, so in OpenSSO, you would register the user with the ID of test and an email address of *test@liferay.com*. Once you have the user set up, log in to Open SSO using this user.

In the same browser window, go to the URL for your server running Liferay and log in as the same user, using the email address *test@liferay.com*. Go to the control panel and click Settings → Authentication → OpenSSO. Modify the three URL fields (Login URL, Logout URL and Service URL) so they point to your OpenSSO server (i.e., only modify the host name portion of the URLs), click the Enabled check box and then click Save. Liferay will then redirect users to OpenSSO when they click the Sign In link.

Authentication: SiteMinder

SiteMinder is a single sign-on implementation from Computer Associates. Liferay 5.2 introduced built-in integration with SiteMinder. SiteMinder uses a custom HTTP header to implement its single sign-on solution.

To enable SiteMinder authentication in Liferay, check the Enabled box on the SiteMinder tab. If you are also using LDAP with Liferay, you can check the Import from LDAP box. If this box is checked, users authenticated from SiteMinder who do not exist in the portal will be imported from LDAP.

The last field defines the header SiteMinder is using to keep track of the user. The default value is already populated. If you have customized the field for your installation, enter the custom value here.

When you are finished, click Save. Next, let’s learn about the SAML 2.0 Provider EE plugin.

SAML

ee-feature-web.png

EE-only

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. An identity provider is a trusted provider that enables users to use single sign-on 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. See https://www.oasis-open.org/committees/security/ for more information. Liferay 6.1 EE and later versions support SAML 2.0 integration via the SAML 2.0 Provider EE plugin. This plugin is provided as an app from Liferay Marketplace that allows Liferay to act as a SAML 2.0 identity provider or as a service provider. First, we’ll look at how to set Liferay up as an Identity Provider and then we’ll look at how to set it up as a Service Provider.

Setting up Liferay as a SAML Identity Provider

In order to set Liferay up to act as a SAML Identity Provider, use the following steps:

  1. Install the SAML 2.0 Provider EE app, either via the Control Panel’s Marketplace interface or manually. To confirm that the plugin was successfully deployed, look for the SAML Admin entry in the Portal section of the Control Panel.

  2. Next, you need to generate a keystore to use with SAML. You can generate a keystore using the Java keytool utility. Navigate to your [Liferay Home]/data directory in a command prompt or terminal and run the following command to generate a keystore there:

    keytool -genkey -keyalg RSA -alias liferaysamlidp -keystore keystore.jks -storepass liferay -validity 360 -keysize 2048
    

    Upon running this command, you’ll be prompted to enter the following information:

    • First and last name
    • Name of your organizational unit
    • Name of your organization
    • Name of your city or locality
    • Name of your state or province
    • Your country’s two-letter country code

    This information will be included in the keystore. After you answer the questions, a keystore named keystore.jks is created with the alias (entity ID) liferaysamlidp and the password liferay. To keep this example simple, use the same password for liferaysamlidp as for the keystore itself: liferay.

  3. Log in to your portal as an administrator and click on the SAML Admin entry in the Control Panel. For the SAML role, select Identity Provider, and for the Entity ID, enter the alias of the keystore you generated in your Liferay instance’s data folder: liferaysamlidp. Then click Save.

  4. After clicking Save, additional options appear in the SAML Admin Control Panel portlet. There are three tabs:

    • General
    • Identity Provider
    • Service Provider Connections

    Leave the SAML role and Entity role as you configured them in step 3. In the Certificate and Private Key section, enter the same information that you entered when you generated your keystore, then click Save. After saving your certificate and private key information, you can view information about your certificate or download your certificate.

  5. Finally, after you’ve saved your certificate and private key information, check the Enabled box at the top of the General tab and click Save. Great! You’ve successfully set Liferay up as a SAML Identity Provider!

To configure Liferay’s SAML Identity Provider Settings, navigate to the Identity Provider tab of the SAML Admin Control Panel portlet. Of course, setting up Liferay 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 portlet and click on the Add Service Provider button to add a SAML Service Provider. Right now, we don’t have one to add but next, we’ll learn how to set Liferay up as a SAML Service Provider.

After you’ve set up another Liferay instance as a Service Provider, you can come back to this Liferay instance’s Control Panel and add the Service Provider: Control PanelSAML Admin &rrar; Service Provider ConnectionsAdd Service Provider.

Setting up Liferay as a SAML Service Provider

In order to set Liferay up to act as a SAML Service Provider, use the following steps. Many of the steps are similar to the ones for setting Liferay up to act as a SAML Identity Provider. A single Liferay instance can be configured as a SAML Identify Provider or a SAML Service Provider but not both! If you’ve already set up one Liferay instance as a SAML Identity Provider, use a different Liferay instance as a SAML Service Provider

  1. Install the SAML 2.0 Provider EE app, either via the control panel’s Marketplace interface or manually. To confirm that the plugin was successfully deployed, look for the SAML Admin entry in the Portal section of the Control Panel.

  2. Next, you need to generate a keystore to use with SAML. You can generate a keystore using the Java keytool utility. Navigate to your [Liferay Home]/data directory in a command prompt or terminal and run the following command to generate a keystore there:

    keytool -genkey -keyalg RSA -alias liferaysamlsp -keystore keystore.jks -storepass liferay -validity 360 -keysize 2048
    

    Upon running this command, you’ll be prompted to enter the following information:

    • First and last name
    • Name of your organizational unit
    • Name of your organization
    • Name of your city or locality
    • Name of your state or province
    • Your country’s two-letter country code

    This information will be included in the keystore. After you answer the questions, a keystore named keystore.jks is created with the alias (entity ID) liferaysamlsp and the password liferay. To keep this example simple, use the same password for liferaysamlsp as for the keystore itself: liferay.

  3. Log in to your portal as an administrator and click on the SAML Admin entry in the Control Panel. For the SAML role, select Service Provider, and for the Entity ID, enter the alias of the keystore you generated in your Liferay instance’s data folder: liferaysamlsp. Then click Save.

  4. After clicking Save, additional options appear in the SAML Admin Control Panel portlet. Note that these options are different than if you were setting up Liferay as an Identity Provider. There are three tabs:

    • General
    • Service Provider (not Identity Provider!)
    • Identity Provider Connection (not Service Provider Connections!)

    Leave the SAML role and Entity role as you configured them in step 3. In the Certificate and Private Key section, enter the same information that you entered when you generated your keystore, then click Save. After saving your certificate and private key information, you can view information about your certificate or download your certificate.

  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 already configured a separate Liferay instance as an Identify provider following the previous instructions, you’d enter the following information:

  6. Finally, after you’ve saved your certificate and private key information and configured an Identity Provider connection, check the Enabled box at the top of the General tab and click Save. Great! You’ve successfully set Liferay up as a SAML Service Provider!

If you’d like to configure Liferay’s SAML Service Provider Settings, navigate to the Service Provider tab of the SAML Admin Control Panel portlet.

Suppose that you have two Liferay instances running on ports 8080 and 9080 of your host. Suppose further that you’ve configured the Liferay running on port 8080 as a SAML Identity Provider and the Liferay running on port 9080 as a SAML Service Provider, following the instructions above. If your Identity Provider and Service Provider have been correctly configured, navigating to http://localhost:8080/c/portal/saml/sso?entityId=liferaysamlsp initiates the SAML Identity Provider based login process. To initiate the SAML Service Provider based login process, just navigate to the Liferay running on port 9080 and click Sign In, navigate to http://localhost:9080/c/portal/login, or try to access a protected resource URL such as a Control Panel URL. Next, let’s examine how to configure portal-wide user settings.

Users

The Users page of Portal Settings has three tabs: Fields, Reserved Credentials and Default User Associations.

The Fields tab allows you to enable/disable the following fields:

  • Enable/disable requiring the Terms of Use

  • Enable/disable user screen names autogeneration

  • Enable/disable requiring the last names

  • Enable/disable the birthday field

  • Enable/disable the gender field

The next tab is Reserved Credentials. You can enter screen names and email addresses here that you don’t want others to use. Liferay will then prevent users from registering with these screen names and email addresses. You might use this feature to prevent users from creating IDs that look like administrative IDs or that have reserved words in their names.

The Default User Associations tab has three fields allowing you to list (one per line) sites, roles and user groups you want new users to become members of automatically. By default, Liferay assigns new users to both the Users role and the Power Users role.

If you have defined other user groups, sites or roles you want newly created users to be members of by default, enter them here. For example, you may have defined site templates in certain user groups to pre-populate end users’ private pages. If there is a particular configuration you want everyone to have, you may want to enter those user groups here.

0 (0 Votes)
Managing Portal Settings Previous