Configure External Authentication

You can enable users to authenticate using external services such as Google, GitHub, LDAP, OAuth, or OIDC.

Authentication via an identity provider is accomplished using Dex, an OpenID Connect identity hub. Dex can be used to expose a consistent OpenID Connect interface to your applications while allowing your users to authenticate using their existing credentials from various back-ends.

Before You Start #

Obtain a server certificate and private key for the domain you want to use
- GKE Walkthrough
Set up HTTPS/TLS
Connect to aioli-master via HTTPS
Ensure you have the necessary credentials for the identity provider you want to enable

How to Configure External Authentication Services #

To enable external authentication services, you must configure the dex.config.connectors section in the values.yaml file.

Tip

Since SSL/TLS certificates are usually based on domain names, you can use the --set loadBalancerHostname=<Your-MLIS-Controller-Domain-Name> Helm option, which allows MLIS to automatically populate the URL values for dex.config.issuer, dex.config.connectors[0].config.redirectURI, dex.config.staticClients[0].redirectURIs, and oidc.idpRecipientUrl with the domain name. This option is valid even if aioli-proxy does not obtain its IP address using --set loadBalancerIP.

Obtain Root Certificate (Optional) #

If your external authentication service uses a self-signed certificate, you may obtain its root CA using the following instructions. Otherwise, you can skip this section.

Expand for Optional Steps

Obtain the root certificate from the external authentication service. You can use the following script to extract the root CA certificate from the server’s certificate chain.

#!/bin/bash

if [ $# -ne 2 ]
then
    echo "usage: $0 domain-name port" 1>&2
    exit 1
fi

domain_name=$1
port=$2

# Connect to the server and retrieve the certificate chain.
openssl s_client -connect ${domain_name}:${port} -showcerts </dev/null 2>/dev/null | \
awk 'BEGIN {found=0} /-----BEGIN CERTIFICATE-----/ {found=1} {if (found) print $0} /-----END CERTIFICATE-----/ {if (found) print ""; found=0}' > all-certs.pem

# Split the certificates into individual files (use gcsplit on MAC).
csplit -f cert- -b "%02d.pem" all-certs.pem '/-----BEGIN CERTIFICATE-----/' '{*}'

# Check each certificate to find the root CA
for cert in cert-*.pem; do
  if openssl x509 -noout -in "$cert" -text | grep -q "CA:TRUE"; then
    mv "$cert" rootCA.crt
    echo "Root CA certificate saved to rootCA.crt"
    break
  fi
done

# Clean up other certificate files
rm cert-*.pem all-certs.pem

Give the script executable permissions.
```
chmod +x get_root_ca_cert.sh
```
Run the script. Replace DOMAIN with your external authentication service’s domain (e.g., example.com) and PORT with its port (e.g., 443). The root CA will be stored in a file called rootCA.crt.
```
./get_root_ca_cert.sh DOMAIN PORT
```
Store the root CA in a Kubernetes secret named dex-idp-cert. Replace the NAMESPACE in the following command with the namespace used in your Helm install command for HPE Machine Learning Inferencing Software.
```
kubectl create secret generic dex-idp-cert --from-file=idp-root-ca.crt=./rootCA.crt --namespace NAMESPACE
```

Provider Configuration #

Create a values.yaml file.
Add the following dex section. Replace the sample values shown with a connector for the external authentication service you want to enable.

In this example, we are using GitHub as our connector. GitHub does not use a self-signed certificate. It uses valid SSL/TLS certificates issued by trusted certificate authorities (CAs). Therefore, no additional configuration is required to pass the root CA to Dex.

dex:
  config:
    connectors:
      - type: github
        name: GitHub 
        id: github
        config:
          issuer: <ISSUER-URL>
          clientID: <CLIENT-ID>
          clientSecret: <CLIENT-SECRET>

If your external authentication service uses a self-signed certificate, add the root CA contained in the dex-idp-cert secret you created previously using the volumes and volumeMounts shown below. In this example, we are using LDAP as our connector.

dex:
  volumes:
  - name: dex-idp-cert-volume
    secret:
      secretName: dex-idp-cert
  volumeMounts:
  - name: dex-idp-cert-volume
    mountPath: "/etc/ssl/certs/idp-root-ca.crt"
    subPath: "idp-root-ca.crt"
  config:
    connectors:
    - type: ldap
      name: LDAP
      id: ldap
      config:
        host: ldap.example.com:636
        insecureNoSSL: false
        insecureSkipVerify: false
        userSearch:
          baseDN: ou=People,o=example.com
          emailAttr: mail
          idAttr: DN
          nameAttr: cn
          username: mail
        usernamePrompt: Email Address

OIDC Configuration #

Add the following oidc section in the values.yaml file.

oidc:
  enabled: true
  # allowInsecureIssuerURLContext: false
  autoProvisionUsers: true
  # authenticationClaim: <authentication_claim_attribute> | email (default), preferred_username, name
  # displayNameAttributeName: <display_name_attribute> | empty (default), name, preferred_username, email

Integrate with Off-Spec Providers #

If you need to integrate with an off-spec provider, set allowInsecureIssuerURLContext to true.

User Provisioning #

If autoProvisionUsers is set to true, users are automatically added to the MLIS database upon successful authentication.
If autoProvisionUsers is set to false, the platform administrator must explicitly create users in the MLIS database and assign their roles.
```
aioli user login admin
aioli user create user.name@acme.com --remote
aioli rbac assign-role Admin -u user.name@acme.com
```

In both cases, users are automatically assigned the Viewer role unless otherwise specified. To see all available roles, use the following command:

aioli rbac list-roles

Tip

For more details on user creation and RBAC, see the User Accounts section.

Allow Preferred User Names #

By default, MLIS sets the username of the user to the email address that is used to sign in with the identity provider. If the identity provider includes the preferred_username claim in the ID token, you may choose to use the preferred_username as the username by adding authenticationClaim: preferred_username to the oidc section of your values.yaml.

Set Display Name Attribute Name #

By default, MLIS leaves the Display Name field blank when a user is added to the database. You may specify which attribute is used to populate the Display Name field by adding oidc.displayNameAttributeName to the oidc section of your values.yaml.

Install Platform #

Provide the values.yaml file to the helm install command during installation, using the --values flag.

helm install mlis aioli/aioli --values values.yaml

Remote users can now authenticate using the external service you have configured.

For instructions on how to sign in as a user, see the Connect to Existing Instance guide and select the remote CLI tab.