Task 2: Adding the LDAP to the security realm

In this task, you add your new LDAP server to the security realm of the sample server.

About this task

The sample server works on an instance of the Liberty profile. The users available for the other samples and tutorials are declared in the basic registry. To include the LDAP registry to the security realm, you modify the server.xml file to include a connection to the LDAP server.

Step 1: Enabling the LDAP registry

In this step, you add the LDAP registry, and add search filters to limit the number of users. The sample server authenticates the users in its basic user registry.

Procedure

If you have never started the sample server, start it now to create the Liberty instance (Starting the sample server).
Before you modify the configuration, make sure that the sample server is stopped (see Stopping the sample server).

Open <WLP_HOME>/usr/servers/odmXXX/server.xml.

Notice the presence of a user rtsAdmin, mapped to the groups AdminGroup and InstallGroup, under <basicRegistry>. This person is the administrative power user. The pertinence of this user becomes clear as you go through the tutorial:

<!-- Web application security -->
  <basicRegistry id="basic" realm="customRealm">
   ...
    <user name="rtsAdmin" password="rtsAdmin" />
   ...
		     <group name="AdminGroup">
			      <member name="rtsAdmin" />
			      <member name="Paul" />
		     </group>
		     <group name="InstallGroup">
			      <member name="rtsAdmin" />
		      </group>
...

Enable the LDAP registry by adding the following code block:

<!-- LDAP connection -->
<ldapRegistry
    id="ldap"
    realm="odmrealm"
    host="localhost"
	   port="10389"
	   ignoreCase="true"
	   recursiveSearch="true"
    ldapType="Custom" 
    baseDN="dc=example,dc=com" 
    bindDN="uid=admin,ou=system" 
    bindPassword="secret">
    <customFilters
       userFilter="(uid=%v)" 
       groupFilter="(cn=%v)" 
       userIdMap="*:uid" 
       groupIdMap="*:cn" 
       groupMemberIdMap="groupOfNames:member">
    </customFilters>
</ldapRegistry>

Notice these details in this code block:

The host and port corresponding to your LDAP server, and the baseDN, corresponding to the entry point in the LDAP hierarchy.
The bindDN and bindPassword parameters, allowing access to the LDAP server.
The <customFilters> section, used to limit the search for users to be authorized to log in to Decision Center.

Save the file.

Step 2: Binding groups and users

In the next task, you log in as the administrative power user to import the LDAP users to the database.

About this task

To log in to Decision Center, a user must be mapped to one of the predefined Decision Center roles. All regular users are mapped to the rtsUser role.

You also need the administrative power user to complete the initial configuration of Decision Center and do some configuration tasks. In the basic registry, the user rtsAdmin belongs to two groups, AdminGroup and InstallGroup. These groups can be named whatever you like, but they must be bound to the rtsAdministrator and rtsInstaller roles.

The recommended approach is to keep this administrative power user in the basic user registry to handle IT functions, and then use the LDAP registry for the other business users. It is also possible to create this user directly in your LDAP as described in the configuration guide Configuring user access to Decision Center.

Procedure

In server.xml, notice the security role binding of the three Decision Center applications - the Business console, and the REST API:

<application-bnd>
<security-role name="rtsAdministrator">
   <group name="AdminGroup"/>
</security-role>
<security-role name="rtsInstaller">
    <group name="InstallGroup"/>
</security-role>
<security-role name="rtsConfigManager">
    <group name="ConfigGroup"/>
</security-role>
<security-role name="rtsUser">
    <special-subject type="ALL_AUTHENTICATED_USERS" />
</security-role>
</application-bnd>

Note: The Configuration Manager role is not used in this tutorial. This type of user has more rights than the standard user, but less than the administrator (see Decision Center security.)

Step 3: Enabling automatic refresh

In this step, you enable automatic import of users and groups before you start the sample server. If you do not specify this option, you must manually import to the Decision Center database any group or user that you add to the LDAP repository.

Procedure

In most situations, manual import is not convenient. Two possibilities are available to provide automatic import:

Automatically import LDAP users from groups that you specify in the Business console.
Automatically import users from all groups that are found in the LDAP.

When you enable automatic import, all manually created users are deleted.

In this tutorial, you implement the first option:

Add the following lines in <WLP_HOME>/usr/servers/odmXXX/jvm.options, and then save:
```
-Dcom.ibm.rules.decisioncenter.ldap.sync.users-and-groups=users
-Dcom.ibm.rules.decisioncenter.ldap.sync.refresh.period=60000
```
The second line sets the refresh rate in milliseconds, in this case every minute.
To see whether you correctly added LDAP access to the sample server, do as follows:
1. Start the sample server (see Opening Decision Center on the sample server).
2. Start the Decision Center Business console.
3. Log in as Jim (password Jim). You are authenticated as a regular user. You do not have access to the Administration tab.
4. In the top banner of the Business console, select the drop-down list beside your user name Jim, and click Profile. Notice that you are not currently a member of any group:
5. Close the panel and log out.

What to do next

In this task, you added the LDAP to the security realm so that users who are declared in this LDAP can log in to the Business console. In the next task, you log in as an administrator to import users into the Decision Center database, so that Jim and Sue can be given security access to specific decision services, through their groups.