Configuring an OpenID Connect identity provider - Configuring identity providers | Authentication and authorization

About identity providers in OKD
Creating the secret
Creating a config map
Sample OpenID Connect CRs
Adding an identity provider to your cluster
Configuring identity providers using the web console

Configure the oidc identity provider to integrate with an OpenID Connect identity provider using an Authorization Code Flow.

About identity providers in OKD

By default, only a kubeadmin user exists on your cluster. To specify an identity provider, you must create a custom resource (CR) that describes that identity provider and add it to the cluster.

OKD user names containing /, :, and % are not supported.

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:

$ oc create secret generic <secret_name> --from-literal=clientSecret=<secret> -n openshift-config

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

apiVersion: v1
kind: Secret
metadata:
  name: <secret_name>
  namespace: openshift-config
type: Opaque
data:
  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:
```
$ oc create secret generic <secret_name> --from-file=<path_to_file> -n openshift-config
```

Creating a config map

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.

$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: ca-config-map
  namespace: openshift-config
data:
  ca.crt: |
    <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

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: oidcidp (1)
    mappingMethod: claim (2)
    type: OpenID
    openID:
      clientID: ... (3)
      clientSecret: (4)
        name: idp-secret
      claims: (5)
        preferredUsername:
        - preferred_username
        name:
        - name
        email:
        - email
      issuer: https://www.idp-issuer.com (6)

1	This 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.
2	Controls how mappings are established between this provider’s identities and `User` objects.
3	The 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>`.
4	Reference to an OKD `Secret` object containing the client secret.
5	List 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	Issuer Identifier described in the OpenID spec. Must use `https` without query or fragment component.

Full OpenID Connect CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: oidcidp
    mappingMethod: claim
    type: OpenID
    openID:
      clientID: ...
      clientSecret:
        name: idp-secret
      ca: (1)
        name: ca-config-map
      extraScopes: (2)
      - email
      - profile
      extraAuthorizeParameters: (3)
        include_granted_scopes: "true"
      claims:
        preferredUsername: (4)
        - preferred_username
        - email
        name: (5)
        - nickname
        - given_name
        - name
        email: (6)
        - custom_email_claim
        - email
      issuer: https://www.idp-issuer.com

1	Optional: Reference to an OKD config map containing the PEM-encoded certificate authority bundle to use in validating server certificates for the configured URL.
2	Optional list of scopes to request, in addition to the `openid` scope, during the authorization token request.
3	Optional map of extra parameters to add to the authorization token request.
4	List of claims to use as the preferred user name when provisioning a user for this identity. First non-empty claim is used.
5	List of claims to use as the display name. First non-empty claim is used.
6	List of claims to use as the email address. First non-empty claim is used.

Additional resources

See Identity provider parameters for information on parameters, such as mappingMethod, that are common to all identity providers.

Adding an identity provider to your cluster

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

Prerequisites

Create an OKD cluster.
Create the custom resource (CR) for your identity providers.
You must be logged in as an administrator.

Procedure

Apply the defined CR:

$ 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.

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.

$ 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:

$ oc login -u <identity_provider_username> --server=<api_server_url_and_port>

Confirm that the user logged in successfully, and display the user name.
```
$ oc whoami
```

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

Navigate to Administration → Cluster Settings.
Under the Configuration tab, click OAuth.
Under the Identity Providers section, select your identity provider from the Add drop-down menu.

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

Configuring a OpenID Connect identity provider

About identity providers in OKD

Creating the secret

Creating a config map

Sample OpenID Connect CRs

Adding an identity provider to your cluster

Configuring identity providers using the web console