OIDC and OAuth identity providers

You can use Open ID Connect or OAuth 2.0 authentication to manage user access and enable automatic registration of users for your environment.

Traditional Content Platform Engine installations require an LDAP directory service to manage access for users and groups. In V5.5.5 and later, an LDAP service is still required to define administrative users and groups and certain groups required by the Process Engine, but you also have the option to use OIDC or OAuth identity providers to manage authentication for the majority of users of your system. Multiple providers can be used to support users who authenticate in different ways.

Users who are authenticated by an OIDC or OAuth provider must be registered with the Content Platform Engine domain before they can be authorized to access resources within that domain. A user who has been so registered is referred to as a managed user, because the Content Platform Engine is managing the identity information it needs for that user by storing it in the Global Configuration Database (GCD).

New managed users can be registered by existing users or, if enabled for the domain, might be able to register themselves. In the former case, the managed user is considered provisional until that user accesses the domain for the first time, at which point that user record becomes confirmed. The records for users who register themselves are placed directly into the confirmed state. The domain administrator can configure settings to have records which have remained provisional removed after a certain period of time, for example to clean up records where the identity information has been entered incorrectly.

Important: Registration is by the email address of the user, and the email address must be unique not only across all managed users, but also must not collide with the short name of any LDAP user or group. Configuration settings called identity rules can restrict which email addresses can be registered as managed users and control which users can register themselves.

The overall setup for using an OIDC/OAuth identity provider is to do the following steps:

Configure an LDAP directory service, which is required for administrator authentication. This service does not need to be as substantial a service as might typically be required to provide authentication for all users of the system.
Configure your identity providers.
Register your client services, for example, Content Platform Engine and IBM® Content Navigator, with the identity provider, and prepare for secure connection with the identity provider.
Deploy your applications.
Configure a Managed User realm in the Administration Console for Content Platform Engine. Add identity rules to the realm as needed to control access.
Add or remove users in the realm, or change user settings as needed. You can control access levels for users by adding them manually in the realm.

Why use an identity provider and a managed user realm?

This method of authentication enables the following use cases:

Restricting access by realm: You can create a managed user realm and specify which email address can be registered in that realm.
Automatic registration of users: The Allow Self Registration identity rule allows a user whose email address matches the rule to register themselves rather than requiring an existing user to register for them.

Blocking email suffixes by realm: You can use the Block identity rule to prevent sets of users from being registered.

Managed realms

A managed user could be a Content Cortex domain user (internal user) or an external user created by External Share. Each managed user belongs to a managed realm, which in turn corresponds to a Managed directory configuration. There can be one or more such realms, and identity rules determine in which realm a particular email address should be registered.

Multiple realms would usually be configured in order to control security differently for users assigned to each realm, via the #REALM_USERS and #AUTHENTICATED-USERS pseudo-groups. For example, if external sharing is being used then one would normally have one realm for the external users and one for internal (if both types of user are authenticated through OIDC/OAuth). Other examples where more than one realm might be appropriate are given later.

Restrictions

(V5.5.4 and later) External Share for containers is supported.
(V5.5.5 and later) External Share for traditional WebSphere® Application Server environment is supported.
(V5.5.5 to V5.5.7) Automatic registration for internal users is only supported in a container environment.
In V5.5.7 IF001, self registration is supported on traditional WebSphere Application Server.
Internal user management with an identity provider and automatic registration for internal users is supported only in new installations and domains. There is no migration path from an existing LDAP-based domain to a domain that uses an identity provider.
You must have an LDAP directory server configuration along with your identity provider in order to manage the admin users and groups.
There is no grouping mechanism for managed users. Access can be assigned to managed users only individually or as follows:
- The #REALM-USERS(<realm name>) can be used to grant access to all users of the specified managed realm.
- The #AUTHENTICATED-USERS group can include the managed realm by setting the Property “Exclude from Authenticated Users” set to False for the realm.

PE workflow

If you plan to use the workflow system, you must configure the PE Administrator Group as an LDAP group. If you want to allow managed users to be able to perform PE Configuration functions like designing workflow and transfer, do not assign a PE Configuration Group.

Use Workflow Groups to specify users within the workflow.

Note: A user cannot be added to a workflow unless they exist in a realm. Users that have not self-registered can be added as provisional users within the realm to allow the launching of a workflow.

The #REALM-USER or #AUTHENTICATED_USERS are not able to be added to the workflow READ, WRITE or CREATE security for Queues, Rosters, or Logs and should not be since they have many users associated with them. Individual users can be assigned as ACLs. Security on the object store and connection point can be used to allow or restrict access to a workflow system.

Thick client PEDesigner and all other thick client tools, including FileNet® Deployment Manager are only available for LDAP users logging in with user name and password. Managed users are unable to use these tools.