4.9. Configuring a OpenID Connect identity provider
Configure an oidc
identity provider to integrate with an OpenID Connect identity provider using an Authorization Code Flow.
You can configure Red Hat Single Sign-On as an OpenID Connect identity provider for OpenShift Container Platform.
The Authentication Operator in OpenShift Container Platform requires that the configured OpenID Connect identity provider implements the OpenID Connect Discovery specification.
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:
Claim | Description |
---|---|
| Short for "subject identifier." The remote identity for the user at the issuer. |
|
The preferred user name when provisioning a user. A shorthand name that the user wants to be referred to as, such as |
| Email address. |
| Display name. |
See the OpenID claims documentation 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.
4.9.1. About identity providers in OpenShift Container Platform
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.
OpenShift Container Platform user names containing /
, :
, and %
are not supported.
4.9.2. Creating the secret
Identity providers use OpenShift Container Platform Secret
objects in the openshift-config
namespace to contain the client secret, client certificates, and keys.
You can define an OpenShift Container Platform
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 define an OpenShift Container Platform
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
4.9.3. Creating a config map
Identity providers use OpenShift Container Platform 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.
This procedure is only required for GitHub Enterprise.
Procedure
Define an OpenShift Container Platform
ConfigMap
object containing the certificate authority by using the following command. The certificate authority must be stored in theca.crt
key of theConfigMap
object.$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
4.9.4. 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 OpenShift Container Platform
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 returnedid_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 OpenShift Container Platform 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.
4.9.5. Adding an identity provider to your clusters
After you install your cluster, add an identity provider to it so your users can authenticate.
Prerequisites
- Create an OpenShift Container Platform 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, theoc 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. Log in to the cluster, passing in the token to authenticate.
$ 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 OpenShift Container Platform, 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
4.9.6. 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 Global 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.