Enportal/5.6/admin/user administration/ldap configuration/tutorial

Revision as of 11:18, 30 April 2015 by imported>Jason.nicholls (1 revision)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


Overview

Using the LazyLoad Process

In enPortal, you can use the "LazyLoad" process to create Portal users "On-Demand" so that when a user tries to log in to enPortal, the portal will contact LDAP and create this user and authenticate it.

  1. You have a local ldap server running on ldap://laptop:10565
  2. In dc=example-corp,dc=com you have created three users: jadams, jsmith, jtaylor within ou=people.
  3. Create an ldapRepository pointing to the ldap server and give it credentials to login.
  4. Create a domainAdapter "testOne". Since you do not have a RoleAdapter you need a way of associating roles to the users defined in this domain. So create a /HelpDesk role; and assign it as the defaultRole using the General tab; change the pluggable authenticator to "com.edgetech.eportal.session.impl.LDAPSessionAuthenticatorExtendedWithLazyLoad". Then switching to the Search tab you fill in Search Base ="ou=people,dc=example-corp,dc=com".
  5. Save the changes.
  6. Open a new browser (or log out of the existing portal session) and attempt to log in to the portal using: domain = "testOne", user = "jadams", password = "pw".
  7. The portal then:
    1. receives the request.
    2. accesses LDAP to see if the user can authenticate. If there is a failure, it returns to the login page.
    3. on auth success; checks to see if user is defined. If the user exists, skip the next step.
    4. creates the user account in the testOne domain, if the user does not exist.
    5. checks to see if the domain dn or user dn is has any ldap group assignments (this will only occur if RoleAdapters were defined for the LDAPRepository definition). Reset the role assignments.
    6. checks to see if the user has a role assignment. If so, it looks up provisioned content and renders the page.


Making LDAP Groups Map to enPortal Roles

If the decision is made to use LDAP, you should also define Groups in LDAP that can be used to create roles in the portal. The following is a scenario:

  1. Inside of ou=groups,dc=example-corp,dc=com
  2. Create three Groups named: HelpDesk, Operator, and Manager.
  3. Inside of these Groups edit the membership to assign Users to Groups.
  4. Logging back into the portal, navigate to the LDAPRepository that was created and define a new RoleAdapter named "/MSP" (The fully qualified portal role). On the Search Base In enter "ou=groups,dc=example-corp,dc=com".
  5. Then for each Group add the following memberships:
    1. Manager assigned jadams as members.
    2. Operator assigned jadams, jsmith as members.
    3. HelpDesk assigned jadams, jsmith, jtaylor as members
  6. Run portal ldapsync command and the roles /MSP/Manager, /MSP/Operator, and /MSP/HelpDesk are defined.
  7. Provision some content (views / channels) to these roles.
  8. Log out and then log in using: domain = "testOne", user = "jsmith", password = "pw".
  9. The user will be logged in and they will have /portalAdministration, Operator and HelpDesk roles available. Note: it is recommended to remove /portalAdministration as the default role for the DomainAdapter.


Importing a User Without a Role Adapter Defined

It is possible to import a user without a Role adapter defined. However, a Role must be assigned to the user for the user to be able to log in to the system. The best way for the Role assignment to be made is for the Role assignment to be imported with the user.


Passing Single Sign-on Credentials to Applications

Sometimes you will want to set the Single Sign-on (SSO) configuration for products integrated into AppBoard/enPortal that are also using LDAP. The goal is to have AppBoard/enPortal pass the login credentials from LDAP to the back-end application, when the same credentials are used to access enPortal and the back-end application.


You can use the following expression when configuring the SSO token. It will pass the same credentials entered by the user logging in to AppBoard, to the backend application:

  • username: ${shim:session.credentials.username}
  • password: ${shim:session.credentials.password}