Configuring an identity provider connection

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.

Before you begin

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.

Procedure

To configure the identity provider connection:

  1. 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.
  2. Create your identity provider application.
    Remember: Check the Software Product Compatibility Report for details on what identity providers are supported.
  3. Register your components as clients of the identity provider that you configured.
  4. 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>" 
  5. Create additional secrets with the certificates from the identity provider.
    1. Contact the identity provider administrator to get the certificate or instructions to download the certificate.
    2. Save the certificate file to a location in your container environment.
    3. 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]
  6. 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"