IAM for your product platform users

Identity and Access Management (IAM) for platform users includes authentication that includes OIDC and SAML, and authorization that includes role-based access control, users management, and Cloud Resource Naming (CRN).


Your product uses WebSphere Liberty OpenID Connect (OIDC) 1.0 for authentication. It calls the standard OIDC endpoints /authorize and /token to initiate an OAuth dance. OpenID in Liberty can be configured with Lightweight Directory Access Protocol (LDAP), after which an LDAP user can authenticate to your product by using the same OpenID endpoints. For single sign-on (SSO) based authentication, OIDC is configured with Security Assertion Markup Language (SAML) to interact with your enterprise identity source.

Authentication protocols supported

Your product supports the following two authentication protocols:

  1. OIDC-based authentication

  2. SAML-based federated authentication

OIDC and SAML are both used for SSO with your product but for different purposes.

Your product is an OIDC identity provider that provides authentication and authorization services to your product console and APIs. It works along with one or more LDAP providers to authenticate the user ID and password with the LDAP service and to provide an access token for subsequent requests to your product services. Your product is an identity provider through LDAP.

Your product can be configured as a SAML service provider, which allows federated authentication with an external SAML 2.0 identity provider. When you configure SSO, your product redirects your console browser to the third-party login page, and OIDC issues you a bearer token.

The OIDC-based authentication service is the default authentication service in your product. If required, you can configure a SAML server to provide federated authentication.

OIDC-based authentication

You must configure and connect an LDAP directory with your product cluster, and provide cluster administrator, Cloud Pak administrator, or administrator access level. For more information, see Configuring LDAP connection. You must set up the LDAP connection before you create a team and add users to the team. Only LDAP users who are assigned to a team can log in to the console.

For more information about creating a team, see Create teams. For more information about adding users to a team, see Add users to a team.

Authorization endpoint

If you want your application to call the console login page, you must use the following endpoint:


Token endpoint APIs

There are two token endpoints:

Ingresses are available for both endpoints, however, using the prefix is recommended. Using the prefix is also recommended for the following endpoints: https://<cluster_address>/oidc/endpoint/OP/token and https://<cluster_address>/idauth/oidc/endpoint/OP/token.

Note: The number 1 endpoint is recommended because it returns the encrypted token and works across all the APIs of your product. The decrypted token that is returned by /oidc/endpoint/OP/token won't work with all the APIs of your product. It can be used by a content service for authentication or by one that requires an OOTB OIDC provider.

SAML-Based authentication

Your product can be configured to use SAML-based authentication from an enterprise SAML server. For more information, see Configuring single sign-on.

Note: Your product does not support SSO login by using the CLI. After you configure SAML, you can log in as either the default admin user or as an LDAP user who is added to a team.

Lightweight Directory Access Protocol (LDAP) support

Your product can be configured with a single or multiple LDAP servers for the authentication and authorization. Your product supports the following LDAP types:

Configuring single sign-on

For more information, see Configuring single sign-on.

Configuring LDAPs

With your product, you can authenticate across multiple LDAPs. You can add multiple directory entries to the LDAP config in the server.xml file. Liberty automatically resolves the domain name from the login and authenticates against the targeted LDAP directory. Your product users and user groups are associated with an enterprise directory during the time of the user and user group onboarding via import. When the new LDAP directory entry is created, the domain name also gets added as a new entry. At the time of login, you can specify the domain against which the authentication should be validated.

It is possible to have a mix of directory types, for example AD, Tivoli, and OpenLDAP. Role-based access control (RBAC) is enforced on the LDAP domain. Cluster administrators and Cloud Pak administrators have access to all LDAP domains, whereas team administrators are restricted to only those domain(s) they are authorized to.

For more information, see Configuring LDAP connection.

Changing LDAP cache settings

For more information, see Changing LDAP cache settings.

Changing LDAP search settings

For more information, see Changing LDAP search settings.

Updating SCIM LDAP attributes mapping

For more information, see Updating SCIM LDAP attributes mapping.

Changing Logjam configuration property

For more information, see Changing Logjam configuration property.

Changing LDAP contextPool settings

For more information, see Changing LDAP contextPool settings.

Troubleshooting LDAP

For more information, see LDAP troubleshooting.


For more information, see Configuring LDAP connection.


Check the following topics for more information on authorization for platform users:

Your product and Kubernetes role-based access control (RBAC)

RBAC is enforced in your product through teams. A team is an entity that groups users and resources. The resources can be Kubernetes type resources (like namespace, pod, and broker) or non-Kubernetes type, such as Helm chart, DB instance, and cloud connection. The assignment of the resources to the team happens through the resource CRNs. The responsible services have to expose the resource CRNs through an API so that they become available on the team's Add Resource dialogue. The Kubernetes resources, such as the namespaces, are exposed through the https://<cluster_address>/idmgmt/identity/api/v1/teams/resources?resourceType=namespace API. It's possible to fetch the resources that are attached to a specific user through their teams by using the https://<cluster_address>/idmgmt/identity/api/v1/teams/resources API.

For more information, see role-based access control and teams.

CRN specification

Your product follows the CRN convention: crn:version:cname:ctype:service-name:region:scope:service-instance:resource-type:resource-instance.

The following CRN attribute definitions are specific to your product platform services:

Other attributes are service-specific.

Your product defines the following constructs for applications based on:

  1. Kubernetes platform
  2. Workloads
  3. Cloud Foundry Enterprise Environment platform

CRNs for Kubernetes resources

The region / cluster-id is set to the cluster_name parameter. The default, when not specified is `mycluster'.


CRNs for service catalog resources

crn:v1:icp:private:k8:mycluster:::clusterserviceclass:csc123 (to be changed to: crn:v1:icp:private:k8:mycluster:sc/csc123::::)

CRNs for your product IAM roles


CRNs for logging and monitoring resources


CRNs for Helm resources


Event streams


CRNs for user defined workloads


CRNs for Key Management Service


CRN examples for workloads hosted on your product platform

scope - repo, pod, user-defined


CRN for application that is hosted on the Cloud Foundry Enterprise Environment platform

scope - account, org, space