Chapter 4. Identity providers overview

4.1. Understanding identity providers
Copiar enlace

Red Hat OpenShift Service on AWS includes a built-in OAuth server. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. As an administrator, you can configure OAuth to specify an identity provider after you install your cluster. Configuring identity providers allows users to log in and access the cluster.

4.1.1. Supported identity providers
Copiar enlace

You can configure the following types of identity providers:

Expand

Identity provider	Description
GitHub or GitHub Enterprise	Configure a GitHub identity provider to validate usernames and passwords against GitHub or GitHub Enterprise’s OAuth authentication server.
GitLab	Configure a GitLab identity provider to use GitLab.com or any other GitLab instance as an identity provider.
Google	Configure a Google identity provider using Google’s OpenID Connect integration.
LDAP	Configure an LDAP identity provider to validate usernames and passwords against an LDAPv3 server, using simple bind authentication.
OpenID Connect	Configure an OpenID Connect (OIDC) identity provider to integrate with an OIDC identity provider using an Authorization Code Flow.
htpasswd	Configure an htpasswd identity provider for a single, static administration user. You can log in to the cluster as the user to troubleshoot issues.

4.1.2. Identity provider parameters
Copiar enlace

The following parameters are common to all identity providers:

Expand

Parameter Description

Parameter	Description
`name`	The provider name is prefixed to provider user names to form an identity name.
`mappingMethod`	Defines how new identities are mapped to users when they log in. Enter one of the following values: claim The default value. Provisions a user with the identity’s preferred user name. Fails if a user with that user name is already mapped to another identity. lookup Looks up an existing identity, user identity mapping, and user, but does not automatically provision users or identities. This allows cluster administrators to set up identities and users manually, or using an external process. Using this method requires you to manually provision users. add Provisions a user with the identity’s preferred user name. If a user with that user name already exists, the identity is mapped to the existing user, adding to any existing identity mappings for the user. Required when multiple identity providers are configured that identify the same set of users and map to the same user names.

name

The provider name is prefixed to provider user names to form an identity name.

mappingMethod

Defines how new identities are mapped to users when they log in. Enter one of the following values:

claim: The default value. Provisions a user with the identity’s preferred user name. Fails if a user with that user name is already mapped to another identity.
lookup: Looks up an existing identity, user identity mapping, and user, but does not automatically provision users or identities. This allows cluster administrators to set up identities and users manually, or using an external process. Using this method requires you to manually provision users.
add: Provisions a user with the identity’s preferred user name. If a user with that user name already exists, the identity is mapped to the existing user, adding to any existing identity mappings for the user. Required when multiple identity providers are configured that identify the same set of users and map to the same user names.

Note

When adding or changing identity providers, you can map identities from the new provider to existing users by setting the mappingMethod parameter to add.

4.2. Configuring a GitHub identity provider
Copiar enlace

Configure a GitHub identity provider to validate user names and passwords against GitHub or GitHub Enterprise’s OAuth authentication server and access your Red Hat OpenShift Service on AWS cluster. OAuth facilitates a token exchange flow between Red Hat OpenShift Service on AWS and GitHub or GitHub Enterprise.

Warning

Configuring GitHub authentication allows users to log in to Red Hat OpenShift Service on AWS with their GitHub credentials. To prevent anyone with any GitHub user ID from logging in to your Red Hat OpenShift Service on AWS cluster, you must restrict access to only those in specific GitHub organizations or teams.

Prerequisites

The OAuth application must be created directly within the GitHub organization settings by the GitHub organization administrator.
GitHub organizations or teams are set up in your GitHub account.

Procedure

From OpenShift Cluster Manager, navigate to the Cluster List page and select the cluster that you need to configure identity providers for.
Click the Access control tab.
Click Add identity provider.
Note
You can also click the Add Oauth configuration link in the warning message displayed after cluster creation to configure your identity providers.
Select GitHub from the drop-down menu.
Enter a unique name for the identity provider. This name cannot be changed later.
- An OAuth callback URL is automatically generated in the provided field. You will use this to register the GitHub application.
  https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
  For example:
  https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
Register an application on GitHub.
Return to Red Hat OpenShift Service on AWS and select a mapping method from the drop-down menu. Claim is recommended in most cases.
Enter the Client ID and Client secret provided by GitHub.
Enter a hostname. A hostname must be entered when using a hosted instance of GitHub Enterprise.
Optional: You can use a certificate authority (CA) file to validate server certificates for the configured GitHub Enterprise URL. Click Browse to locate and attach a CA file to the identity provider.
Select Use organizations or Use teams to restrict access to a particular GitHub organization or a GitHub team.
Enter the name of the organization or team you want to restrict access to. Click Add more to specify multiple organizations or teams that users can be a member of.
Click Confirm.

