Platform and Cloud Pak

User Management Services in IBM Cloud Pak for Automation

By Georg Sander posted Mon January 11, 2021 10:05 AM

  

Authors: Georg Sander, Andrea Baader, Jens Engelke, Larissa Auberger

IBM Cloud Pak for Automation is IBM’s Cloud solution for various kind of business automation. It can be deployed virtually anywhere and is also available as IBM-managed software as a service (Saas). It consists of multiple components that can roughly be categorized into

  • Document Processing
  • Content Management
  • Automated Decision Processing
  • Workflows and Business Process Management
  • Task Automation with bots

To achieve secure interoperability between these components, it is essential that all components can work with the same user base. As an example, a user may want to design a workstream that needs to access the content management component in order to later branch the workflow based on automated decisions. This is only possible if that user can access the IBM Business Automation Application Designer, the IBM Filenet Content Manager and the IBM Operational Decision Manager (ODM) in a uniform way and when each of these components can invoke other microservices “on behalf of” this current user.

User Management Overview

That’s where the user management services come into play. The user management services (UMS) of the IBM Cloud Pak for Automation ensure that the transition between the different applications is seamless; in fact, the user may have the impression he is working only with one application while in reality, it is a mix of applications and microservices that interact with each other.

The UMS services

The IBM Cloud Pak for Automation is an integrated set of software capabilities that automate work to improve the effectiveness and productivity of employees. The User Management Services contribute to that effectiveness and productivity in various ways as an elementary part that most of the time covertly shows its strength. The average user won’t be aware that these services are actively working to support him or her, but these service ensure, for instance, that users need to authenticate only once to access and perform their work. These services also help to coordinate and manage work of teams, so that teams can efficiently work on common goals. While software operators and user administrators will deal with these services directly, normal users can enjoy the fact that things just magically work without the need to look into the details.

This article will however expose some details of the user management services. They can be divided in the following topics:

  • Authentication and Single Sign On
  • User Registry Service
  • Team Service to support authorization decisions
  • Other services for user data

Authentication and Single Sign On

A uniform user experience requires that no matter to which component you log in, you always see the same login screen. This gives the user the impression that he logs into a common platform, not into individual services. Once the user is logged in, he has access to all components. This behavior is called single sign on.

The UMS Services provide the common login page and handle all aspects of the single sign on. It utilizes a protocol standard called OpenID Connect, which is based on the OAuth 2.0 protocol. The OpenID Connect standard defines various token-based authentication flows. These allow the components to detect whether the current user is already logged in by another component, or to inject the login page when needed. For details on OpenID Connect and its advantages, see https://openid.net/connect/.

The UMS Services also provide a bridge to the Basic Authentication standard. This is an alternative to OpenID Connect that was commonly used on the web before OAuth was invented. To achieve interoperability with older clients, Basic Authentication is supported by some selected APIs. The Basic Authentication bridge is implemented via a trust association interceptor UMS Basic Authentication TAI in Business Automation Workflow, Workstream Services and Studio.

Automated services are not always associated with users. For instance, there are long-running system processes that are active even when no user is active, for instance to clean up data overnight. Therefore, automated services need to be able to trigger a login context switch, i.e. they need to automatically log in as a different system account. In Java components, the JAAS standard is commonly used to implement such login context switches. The UMS Services provide a UMS JAAS Login Module to support login context switches for system accounts. Several components in Cloud Pak for Automation create system accounts in UMS in addition to LDAP users.

User Registry Service

The user registry contains the users that have permission to log into the IBM Cloud Pak for Automation. This is always implemented by an LDAP server. The user registry can contain group information for users and additional attributes, such as an email. Larger companies often have an LDAP server for their employee directory that can be bound directly to the Cloud Pak. While LDAP itself is a protocol, it is more convenient for components to access user registry information over REST. Since this is a functionality that not every LDAP server supports, the Cloud Pak services include a UMS SCIM service. SCIM (System for Cross-domain Identity Management) is a powerful standard to access the user registry over REST, which is commonly adopted in cloud-based applications. For details about SCIM, see http://www.simplecloud.info/.

The full SCIM API allows read and write access to the user registry. The IBM Cloud Pak for Automation uses only read access, to avoid permission and security concerns when customers integrate the IBM Cloud Pak for Automation into their application infrastructure. In a typical company-wide LDAP, only an administrator team has write access to the data of the LDAP server. The IBM Cloud Pak for Automation does not need to play the administrator role for the user registry, hence the SCIM support in the user management services is limited to the need of the Cloud Pak.

Providing SCIM for components in Cloud Pak for Automation ensures a consistent view on the user population for all consumers of the API. It avoids the need for and possible errors associated with configuring an LDAP connection for many components in different technologies.

Teams Service

For authorization decisions, it is convenient to group users. This allows to assign the access permission regarding a certain resource to the entire group, instead of assigning permissions to individual users. There are two possibilities to implement such user groups: LDAP groups handled by the LDAP server, and teams handled by the UMS Teams service. This service can be considered as an intermediate facility between LDAP and IBM Cloud Pak components.

There are several reasons why introducing a teams service has benefits:

  • The UMS Teams service provides a specialized REST API that is optimized for the needs of authorization decisions. Different to the SCIM service, this REST API covers also write access in addition to the read access.
  • Customers often do not want to modify their LDAP groups for temporary needs of global teams, in particular when they are using a company-wide LDAP server. The UMS Teams service allows to model dedicated, shorter living teams for specific business needs of the IBM Cloud Pak, while LDAP groups are usually long-living. Furthermore, teams can be administered and edited independent of an LDAP administrator.
  • The UMS Teams service allows to model authorization behavior among teams themselves, which is more flexible than the capabilities of LDAP groups.

A team of the UMS Teams service is essentially a collection of users and LDAP groups. Teams can be nested, that is, a team can have multiple subteams, however a cyclic nesting (a team that contains itself as subteam) is not allowed.

Other services for user data

Cloud Pak components may have the need to store data associated to a user or team. An example are user preference settings. To make such settings interoperable with all Cloud Pak services, a common user profile service is desirable. In the current state (December 2020), the UMS Services of the Cloud Pak for Automation do not expose such a service yet, but as the Cloud Pak evolves, such a service would be a logical next step that we will certainly see in the future.

0 comments
23 views

Permalink