Configuring user access without OpenID

Before you create an ODM instance, you must override the default user registry configuration and include it in a secret that you pass to IBM Operational Decision Manager. Regardless of whether your authentication registry is basic or an LDAP, always put the administrative users in the basic registry because they need to modify parameters in Decision Center.

About this task

Note: IBM Operational Decision Manager works with WebSphere® Liberty server. Liberty uses an LDAP type of registry, so the examples that are given here use the syntax specific to this type of LDAP. For more information, see the Liberty server documentation.

A default registry configuration is used when you install ODM. To replace this configuration with your own, you must create a webSecurity.xml file in which you define the users that you want to authenticate with the application server.

Use case 1: The basic registry contains all wanted users

In the following webSecurity.xml file, you define an ODM super user. This user can be used to administer both Decision Server and Decision Center. But to separate the rtsAdministrator and the resAdministrator roles, two extra administrative users, rtsAdmin and resAdmin, are defined.


<server>
   <!-- Define the basic registry -->	
   <basicRegistry id="basic" realm="customRealm">

      <!-- ODM super user -->
      <user name="odmAdmin" password="odmAdmin"/>
	
      <!-- Users for Decision Center -->
      <user name="rtsAdmin" password="rtsAdmin"/>
      <user name="rtsConfig" password="rtsConfig"/>
      <user name="rtsUser1" password="rtsUser1"/>
      <user name="rtsUser2" password="rtsUser2"/>
 
      <!-- Users for Decision Server -->
      <user name="resAdmin" password="resAdmin"/>
      <user name="resDeployer" password="resDeployer"/>
      <user name="resMonitor" password="resMonitor"/>
      <user name="resExecutor" password="resExecutor" />

      <!-- Groups for Decision Center -->
      <group name="rtsAdministrators">
         <member name="odmAdmin"/>
         <member name="rtsAdmin"/>
      </group>
      <group name="rtsConfigManagers">
         <member name="rtsConfig"/>
      </group>

      <!-- Groups for Decision Server -->
      <group name="resAdministrators">
         <member name="odmAdmin" />
         <member name="resAdmin" />
      </group>
      <group name="resDeployers">
         <member name="resDeployer" />
      </group>
      <group name="resMonitors">
         <member name="resMonitor" />
      </group>
      <group name="resExecutors">
         <member name="odmAdmin" />
         <member name="resAdmin" />
         <member name="resDeployer" />
         <member name="resMonitor" />
         <member name="resExecutor" />
      </group>
   </basicRegistry>
</server>

A sample YAML file can be found in GitHub https://github.com/ODMDev/odm-docker-kubernetes/blob/master/configuration/security/sample-webSecurity-basic-registry.xml.

Use case 2: The basic registry contains only a super user and all the other users are in the LDAP registry

Attention: Do not create in the LDAP registry a group that exists in the basic registry. It is not supported by the Liberty server. In this example, the rtsAdministrators, resAdministrators, and resExecutors groups are provided by the basic registry. Other groups like rtsConfigManagers, resMonitors, and resDeployers are provided by the LDAP registry. Role and group names must be identical. If you cannot or do not want to use these group names, turn to Use case 3.

If you use an LDAP registry and you are allowed to create groups in your LDAP registry, follow these recommendations:

Put the super users in the basic registry.
Create LDAP groups for Decision Center in which you place users to give them more permissions.
Create LDAP groups for Decision Server in which you place users.
Add the LDAP connection information in the .xml registry configuration file and adapt the <customFilters> section if you want to restrict access to the Decision Center and Decision Server applications to authorized LDAP users.

The following webSecurity.xml configuration uses OpenLDAP.


<server>
   <!-- Define the basic registry -->
   <!-- The basic registry contains only a super user. All the other users will be in the LDAP registry. -->
   <basicRegistry id="basic" realm="customRealm">
   
   <!-- Define users -->
   <!-- ODM super user -->
   <user name="odmAdmin" password="odmAdmin"/>
   
   <!-- Assign users to groups -->
   <group name="rtsAdministrators">
      <member name="odmAdmin"/>
   </group>
   <group name="resAdministrators">
      <member name="odmAdmin" />
   </group>
   <group name="resExecutors">
      <member name="odmAdmin" />
   </group>
   </basicRegistry>

   <!-- Define the LDAP registry -->
   <ldapRegistry id="ldap" realm="OpenLdapRealm" 
    host="openldap" port="389" ldapType="Custom" ignoreCase="true" recursiveSearch="true"
    baseDN="dc=example,dc=org" bindDN="cn=admin,dc=example,dc=org" bindPassword="admin">
      <customFilters
         userFilter="(uid=%v)" 
         groupFilter="(cn=%v)"
         userIdMap="*:uid" 
         groupIdMap="*:cn" 
         groupMemberIdMap="groupOfNames:member">
      </customFilters>    
   </ldapRegistry>
</server>

Use case 3: You want to extend the role mapping