Verification

The configured identity provider is now visible on the Access control tab of the Cluster List page.

4.3. Configuring a GitLab identity provider
Copiar enlace

Configure a GitLab identity provider to use GitLab.com or any other GitLab instance as an identity provider.

Prerequisites

If you use GitLab version 7.7.0 to 11.0, you connect using the OAuth integration. If you use GitLab version 11.1 or later, you can use OpenID Connect (OIDC) to connect instead of OAuth.

Procedure

From OpenShift Cluster Manager, navigate to the Cluster List page and select the cluster that you need to configure identity providers for.
Click the Access control tab.
Click Add identity provider.
Note
You can also click the Add Oauth configuration link in the warning message displayed after cluster creation to configure your identity providers.
Select GitLab from the drop-down menu.
Enter a unique name for the identity provider. This name cannot be changed later.
- An OAuth callback URL is automatically generated in the provided field. You will provide this URL to GitLab.
  https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
  For example:
  https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/gitlab
Add a new application in GitLab.
Return to Red Hat OpenShift Service on AWS and select a mapping method from the drop-down menu. Claim is recommended in most cases.
Enter the Client ID and Client secret provided by GitLab.
Enter the URL of your GitLab provider.
Optional: You can use a certificate authority (CA) file to validate server certificates for the configured GitLab URL. Click Browse to locate and attach a CA file to the identity provider.
Click Confirm.

Verification

The configured identity provider is now visible on the Access control tab of the Cluster List page.

4.4. Configuring a Google identity provider
Copiar enlace

Configure a Google identity provider to allow users to authenticate with their Google credentials.

Warning

Using Google as an identity provider allows any Google user to authenticate to your server. You can limit authentication to members of a specific hosted domain with the hostedDomain configuration attribute.

Procedure

From OpenShift Cluster Manager, navigate to the Cluster List page and select the cluster that you need to configure identity providers for.
Click the Access control tab.
Click Add identity provider.
Note
You can also click the Add Oauth configuration link in the warning message displayed after cluster creation to configure your identity providers.
Select Google from the drop-down menu.
Enter a unique name for the identity provider. This name cannot be changed later.
- An OAuth callback URL is automatically generated in the provided field. You will provide this URL to Google.
  https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
  For example:
  https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/google
Configure a Google identity provider using Google’s OpenID Connect integration.
Return to Red Hat OpenShift Service on AWS and select a mapping method from the drop-down menu. Claim is recommended in most cases.
Enter the Client ID of a registered Google project and the Client secret issued by Google.
Enter a hosted domain to restrict users to a Google Apps domain.
Click Confirm.

Verification

The configured identity provider is now visible on the Access control tab of the Cluster List page.

4.5. Configuring a LDAP identity provider
Copiar enlace

Configure the LDAP identity provider to validate user names and passwords against an LDAPv3 server, using simple bind authentication.

Prerequisites

When configuring a LDAP identity provider, you will need to enter a configured LDAP URL. The configured URL is an RFC 2255 URL, which specifies the LDAP host and search parameters to use. The syntax of the URL is:

ldap://host:port/basedn?attribute?scope?filter

Expand

URL component	Description
`ldap`	For regular LDAP, use the string `ldap`. For secure LDAP (LDAPS), use `ldaps` instead.
`host:port`	The name and port of the LDAP server. Defaults to `localhost:389` for ldap and `localhost:636` for LDAPS.
`basedn`	The DN of the branch of the directory where all searches should start from. At the very least, this must be the top of your directory tree, but it could also specify a subtree in the directory.
`attribute`	The attribute to search for. Although RFC 2255 allows a comma-separated list of attributes, only the first attribute will be used, no matter how many are provided. If no attributes are provided, the default is to use `uid`. It is recommended to choose an attribute that will be unique across all entries in the subtree you will be using.
`scope`	The scope of the search. Can be either `one` or `sub`. If the scope is not provided, the default is to use a scope of `sub`.
`filter`	A valid LDAP search filter. If not provided, defaults to `(objectClass=*)`

When doing searches, the attribute, filter, and provided user name are combined to create a search filter that looks like:

(&(<filter>)(<attribute>=<username>))

Important

If the LDAP directory requires authentication to search, specify a bindDN and bindPassword to use to perform the entry search.

Procedure

