Configuring a basic authentication identity provider

Configure a basic-authentication identity provider for users to log in to OKD with credentials validated against a remote identity provider. Basic authentication is a generic back-end integration mechanism.

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.

About basic authentication

Basic authentication is a generic back-end integration mechanism that allows users to log in to OKD 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 OKD, 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 OKD during login.

This only works for user name/password login mechanisms, and OKD 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:

  1. {"error":"Error message"}

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

  1. {"sub":"userid"} (1)
1The 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:

    1. {"sub":"userid", "name": "User Name", ...}

  • An email address using the email key. For example:

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

  • 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 OKD user for the authenticated identity. For example:

    1. {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

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 that contains the key and certificate by using the following command:

    1. $ oc create secret tls <secret_name> --key=key.pem --cert=cert.pem -n openshift-config

    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: kubernetes.io/tls
    7. data:
    8.   tls.crt: <base64_encoded_cert>
    9.   tls.key: <base64_encoded_key>

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.

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

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

Sample basic authentication CR

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

Basic authentication CR

  1. apiVersion: config.openshift.io/v1
  2. kind: OAuth
  3. metadata:
  4.   name: cluster
  5. spec:
  6.   identityProviders:
  7.   - name: basicidp (1)
  8.     mappingMethod: claim (2)
  9.     type: BasicAuth
  10.     basicAuth:
  11.       url: https://www.example.com/remote-idp (3)
  12.       ca: (4)
  13.         name: ca-config-map
  14.       tlsClientCert: (5)
  15.         name: client-cert-secret
  16.       tlsClientKey: (6)
  17.         name: client-key-secret
1This provider name is prefixed to the returned user ID to form an identity name.
2Controls how mappings are established between this provider’s identities and User objects.
3URL accepting credentials in Basic authentication headers.
4Optional: Reference to an OKD ConfigMap object containing the PEM-encoded certificate authority bundle to use in validating server certificates for the configured URL.
5Optional: Reference to an OKD Secret object containing the client certificate to present when making requests to the configured URL.
6Reference to an OKD Secret object containing the key for the client certificate. Required if tlsClientCert is specified.

Additional resources

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 OKD cluster.

  • 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. Log in to the cluster as a user from your identity provider, entering the password when prompted.

    1. $ oc login -u <username>

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

    1. $ oc whoami

Example Apache HTTPD configuration for basic identity providers

The basic identify provider (IDP) configuration in OKD 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

  1. <VirtualHost *:443>
  2.   # CGI Scripts in here
  3.   DocumentRoot /var/www/cgi-bin
  5.   # SSL Directives
  6.   SSLEngine on
  7.   SSLCipherSuite PROFILE=SYSTEM
  8.   SSLProxyCipherSuite PROFILE=SYSTEM
  9.   SSLCertificateFile /etc/pki/tls/certs/localhost.crt
  10.   SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
  12.   # Configure HTTPD to execute scripts
  13.   ScriptAlias /basic /var/www/cgi-bin
  15.   # Handles a failed login attempt
  16.   ErrorDocument 401 /basic/fail.cgi
  18.   # Handles authentication
  19.   <Location /basic/login.cgi>
  20.     AuthType Basic
  21.     AuthName "Please Log In"
  22.     AuthBasicProvider file
  23.     AuthUserFile /etc/httpd/conf/passwords
  24.     Require valid-user
  25.   </Location>
  26. </VirtualHost>

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

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

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

  1. #!/bin/bash
  2. echo "Content-Type: application/json"
  3. echo ""
  4. echo '{"error": "Login failure"}'
  5. exit 0

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.

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.

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

Successful responses

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

  1. {"sub":"userid"}

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:

    1. {"sub":"userid", "name": "User Name", ...}

  • An email address using the email key:

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

  • A preferred user name using the preferred_username key:

    1. {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

    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 OKD 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"}