By default, the roles on the Liberty server are strictly mapped to groups with the same name. For example, the resAdministrators role must be mapped to a resAdministrators group in the basic or LDAP registry.

To extend the default mapping to three predefined groups and three predefined users, set the extendRoleMapping parameter to true for each ODM component. For example, if the Helm template is generated with --set decisionServerConsole.extendRoleMapping=true, then the Decision Server Console roles on the Liberty server are configured as follows.


<server>     
   <!-- Define the basic registry -->
   <basicRegistry id="basicRegistry">

   <!-- ODM super user -->
   <user name="odmAdmin" password="odmAdmin"/>

   <!-- Users for Decision Center -->
   <user name="rtsAdmin" password="rtsAdmin"/>
   <user name="rtsConfig" password="rtsConfig"/>
   <user name="rtsUser1" password="rtsUser1"/>
   <user name="rtsUser2" password="rtsUser2"/>

   <!-- Users for Decision Server -->
   <user name="resAdmin" password="resAdmin"/>
   <user name="resDeployer" password="resDeployer"/>
   <user name="resMonitor" password="resMonitor"/>
   <user name="resExecutor" password="resExecutor" />

   <!-- Groups for Decision Center -->
   <group name="basicRtsAdministrators">
    <member name="odmAdmin" />
    <member name="rtsAdmin" />
   </group>
   <group name="basicRtsInstallers">
    <member name="odmAdmin" />
    <member name="rtsAdmin" />
   </group>
   <group name="basicRtsConfigManagers">
    <member name="rtsConfig"/>
   </group>
   <group name="basicResAdministrators">
    <member name="odmAdmin" />
    <member name="resAdmin" />
   </group>
   <group name="basicResDeployers">
    <member name="resDeployer" />
   </group>
   <group name="basicResMonitors">
    <member name="resMonitor" />
   </group>
   <group name="basicResExecutors">
    <member name="odmAdmin" />
    <member name="resAdmin" />
    <member name="resDeployer" />
    <member name="resMonitor" />
    <member name="resExecutor" />
   </group>
   </basicRegistry>

   <!-- Define the LDAP registry -->
   <ldapRegistry id="ldap" baseDN="dc=example,dc=org"
    host="openldap" port="389" ldapType="Custom" ignoreCase="true" recursiveSearch="true" bindDN="cn=admin,dc=example,dc=org" bindPassword="admin">
      <customFilters
         userFilter="(uid=%v)" 
         groupFilter="(cn=%v)"
         userIdMap="*:uid" 
         groupIdMap="*:cn" 
         groupMemberIdMap="groupOfNames:member">
      </customFilters>    
   </ldapRegistry>

   <!-- Define the federated repository -->
   <federatedRepository id="vmm">
   <primaryRealm name="o=defaultWIMFileBasedRealm">
        <participatingBaseEntry name="o=BasicRegistry"/>
        <participatingBaseEntry name="dc=example,dc=org"/>
   </primaryRealm>
   </federatedRepository>

   <!-- Define the mapping between roles and groups -->
    
   <!-- Grant access to the role rtsAdministrator for the groups basicRtsAdministrators in basic registry and ldapRtsAdministrators in LDAP -->
   <variable name="odm.rtsAdministrators.group1" value="group:o=defaultWIMFileBasedRealm/basicRtsAdministrators"/>
   <variable name="odm.rtsAdministrators.group2" value="group:o=defaultWIMFileBasedRealm/cn=ldapRtsAdministrators,ou=memberlist,dc=example,dc=org"/>
    
   <!-- Grant access to the role rtsInstaller for the groups basicRtsInstallers in basic registry and ldapRtsInstallers in LDAP -->
   <variable name="odm.rtsInstallers.group1" value="group:basicRealm/basicRtsInstallers"/>
   <variable name="odm.rtsInstallers.group2" value="group:o=defaultWIMFileBasedRealm/cn=ldapRtsInstallers,ou=memberlist,dc=example,dc=org"/>
    
   <!-- Grant access to the role rtsConfigManager for the groups basicRtsConfigManagers in basic registry and ldapRtsConfigManagers in LDAP -->
   <variable name="odm.rtsConfigManagers.group1" value="group:basicRealm/basicRtsConfigManagers"/>
   <variable name="odm.rtsConfigManagers.group2" value="group:o=defaultWIMFileBasedRealm/cn=ldapRtsConfigManagers,ou=memberlist,dc=example,dc=org"/>
    
   <!-- Grant access to the role resAdministrator for the groups basicResAdministrators in basic registry and ldapResAdministrators in LDAP -->
   <variable name="odm.resAdministrators.group1" value="group:o=defaultWIMFileBasedRealm/basicResAdministrators"/>
   <variable name="odm.resAdministrators.group2" value="group:o=defaultWIMFileBasedRealm/cn=ldapResAdministrators,ou=memberlist,dc=example,dc=org"/>
    
   <!-- Grant access to the role resDeployers for the groups basicResDeployers in basic registry and ldapResDeployers in LDAP -->
   <variable name="odm.resDeployers.group1" value="group:o=defaultWIMFileBasedRealm/basicResDeployers"/>
   <variable name="odm.resDeployers.group2" value="group:o=defaultWIMFileBasedRealm/cn=ldapResDeployers,ou=memberlist,dc=example,dc=org"/>
    
   <!-- Grant access to the role resMonitors for the groups basicResMonitors in basic registry and ldapResMonitors in LDAP -->
   <variable name="odm.resMonitors.group1" value="group:o=defaultWIMFileBasedRealm/basicResMonitors"/>
   <variable name="odm.resMonitors.group2" value="group:o=defaultWIMFileBasedRealm/cn=ldapResMonitors,ou=memberlist,dc=example,dc=org"/>
   
   <!-- Grant access to the role resExecutors for the groups basicResExecutors in basic registry and ldapResExecutors in LDAP -->
   <variable name="odm.resExecutors.group1" value="group:o=defaultWIMFileBasedRealm/basicResExecutors"/>
   <variable name="odm.resExecutors.group2" value="group:o=defaultWIMFileBasedRealm/cn=ldapResExecutors,ou=memberlist,dc=example,dc=org"/>