From OpenShift Cluster Manager, navigate to the Cluster List page and select the cluster that you need to configure identity providers for.
Click the Access control tab.
Click Add identity provider.
Note
You can also click the Add Oauth configuration link in the warning message displayed after cluster creation to configure your identity providers.
Select LDAP from the drop-down menu.
Enter a unique name for the identity provider. This name cannot be changed later.
Select a mapping method from the drop-down menu. Claim is recommended in most cases.
Enter a LDAP URL to specify the LDAP search parameters to use.
Optional: Enter a Bind DN and Bind password.
Enter the attributes that will map LDAP attributes to identities.
- Enter an ID attribute whose value should be used as the user ID. Click Add more to add multiple ID attributes.
- Optional: Enter a Preferred username attribute whose value should be used as the display name. Click Add more to add multiple preferred username attributes.
- Optional: Enter an Email attribute whose value should be used as the email address. Click Add more to add multiple email attributes.
Optional: Click Show advanced Options to add a certificate authority (CA) file to your LDAP identity provider to validate server certificates for the configured URL. Click Browse to locate and attach a CA file to the identity provider.
Optional: Under the advanced options, you can choose to make the LDAP provider Insecure. If you select this option, a CA file cannot be used.
Important
If you are using an insecure LDAP connection (ldap:// or port 389), then you must check the Insecure option in the configuration wizard.
Click Confirm.

Verification

The configured identity provider is now visible on the Access control tab of the Cluster List page.

4.6. Configuring an OpenID identity provider
Copiar enlace

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

Important

The Authentication Operator in Red Hat OpenShift Service on AWS requires that the configured OpenID Connect identity provider implements the OpenID Connect Discovery specification.

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

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

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:

Expand

Claim	Description
`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 OpenID claims documentation for more information.

Prerequisites

Before you configure OpenID Connect, check the installation prerequisites for any Red Hat product or service you want to use with your Red Hat OpenShift Service on AWS cluster.

Procedure

From OpenShift Cluster Manager, navigate to the Cluster List page and select the cluster that you need to configure identity providers for.
Click the Access control tab.
Click Add identity provider.
Note
You can also click the Add Oauth configuration link in the warning message displayed after cluster creation to configure your identity providers.
Select OpenID from the drop-down menu.
Enter a unique name for the identity provider. This name cannot be changed later.
- An OAuth callback URL is automatically generated in the provided field.
  https://oauth.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
  For example:
  https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/openid
Register a new OpenID Connect client in the OpenID identity provider by following the steps to create an authorization request.
Return to Red Hat OpenShift Service on AWS and select a mapping method from the drop-down menu. Claim is recommended in most cases.
Enter a Client ID and Client secret provided from OpenID.
Enter an Issuer URL. This is the URL that the OpenID provider asserts as the Issuer Identifier. It must use the https scheme with no URL query parameters or fragments.
Enter an Email attribute whose value should be used as the email address. Click Add more to add multiple email attributes.
Enter a Name attribute whose value should be used as the preferred username. Click Add more to add multiple preferred usernames.
Enter a Preferred username attribute whose value should be used as the display name. Click Add more to add multiple display names.
Optional: Click Show advanced Options to add a certificate authority (CA) file to your OpenID identity provider.
Optional: Under the advanced options, you can add Additional scopes. By default, the OpenID scope is requested.
Click Confirm.

Verification

The configured identity provider is now visible on the Access control tab of the Cluster List page.

4.7. Configuring an htpasswd identity provider
Copiar enlace

Configure an htpasswd identity provider to create a single, static user with cluster administration privileges. You can log in to your cluster as the user to troubleshoot problems. You can use the web user interface (UI) or your command-line interface (CLI) to create an htpasswd identity provider.

4.7.1. Configuring an htpasswd identity provider
Copiar enlace

You can create an htpasswd identity provider with the OpenShift Cluster Manager web user interface (UI).

Procedure

Select your cluster from the the Cluster List page on OpenShift Cluster Manager.
Select Access control Identity providers.
Click Add identity provider.
Select HTPasswd from the Identity Provider list.
Add a unique name in the Name field for the identity provider.
Use the suggested username and password for the static user, or create your own.
Note
You cannot retrieve the credentials defined in this step after you select Add in the following step. If you lose the credentials, you must recreate the identity provider and define the credentials again.
Select Add to create the htpasswd identity provider and the single, static user.
Grant the static user permission to manage the cluster:
1. Select Access control Cluster Roles and Access > Add user.
2. Enter the User ID of the static user that you created in the preceding step.
3. Select Add user to grant the administration privileges to the user.

Verification

The configured htpasswd identity provider is visible on the Access control Identity providers page.
Note
After creating the identity provider, synchronization usually completes within two minutes. You can log in to the cluster as the user after the htpasswd identity provider becomes available.
The single, administrative user is visible on the Access control Cluster Roles and Access page. The administration group membership of the user is also displayed.

4.7.2. Configuring an htpasswd identity provider with the CLI
Copiar enlace

You can create an htpasswd identity provider (IDP) with the ROSA command-line interface (CLI) (rosa) tool.

Prerequisites

You have installed and configured the latest version of the ROSA CLI.

Procedure

Run the following command to create an htpasswd IDP by passing the usernames and passwords in the command-line interface:
```
$ rosa create idp --type=htpasswd -c  <cluster_name> --users='user1:password1,user2:password2,user3:password3'
```
Note
The --users string value must be a comma separated list of username:password, within quotes like "user1:password" to create a user account with a name of user1 and a password of password. The quotes prevent your password from disrupting the Bash commands.
Passwords must include uppercase letters, lowercase letters, and numbers or symbols, specifically, ASCII-standard characters only. The password must be at least 14 characters.

4.7.2.1. Configuring an htpasswd identity provider with an htpasswd file
Copiar enlace

You can create an htpasswd identity provider (IDP) with the ROSA command-line interface (CLI) (rosa) tool and a well-formed htpasswd file.

Prerequisites

You have installed and configured the latest version of the ROSA CLI.

Procedure

Create a text file with a new row for each set of credentials with the username and password being colon separated like the following example:
```
johndoe:$apr1$hRY7OJWH$km1EYH.UIRj00000000/
janedoe:$apr1$Q58SO804$B/fECNWfn5F00000000/
```
Note
The htpasswd file is encrypted using APR1 hashing. For more information, see "Apache Password Formats" in the Additional resources.
```
$ rosa create idp --type=htpasswd -c <cluster_name> --from-file=myhtpassfile.txt
```

4.7.3. Configuring an htpasswd identity provider with Terraform
Copiar enlace

You can create an htpasswd identity provider (IDP) with Terraform.

Prerequisites

You have installed and configured the latest version of the ROSA CLI.
You have installed and configured the latest version of Terraform.

Procedure

Grant permissions to your account by using an offline Red Hat OpenShift Cluster Manager token.
Copy your offline token, and set the token as an environmental variable by running the following command:
```
$ export RHCS_TOKEN=<your_offline_token>
```
Note
This environmental variable resets at the end of each session, such as restarting your machine or closing the terminal.

Create the htpasswd_idp.tf file by running one of the following commands:

Option 1: To create a user with a generated, randomized password, run:

$ cat<<-EOF>htpasswd_idp.tf
  module "htpasswd_idp" {
    source = "terraform-redhat/rosa-hcp/rhcs//modules/idp"
    version = "1.6.2"

    cluster_id         = "2odpb9p344hnkfvpkluo00qmgkika78l"
    name               = "htpasswd-idp-tf-1"
    idp_type           = "htpasswd"
    htpasswd_idp_users = [{ username = "pej-user-d1", password = random_password.password.result }]
  }

  resource "aws_secretsmanager_secret" "idp_password" {
  name        = "idp-password-secret"
  description = "Any description here"
  }

  resource "random_password" "password" {
      length           = 16
      lower            = true
      special          = true
      override_special = "!#$%&*()-_=+[]{}<>:?"
  }

  # If you need to output the password, mark it as sensitive to hide from CLI logs
  output "password_output" {
      value     = random_password.password.result
      sensitive = true
  }

  # This section sends your credentials to your AWS Secrets Manager to enable you to log in to your cluster.
  resource "aws_secretsmanager_secret_version" "idp_password_val" {
  secret_id     = aws_secretsmanager_secret.idp_password.id
  secret_string = random_password.password.result
  }
EOF

You must replace the <cluster_id> placeholder with the 32-digit ID for your cluster. To find that value, run rosa list clusters | awk '{print $1}'. You also must replace the <user_name> placeholder with the username you want to create. The randomized password is then stored in your AWS Secrets manager to be used when logging in to the cluster.

Run the following command to view your password after setting it:
```
$ terraform output password_output
```
The CLI returns your generated password in plain text.

Option 2: To specify your passwords when creating a user, run:
```
$ cat<<-EOF>htpasswd_idp.tf
  module "htpasswd_idp" {
    source = "terraform-redhat/rosa-hcp/rhcs//modules/idp"
    version = "1.6.2"

    cluster_id         = "<cluster_id>"
    name               = "htpasswd-idp"
    idp_type           = "htpasswd"
    htpasswd_idp_users = [{ username="<user_name>",password="<password>"}]
  }
EOF
```
You must replace the <cluster_id> placeholder with the 32-digit ID for your cluster. To find that value, run rosa list clusters | awk '{print $1}'. You also must replace the <user_name> placeholder with the username you want to create as well as a password for the <password> placeholder.

Run the following command to set up Terraform to create your resources based on your Terraform files:
```
$ terraform init
```
Verify that the Terraform you copied is correct by running the following command:
```
$ terraform validate
```
Example output
```
Success! The configuration is valid.
```
Create your cluster with Terraform by running the following command:
```
$ terraform apply
```
Enter yes to proceed or no to cancel when the Terraform interface lists the resources to be created or changed and prompts for confirmation:
```
Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes
```
You see a confirmation that your IDP has been created.
```
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
```
Note
If you used the randomized password template, then the generated password is stored in your AWS Secrets manager.

Este contenido no está disponible en el idioma seleccionado.

4.1. Understanding identity providers
Copiar enlace

4.1.1. Supported identity providers
Copiar enlace

4.1.2. Identity provider parameters
Copiar enlace

4.2. Configuring a GitHub identity provider
Copiar enlace

4.3. Configuring a GitLab identity provider
Copiar enlace

4.4. Configuring a Google identity provider
Copiar enlace

4.5. Configuring a LDAP identity provider
Copiar enlace

4.6. Configuring an OpenID identity provider
Copiar enlace

4.7. Configuring an htpasswd identity provider
Copiar enlace

4.7.1. Configuring an htpasswd identity provider
Copiar enlace

4.7.2. Configuring an htpasswd identity provider with the CLI
Copiar enlace

4.7.2.1. Configuring an htpasswd identity provider with an htpasswd file
Copiar enlace

4.7.3. Configuring an htpasswd identity provider with Terraform
Copiar enlace

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Hacer que el código abierto sea más inclusivo

Acerca de Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Este contenido no está disponible en el idioma seleccionado.

Chapter 4. Identity providers overview

4.1. Understanding identity providersCopiar enlaceEnlace copiado en el portapapeles!

4.1.1. Supported identity providersCopiar enlaceEnlace copiado en el portapapeles!

4.1.2. Identity provider parametersCopiar enlaceEnlace copiado en el portapapeles!

4.2. Configuring a GitHub identity providerCopiar enlaceEnlace copiado en el portapapeles!

4.3. Configuring a GitLab identity providerCopiar enlaceEnlace copiado en el portapapeles!

4.4. Configuring a Google identity providerCopiar enlaceEnlace copiado en el portapapeles!

4.5. Configuring a LDAP identity providerCopiar enlaceEnlace copiado en el portapapeles!

4.6. Configuring an OpenID identity providerCopiar enlaceEnlace copiado en el portapapeles!

4.7. Configuring an htpasswd identity providerCopiar enlaceEnlace copiado en el portapapeles!

4.7.1. Configuring an htpasswd identity providerCopiar enlaceEnlace copiado en el portapapeles!

4.7.2. Configuring an htpasswd identity provider with the CLICopiar enlaceEnlace copiado en el portapapeles!

4.7.2.1. Configuring an htpasswd identity provider with an htpasswd fileCopiar enlaceEnlace copiado en el portapapeles!

4.7.3. Configuring an htpasswd identity provider with TerraformCopiar enlaceEnlace copiado en el portapapeles!

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Hacer que el código abierto sea más inclusivo

Acerca de Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.1. Understanding identity providers
Copiar enlace

4.1.1. Supported identity providers
Copiar enlace

4.1.2. Identity provider parameters
Copiar enlace

4.2. Configuring a GitHub identity provider
Copiar enlace

4.3. Configuring a GitLab identity provider
Copiar enlace

4.4. Configuring a Google identity provider
Copiar enlace

4.5. Configuring a LDAP identity provider
Copiar enlace

4.6. Configuring an OpenID identity provider
Copiar enlace

4.7. Configuring an htpasswd identity provider
Copiar enlace

4.7.1. Configuring an htpasswd identity provider
Copiar enlace

4.7.2. Configuring an htpasswd identity provider with the CLI
Copiar enlace

4.7.2.1. Configuring an htpasswd identity provider with an htpasswd file
Copiar enlace

4.7.3. Configuring an htpasswd identity provider with Terraform
Copiar enlace