4.4. Configuring a basic authentication identity provider

4.4.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.4.2. About basic authentication
复制链接

Basic authentication is a generic back-end integration mechanism that allows users to log in to OpenShift Container Platform with credentials validated against a remote identity provider.

Because basic authentication is generic, you can use this identity provider for advanced authentication configurations.

重要

Basic authentication must use an HTTPS connection to the remote server to prevent potential snooping of the user ID and password and man-in-the-middle attacks.

With basic authentication configured, users send their user name and password to OpenShift Container Platform, which then validates those credentials against a remote server by making a server-to-server request, passing the credentials as a basic authentication header. This requires users to send their credentials to OpenShift Container Platform during login.

注意

This only works for user name/password login mechanisms, and OpenShift Container Platform must be able to make network requests to the remote authentication server.

User names and passwords are validated against a remote URL that is protected by basic authentication and returns JSON.

A 401 response indicates failed authentication.

A non-200 status, or the presence of a non-empty "error" key, indicates an error:

{"error":"Error message"}

{"error":"Error message"}

Copy to Clipboard

Toggle word wrap

A 200 status with a sub (subject) key indicates success:

{"sub":"userid"}

{"sub":"userid"}

1

Copy to Clipboard

Toggle word wrap

1: The subject must be unique to the authenticated user and must not be able to be modified.

A successful response can optionally provide additional data, such as:

A display name using the name key. For example:
```
{"sub":"userid", "name": "User Name", ...}
```
```
{"sub":"userid", "name": "User Name", ...}
```
Copy to Clipboard Toggle word wrap
An email address using the email key. For example:
```
{"sub":"userid", "email":"user@example.com", ...}
```
```
{"sub":"userid", "email":"user@example.com", ...}
```
Copy to Clipboard Toggle word wrap
A preferred user name using the preferred_username key. This is useful when the unique, unchangeable subject is a database key or UID, and a more human-readable name exists. This is used as a hint when provisioning the OpenShift Container Platform user for the authenticated identity. For example:
```
{"sub":"014fbff9a07c", "preferred_username":"bob", ...}
```
```
{"sub":"014fbff9a07c", "preferred_username":"bob", ...}
```
Copy to Clipboard Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

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
```
```
$ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config
```
Copy to Clipboard Toggle word wrap

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

Procedure

Define an OpenShift Container Platform 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
```
```
$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
```
Copy to Clipboard Toggle word wrap

4.4.5. Sample basic authentication CR
复制链接

The following custom resource (CR) shows the parameters and acceptable values for a basic authentication identity provider.

Basic authentication CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: basicidp 
    mappingMethod: claim 
    type: BasicAuth
    basicAuth:
      url: https://www.example.com/remote-idp 
      ca: 
        name: ca-config-map
      tlsClientCert: 
        name: client-cert-secret
      tlsClientKey: 
        name: client-key-secret

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: basicidp

1


    mappingMethod: claim

2


    type: BasicAuth
    basicAuth:
      url: https://www.example.com/remote-idp

3

ca:

4


        name: ca-config-map
      tlsClientCert:

5


        name: client-cert-secret
      tlsClientKey:

6


        name: client-key-secret

Copy to Clipboard

Toggle word wrap

1: This provider name is prefixed to the returned user ID to form an identity name.
2: Controls how mappings are established between this provider’s identities and User objects.
3: URL accepting credentials in Basic authentication headers.
4: Optional: Reference to an OpenShift Container Platform ConfigMap object containing the PEM-encoded certificate authority bundle to use in validating server certificates for the configured URL.
5: Optional: Reference to an OpenShift Container Platform Secret object containing the client certificate to present when making requests to the configured URL.
6: Reference to an OpenShift Container Platform Secret object containing the key for the client certificate. Required if tlsClientCert is specified.

Additional resources

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

