Configuring a basic authentication identity provider - Configuring identity providers | Authentication and authorization

Identity providers in OKD
About basic authentication
Creating the secret
Creating a 'ConfigMap'
Sample basic authentication custom resource
Adding an identity provider to your cluster
Example Apache HTTPD configuration for basic identity providers
- File requirements
Troubleshooting basic authentication

Configure the basic-authentication identity provider. Users can log in to OKD with credentials validated against a remote authentication service, without maintaining a separate user store in the cluster.

Identity providers in OKD

You can configure identity providers by creating a custom resource (CR) that describes the provider and adding it to the cluster. Identity providers enable user authentication in OKD beyond the default kubeadmin user.

OKD usernames containing /, :, and % are not supported.

About basic authentication

Configure basic authentication to validate user credentials against a remote service over HTTP. Use this integration when you need a flexible back-end for username and password login in OKD.

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 username and password to OKD during login. OKD validates those credentials against a remote server. OKD makes a server-to-server request, passing the credentials as a basic authentication header.

This only works for username and password login mechanisms, and OKD must be able to make network requests to the remote authentication server.

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

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

{"sub":"userid"}

where:

userid: Specifies a value that is unique to the authenticated user and must not 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", ...}
```

An email address using the email key. For example:

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

A preferred username 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:
```
{"sub":"014fbff9a07c", "preferred_username":"bob", ...}
```

Creating the secret

You can create a TLS Secret object in the openshift-config namespace by using the oc CLI or by applying a YAML file to store client certificates and keys that identity providers require for secure communication.

Procedure

Create a Secret object that contains the key and certificate by running the following command:
```
$ oc create secret tls <secret_name> --key=key.pem --cert=cert.pem -n openshift-config
```

Optional: Apply the following YAML to create the secret:

apiVersion: v1
kind: Secret
metadata:
  name: <secret_name>
  namespace: openshift-config
type: kubernetes.io/tls
data:
  tls.crt: <base64_encoded_cert>
  tls.key: <base64_encoded_key>

Creating a 'ConfigMap'

Create a ConfigMap object in the openshift-config namespace to store the certificate authority bundle that identity providers use to validate secure connections to the remote authentication service.

Procedure

Define an OKD ConfigMap object containing the certificate authority by running the following command:
```
$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
```

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

The certificate authority must be stored in the ca.crt key of the ConfigMap object.

Sample basic authentication custom resource

You can configure basic authentication for your cluster by applying an OAuth custom resource (CR) with a BasicAuth identity provider. Use this sample to review provider parameters and acceptable values before you connect to your remote authentication server.

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

where:

spec.identityProviders.name: Specifies that the provider name is prefixed to the returned user ID to form an identity name.
spec.identityProviders.mappingMethod: Specifies how mappings are established between the identities of this provider and User objects.
spec.identityProviders.basicAuth.url: Specifies the URL that accepts credentials in Basic authentication headers.
spec.identityProviders.basicAuth.ca: Optional: Specifies a reference to an OKD ConfigMap object containing the Privacy-Enhanced Mail (PEM)-encoded certificate authority bundle to use in validating server certificates for the configured URL.
spec.identityProviders.basicAuth.tlsClientCert: Optional: Specifies a reference to an OKD Secret object containing the client certificate to present when making requests to the configured URL.
spec.identityProviders.basicAuth.tlsClientKey: Specifies a reference to an OKD Secret object containing the key for the client certificate. Required if tlsClientCert is specified.

Additional resources

Identity provider parameters

Adding an identity provider to your cluster

Apply the identity provider custom resource (CR) to your cluster so users can authenticate with the configured identity provider.

Prerequisites

You installed an OKD cluster.
You defined the CR for your identity provider.
You are logged in as an administrator.

Procedure

Apply the defined CR by running the following command:

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

Log in to the cluster with credentials from the configured identity provider by running the following command. Enter the password when prompted:
```
$ oc login -u <username>
```
Confirm that the user logged in successfully and that the username displays by running the following command:
```
$ oc whoami
```

Example Apache HTTPD configuration for basic identity providers

You can use CGI scripting in Apache HTTPD to configure a remote authentication server that returns JSON responses for basic identity providers in OKD.

The following is an example of an Apache VirtualHost configuration file.

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

The following is an example of a login.cgi CGI script file.

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

The following is an example of a fail.cgi CGI script file.

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

File requirements

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

The login.cgi and fail.cgi CGI script files must be executable. Use the chmod +x command on both files.
If SELinux is enabled, the login.cgi and fail.cgi CGI script files must have proper SELinux security contexts. Run the restorecon -RFv /var/www/cgi-bin command, or ensure that the context is the httpd_sys_script_exec_t SELinux type by using the ls -laZ command.
The login.cgi CGI script file runs only when the user successfully logs in according to the Require and Auth Apache configuration directives.
The fail.cgi CGI script file runs when the user fails to log in and returns an HTTP 401 HTTP status code.

Troubleshooting basic authentication

Troubleshoot basic authentication by testing backend connectivity and verifying JSON login responses when users cannot authenticate in OKD.

The most common issue relates to network connectivity to the backend server. To debug connectivity, run curl commands on a control plane node.

Procedure

To test successful and unsuccessful logins, replace the <user> and <password> in the following example command with valid or invalid 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

Review successful login responses.

A 200 status with a sub (subject) key indicates success:
```
{"sub":"userid"}
```
The subject must be unique to the authenticated user and must not be modified.

A successful response can optionally provide additional data, such as:
- A display name using the name key:
  
  {"sub":"userid", "name": "User Name", ...}
- An email address using the email key:
  
  {"sub":"userid", "email":"user@example.com", ...}
- A preferred username using the preferred_username key:
  
  {"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.
Review failed login 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"}