</server>

You must define in the webSecurity.xml file the mapping between a user or a group variable and a user or a group located in the basic or the LDAP registry.

A sample YAML file can be found in GitHub https://github.com/ODMDev/odm-docker-kubernetes/blob/master/configuration/security/sample-webSecurity-role-extension.xml.

Procedure

Define your user registry configuration according to your needs in a webSecurity.xml file.
Create a secret with the webSecurity.xml file by running the following command.
```
kubectl create secret generic my-auth-secret --from-file=webSecurity.xml=webSecurity.xml
```
Where my-auth-secret is the name you give to your secret, and webSecurity.xml the name of your user registry configuration file.
Note: If you want to use SSL-enabled LDAP in your container environment, you must create the SSL secret with the certificate of the LDAP server.
- Put the LDAP certificate in the truststore.jks file. Follow the procedure described in Defining the security certificate.
- In the LDAP registry (ldapRegistry) section of the webSecurity.xml file, add the following two parameters.
```
sslEnabled="true"
sslRef="odmDefaultSSLConfig"
```
  Where odmDefaultSSLConfig is the name of the ODM SSL reference. Keep it as is.

Optional: Specify two extra files in your configuration: ldap-configurations.xml and group-security-configurations.xml.

kubectl create secret generic my-auth-secret --from-file=webSecurity.xml --from-file=ldap-configurations.xml --from-file=group-security-configurations.xml

The ldap-configurations.xml file automatically defines the LDAP configuration available under the Decision Center Administration tab.

For example,

<dc-usermanagement>
        <ldapConnections>
                <ldapConnection name="LDAP">
                        <ldapUrl>http://hostname</ldapUrl>
                        <searchConnectionDN>cn=admin,dc=example,dc=org</searchConnectionDN>
                        <searchConnectionPassword>password</searchConnectionPassword>
                        <groupSearchBase>ou=groups,dc=example,dc=org</groupSearchBase>
                        <groupSearchFilter>(cn=*)</groupSearchFilter>
                        <groupNameAttribute>cn</groupNameAttribute>
                        <groupMemberAttribute>member</groupMemberAttribute>
                        <userIdAttribute>uid</userIdAttribute>
                        <userNameAttribute>cn</userNameAttribute>
                        <userMailAttribute>mail</userMailAttribute>
                        <ldapProperties>
                                <ldapPropertyName/>
                        </ldapProperties>
                </ldapConnection>
        </ldapConnections>
</dc-usermanagement>

This option is equivalent to the manual procedure described here Synchronizing users and groups in Decision Center

The group-security-configurations.xml file automatically populates the groups and users under the Decision Center Administration tab to map roles to groups.

For example,

<dc-usermanagement>
        <role name="rtsAdministrator"/>
        <role name="rtsConfigManager"/>
        <role name="rtsInstaller"/>
        <role name="rtsUser"/>


        <group name="rtsAdministrators" roles="rtsAdministrator"/>
        <group name="rtsConfigManagers" roles="rtsConfigManager"/>
        <group name="rtsInstallers" roles="rtsInstaller"/>
        <group name="rtsUsers" roles="rtsUser"/>
        
        <user name="odmAdmin" groups="rtsAdministrators, rtsInstallers, rtsConfigManagers, rtsUsers"/>
        <user name="rtsAdmin" groups="rtsAdministrators, rtsInstallers, rtsConfigManagers, rtsUsers"/>
        <user name="rtsConfig" groups="rtsConfigManagers, rtsUsers"/>
        <user name="rtsUser1" groups="rtsUsers"/>
        <user name="rtsUser2" groups="rtsUsers"/>
</dc-usermanagement>

Pass the name of your secret as the value for the customization.authSecretRef parameter when you create the ODM instance.

Attention: The secret must be specified when you create the ODM instance, otherwise the user access is not configured.