In IBM InfoSphere Information Server Suite, authentication is done against a user registry which by default is an internal registry stored in the Metadata repository. This however, can be altered to authenticate against an LDAP (Lightweight Directory Access Protocol) registry or the local operating system registry. Authentication happens at 2 levels in IBM InfoSphere Information Suite.
1. Authentication at services level – This controls the access to the shared services, repository and its contents
2. Authentication at engine level – Also referred to as Engine credentials, this controls access to the Engine.
This article discusses the factors to be considered while deciding on user registry for IBM InfoSphere Information Server Suite. We are going to discuss the level of difficulty for each of the following factors.
1. Installation and setup – The ease of configuring the IBM IIS suite to work with an independent user registry
2. Maintenance – How much effort is required by my team to maintain the integration of IIS Suite to external registry?
3. Scalability and flexibility – Is the integration scalable when the number of users increase and how can authentication be managed
4. Engine Authentication – The ease with which the Engine credentials can be integrated with external registry
We have 4 different options for configuring the user registry as shown in the screenshot below.
1. Federated Repositories – This is the most versatile registry available. Federated repositories enable you to authenticate users against multiple user registries. This is suitable for a large scale enterprise where users may be scattered across multiple LDAP registries. In addition to the LDAP registries (which include Active Directory) federated repositories may also include the internal user registries which are created by default. User access can be controlled through groups in LDAP and there is no intervention required from the DataStage admin to grant access to a new user to DataStage. The federated repositories provide the flexibility of storing the DataStage service credentials in the internal registry and Users in various different LDAP registries. LDAP users may be restricted at an OU (Organizational Unit) level, at Group level or at an Individual user level. LDAP administrators are required for the maintenance of the LDAP registry.
2. Local operating system – This registry is used to restrict access to only local system users. This registry is rarely used. Since authentication is done at the operating system level, all the security features of the operating system apply to IBM InfoSphere Information server. Please note that this registry does not allow any LDAP users to access the Information Server Suite and allows only those users which are operating system only. This restriction makes this configuration the least flexible configuration, however, this also increases the security on the server due to the restricted access that it provides. The local Operating system registry might result in major performance issues in a Windows environment and is best avoided when InfoSphere is hosted on Windows.
3. Standalone LDAP registry – As the name implies this configuration has the registry on an LDAP server. This configuration provides low maintenance and moderate scalability. Creating a new user is as simple as creating a new user on the LDAP and adding the user to a group which has been provided access to the Suite. This however provides only one user registry for authentication and cannot provide authentication against multiple LDAP registries as is the case with Federated repositories. LDAP administrators are required for the maintenance of the LDAP registry.
4. Standalone custom registry – This is the default registry which is configured during installation of IBM InfoSphere Information Server Suite. This can also be extended to authenticate using PAM (Pluggable Authentication Module).
a. Internal registry only – This is simple to use and is the default configuration. The Metadata repository stores the credentials which are encrypted one-way. The registry however authenticates only the services tier and should be mapped manually to local operating system users for the engine tier. The internal registry does not support password policies and does not limit the false login attempts.
b. PAM authentication – While the internal registry is simple to use, inclusion of PAM increases the complexity of configuration. Authentication through PAM is done through files which stores the credentials and groups on the DataStage server. This configuration can be used for small scale installation. The maintenance for this system is high as the administrator will have to manually update the files every time a new user is created. Conflicts with PAM policies also create several maintenance issues requiring both a strong UNIX administrator and DataStage administrator to work closely.
The table listed below summarizes the above features and can be used for arriving a decision on which user registry to be considered for your installation.