4.4.6. 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>
```
```
$ oc apply -f </path/to/CR>
```
Copy to Clipboard Toggle word wrap
注意
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.
Log in to the cluster as a user from your identity provider, entering the password when prompted.
```
oc login -u <username>
```
```
$ oc login -u <username>
```
Copy to Clipboard Toggle word wrap
Confirm that the user logged in successfully, and display the user name.
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap

4.4.7. Example Apache HTTPD configuration for basic identity providers
复制链接

The basic identify provider (IDP) configuration in OpenShift Container Platform 4 requires that the IDP server respond with JSON for success and failures. You can use CGI scripting in Apache HTTPD to accomplish this. This section provides examples.

Example /etc/httpd/conf.d/login.conf

<VirtualHost *:443>
  # CGI Scripts in here
  DocumentRoot /var/www/cgi-bin

  # SSL Directives
  SSLEngine on
  SSLCipherSuite PROFILE=SYSTEM
  SSLProxyCipherSuite PROFILE=SYSTEM
  SSLCertificateFile /etc/pki/tls/certs/localhost.crt
  SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

  # Configure HTTPD to execute scripts
  ScriptAlias /basic /var/www/cgi-bin

  # Handles a failed login attempt
  ErrorDocument 401 /basic/fail.cgi

  # Handles authentication
  <Location /basic/login.cgi>
    AuthType Basic
    AuthName "Please Log In"
    AuthBasicProvider file
    AuthUserFile /etc/httpd/conf/passwords
    Require valid-user
  </Location>
</VirtualHost>

<VirtualHost *:443>
  # CGI Scripts in here
  DocumentRoot /var/www/cgi-bin

  # SSL Directives
  SSLEngine on
  SSLCipherSuite PROFILE=SYSTEM
  SSLProxyCipherSuite PROFILE=SYSTEM
  SSLCertificateFile /etc/pki/tls/certs/localhost.crt
  SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

  # Configure HTTPD to execute scripts
  ScriptAlias /basic /var/www/cgi-bin

  # Handles a failed login attempt
  ErrorDocument 401 /basic/fail.cgi

  # Handles authentication
  <Location /basic/login.cgi>
    AuthType Basic
    AuthName "Please Log In"
    AuthBasicProvider file
    AuthUserFile /etc/httpd/conf/passwords
    Require valid-user
  </Location>
</VirtualHost>

Copy to Clipboard

Toggle word wrap

Example /var/www/cgi-bin/login.cgi

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"sub":"userid", "name":"'$REMOTE_USER'"}'
exit 0

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"sub":"userid", "name":"'$REMOTE_USER'"}'
exit 0

Copy to Clipboard

Toggle word wrap

Example /var/www/cgi-bin/fail.cgi

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"error": "Login failure"}'
exit 0

#!/bin/bash
echo "Content-Type: application/json"
echo ""
echo '{"error": "Login failure"}'
exit 0

Copy to Clipboard

Toggle word wrap

4.4.7.1. File requirements
复制链接

These are the requirements for the files you create on an Apache HTTPD web server:

login.cgi and fail.cgi must be executable (chmod +x).
login.cgi and fail.cgi must have proper SELinux contexts if SELinux is enabled: restorecon -RFv /var/www/cgi-bin, or ensure that the context is httpd_sys_script_exec_t using ls -laZ.
login.cgi is only executed if your user successfully logs in per Require and Auth directives.
fail.cgi is executed if the user fails to log in, resulting in an HTTP 401 response.

4.4.8. Basic authentication troubleshooting
复制链接

The most common issue relates to network connectivity to the backend server. For simple debugging, run curl commands on the master. To test for a successful login, replace the <user> and <password> in the following example command with valid credentials. To test an invalid login, replace them with false credentials.

curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp

$ curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp

Copy to Clipboard

Toggle word wrap

Successful responses

A 200 status with a sub (subject) key indicates success:

{"sub":"userid"}

{"sub":"userid"}

Copy to Clipboard

Toggle word wrap

The subject must be unique to the authenticated user, and must not be able to be modified.

A successful response can optionally provide additional data, such as:

A display name using the name key:
```
{"sub":"userid", "name": "User Name", ...}
```
```
{"sub":"userid", "name": "User Name", ...}
```
Copy to Clipboard Toggle word wrap

An email address using the email key:

{"sub":"userid", "email":"user@example.com", ...}

{"sub":"userid", "email":"user@example.com", ...}

Copy to Clipboard

Toggle word wrap

A preferred user name using the preferred_username key:
```
{"sub":"014fbff9a07c", "preferred_username":"bob", ...}
```
```
{"sub":"014fbff9a07c", "preferred_username":"bob", ...}
```
Copy to Clipboard Toggle word wrap
The preferred_username key is useful when the unique, unchangeable subject is a database key or UID, and a more human-readable name exists. This is used as a hint when provisioning the OpenShift Container Platform user for the authenticated identity.

Failed responses

A 401 response indicates failed authentication.
A non-200 status or the presence of a non-empty "error" key indicates an error: {"error":"Error message"}

4.4.1. About identity providers in OpenShift Container Platform
复制链接

4.4.2. About basic authentication
复制链接

4.4.3. Creating the secret
复制链接

4.4.4. Creating a config map
复制链接

4.4.5. Sample basic authentication CR
复制链接

4.4.6. Adding an identity provider to your clusters
复制链接

4.4.7. Example Apache HTTPD configuration for basic identity providers
复制链接

4.4.7.1. File requirements
复制链接

4.4.8. Basic authentication troubleshooting
复制链接

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.4. Configuring a basic authentication identity provider

4.4.1. About identity providers in OpenShift Container Platform复制链接链接已复制到粘贴板!

4.4.2. About basic authentication复制链接链接已复制到粘贴板!

4.4.3. Creating the secret复制链接链接已复制到粘贴板!

4.4.4. Creating a config map复制链接链接已复制到粘贴板!

4.4.5. Sample basic authentication CR复制链接链接已复制到粘贴板!

4.4.6. Adding an identity provider to your clusters复制链接链接已复制到粘贴板!

4.4.7. Example Apache HTTPD configuration for basic identity providers复制链接链接已复制到粘贴板!

4.4.7.1. File requirements复制链接链接已复制到粘贴板!

4.4.8. Basic authentication troubleshooting复制链接链接已复制到粘贴板!

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.4.1. About identity providers in OpenShift Container Platform
复制链接

4.4.2. About basic authentication
复制链接

4.4.3. Creating the secret
复制链接

4.4.4. Creating a config map
复制链接

4.4.5. Sample basic authentication CR
复制链接

4.4.6. Adding an identity provider to your clusters
复制链接

4.4.7. Example Apache HTTPD configuration for basic identity providers
复制链接

4.4.7.1. File requirements
复制链接

4.4.8. Basic authentication troubleshooting
复制链接