Configuring a OpenID Connect identity provider

    You can configure a Keycloak server as an OpenID Connect identity provider for OKD.

    ID Token and UserInfo decryptions are not supported.

    By default, the openid scope is requested. If required, extra scopes can be specified in the extraScopes field.

    Claims are read from the JWT id_token returned from the OpenID identity provider and, if specified, from the JSON returned by the UserInfo URL.

    At least one claim must be configured to use as the user’s identity. The standard identity claim is sub.

    You can also indicate which claims to use as the user’s preferred user name, display name, and email address. If multiple claims are specified, the first one with a non-empty value is used. The standard claims are:

    ClaimDescription

    sub

    Short for “subject identifier.” The remote identity for the user at the issuer.

    preferred_username

    The preferred user name when provisioning a user. A shorthand name that the user wants to be referred to as, such as janedoe. Typically a value that corresponding to the user’s login or username in the authentication system, such as username or email.

    email

    Email address.

    name

    Display name.

    See the for more information.

    Using an OpenID Connect identity provider requires users to get a token using <master>/oauth/token/request to use with command-line tools.

    Creating the secret

    Identity providers use OKD Secret objects in the openshift-config namespace to contain the client secret, client certificates, and keys.

    Procedure

    • Create a Secret object containing a string by using the following command:

      You can alternatively apply the following YAML to create the secret:

      1. apiVersion: v1
      2. kind: Secret
      3. metadata:
      4.   name: <secret_name>
      5.   namespace: openshift-config
      6. type: Opaque
      8.   clientSecret: <base64_encoded_client_secret>

    • You can define a Secret object containing the contents of a file, such as a certificate file, by using the following command:

      1. $ oc create secret generic <secret_name> --from-file=<path_to_file> -n openshift-config

    Identity providers use OKD ConfigMap objects in the openshift-config namespace to contain the certificate authority bundle. These are primarily used to contain certificate bundles needed by the identity provider.

    Procedure

    • Define an OKD ConfigMap object containing the certificate authority by using the following command. The certificate authority must be stored in the ca.crt key of the ConfigMap object.

      You can alternatively apply the following YAML to create the config map:

      1. apiVersion: v1
      2. kind: ConfigMap
      3.   name: ca-config-map
      4.   namespace: openshift-config
      5. type: Opaque
      6. data:
      7.   ca.crt: |
      8.     <CA_certificate_PEM>

    Sample OpenID Connect CRs

    The following custom resources (CRs) show the parameters and acceptable values for an OpenID Connect identity provider.

    If you must specify a custom certificate bundle, extra scopes, extra authorization request parameters, or a userInfo URL, use the full OpenID Connect CR.

    Standard OpenID Connect CR

    1. apiVersion: config.openshift.io/v1
    2. kind: OAuth
    3. metadata:
    4.   name: cluster
    5. spec:
    6.   identityProviders:
    7.   - name: oidcidp (1)
    8.     mappingMethod: claim (2)
    10.     openID:
    11.       clientID: ... (3)
    12.       clientSecret: (4)
    13.         name: idp-secret
    14.       claims: (5)
    15.         - preferred_username
    16.         name:
    17.         - name
    18.         email:
    19.         - email
    20.       issuer: https://www.idp-issuer.com (6)
    1This provider name is prefixed to the value of the identity claim to form an identity name. It is also used to build the redirect URL.
    2Controls how mappings are established between this provider’s identities and User objects.
    3The client ID of a client registered with the OpenID provider. The client must be allowed to redirect to https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name&gt;.
    4Reference to an OKD Secret object containing the client secret.
    5List of claims to use as the identity. First non-empty claim is used. At least one claim is required. If none of the listed claims have a value, authentication fails. For example, this uses the value of the sub claim in the returned id_token as the user’s identity.
    6 described in the OpenID spec. Must use https without query or fragment component.

    Full OpenID Connect CR

    Additional resources

    After you install your cluster, add an identity provider to it so your users can authenticate.

    Prerequisites

    • Create the custom resource (CR) for your identity providers.

    • You must be logged in as an administrator.

    Procedure

    1. Apply the defined CR:

      1. $ oc apply -f </path/to/CR>

      If a CR does not exist, oc apply creates a new CR and might trigger the following warning: Warning: oc apply should be used on resources created by either oc create —save-config or oc apply. In this case you can safely ignore this warning.

    2. Obtain a token from the OAuth server.

      As long as the kubeadmin user has been removed, the oc login command provides instructions on how to access a web page where you can retrieve the token.

      You can also access this page from the web console by navigating to (?) Help → Command Line Tools → Copy Login Command.

    3. Log in to the cluster, passing in the token to authenticate.

      1. $ oc login --token=<token>

      If your OpenID Connect identity provider supports the resource owner password credentials (ROPC) grant flow, you can log in with a user name and password. You might need to take steps to enable the ROPC grant flow for your identity provider.

      After the OIDC identity provider is configured in OKD, you can log in by using the following command, which prompts for your user name and password:

    4. Confirm that the user logged in successfully, and display the user name.

    Configuring identity providers using the web console

    Configure your identity provider (IDP) through the web console instead of the CLI.

    Prerequisites

    • You must be logged in to the web console as a cluster administrator.

    Procedure

    1. Navigate to Administration → Cluster Settings.

    2. Under the Global Configuration tab, click OAuth.

    You can specify multiple IDPs through the web console without overwriting existing IDPs.