You can use an identity provider to manage user authentication for your container
environment. You can use this approach to manage and automatically register both internal users and
users that you designate for external sharing of items.
Check the IBM® Software Product Compatibility Report for the
appropriate versions of supporting software.
About this task
To prepare this connection for your container environment, you set up your identity provider,
register your clients with the identity provider, and create secrets with your connection
credentials. To register your clients- at a minimum, Content Platform Engine and Navigator- you must
provide a redirect URI for each component in the following
format:https://ingress-cpe:<hostname>
.
When you prepare your environment, record the settings so that these values are available to
enter into the custom resource YAML file for deployment and configuration. For lists of the
parameters that you need to collect, see Identity provider
configuration parameters.
After you configure your identity provider connection and provide the relevant details in your
custom resource YAML file, the operator creates the identity provider configuration for your
container environment.
To configure the identity provider connection:
- Prepare a draft redirect URL value to use when you register your components as clients of
the identity provider.
When registering an application with an Identity Provider, you can
use the same clientId registration for each of the IBM® Content Navigator, External Share, and
Content Platform Engine instances in your environment. You must provide a redirect URL for each of
these instances using the following pattern:
https://ingress.es-<ingress_host>/oidcclient/redirect/<Provider ID for each instance>
You
confirm the values for these redirect URLs after your container deployment completes. At that
time you determine the final URL and reset the URL values with the identity provider.
- Create your identity provider application.
Remember: Check the Software Product Compatibility Report for details on what identity
providers are supported.
- Register your components as clients of the identity provider that you
configured.
-
On your cluster, create an identity provider secret with the client ID and client secret from
the identity provider:
kubectl create secret generic ibm-scim-secret \
--from-literal=client_id="<client ID from your IdP>" \
--from-literal=client_secret="<client secret from your IdP>"
- Create additional secrets with the certificates from the identity provider.
- Contact the identity provider administrator to get the certificate or instructions to
download the certificate.
- Save the certificate file to a location in your container environment.
- From the directory where the downloaded certificate file is located, run the following
command:
kubectl create secret generic <secret name> --from-file=tls.crt=<CERT FILE_NAME> -n <namespace>
For example, for
Google:
oc create secret generic gmail-tls --from-file=tls.crt=gmail_tls2.cert -n <namespace>
When you add your values to the custom resource YAML file, add the secret name as the value for
trusted_certificate_list
, and include the square brackets around the secret
name.
shared_configuration:
…
tls:
trusted_certificate_list: [gmail-tls]
- Compile the values to add to the custom resource YAML file that you will use for
deployment:
For example:
shared_configuration:
open_id_connect_providers:
- provider_name: "ExShareGID"
display_name: "Google"
client_oidc_secret:
nav: "sample-oidc-google-secret" # Points to a secret with client_id and client_secret in that format.
cpe: "sample-oidc-google-secret" # Points to a secret with client_id and client_secret in that format..
issuer_identifier: "https://accounts.google.com"
# REQUIRED PROPERTIES AND VALUES which are common
# If not set will be set to the defaults.
response_type: "id_token token"
scope: "openid email profile"
map_identity_to_registry_user: "false"
authn_session_disabled: "true"
inbound_propagation: "supported"
https_required: "true"
validation_method: "introspect"
disable_ltpa_cookie: "true"
signature_algorithm: "RS256"
user_identifier: "email" # sub for ums and ibm id, email for google
unique_user_identifier: "email" # sub for ums and ibm id, email for google
user_identity_to_create_subject: "email" # sub for ums and ibm id, email for google
# Uncomment out discovery_endpoint_url for Google or UMS IdP.
discovery_endpoint_url: "https://accounts.google.com/.well-known/openid-configuration"
# authorization_endpoint_url: ""
# token_endpoint_url: ""
# validation_endpoint_url: ""
# trust_alias_name: "secrent name you created"
# disables_iss_checking: "true"
# jwk_client_oidc_secret:
# es: "" # Points to a secret with client_id and client_secret in that format.
# nav: "" # Points to a secret with client_id and client_secret in that format.
# cpe: "" # Points to a secret with client_id and client_secret in that format.
# graphql: ""
# token_reuse: "true"
# oidc_ud_param:
# - 'DELIM=;KEY1;value1'
# - "key2:value2"
The sample is specifically for Google ID. The sample
provides the common shared parameters required for most IdPs, but each IdP may need different
parameters added or removed. You can refer to your specific IdP documentation for the exact
parameters and uncomment or add in parameters accordingly in the CR file.
If you have more
than one identity provider, you add a stanza and record values for each provider. For more
information on the parameters and values, see Identity provider configuration parameters.
If any required parameters are
not provided in the sample, you can add them as a list of strings such as 'key:value' in the
oidc_ud_param
:
oidc_ud_param:
- 'DELIM=;KEY1;value1'
- "key2:value2"
The operator splits the string by the default delimiter,
a colon (:). If the value of a required parameter contains a colon (:), such as in a URL, you can
specify
'DELIM=<delim>KEY<delim>VALUE'
instead, for
example:
'DELIM=;myURLKey;https://myurl.com'
In this case, the operator
would output the parameter pair as
follows:
myURLKey="https://myurl.com"