OpenID Connect Identity Management

AIStor supports using an OpenID Connect (OIDC) identity provider (IDP) such as Okta, KeyCloak, Dex, Google, or Facebook for external management of user identities.

This page explains how to configure an OIDC provider for AIStor on Kubernetes and baremetal infrastructures.

See OpenID Connect Access Management for how to set up appropriate access controls for OIDC-managed identities.

This procedure is generic for OIDC compatible providers. Refer to the documentation for the OIDC provider of your choice for specific information.

This procedure assumes an existing OIDC provider such as Okta, KeyCloak, Dex, Google, or Facebook. Instructions on configuring these services are out of scope for this procedure.

The AIStor deployment must have bidirectional network connectivity to the target OIDC service.

Ensure each user identity intended for use with AIStor has the appropriate claim configured such that AIStor can associate a policy to the authenticated user. An OpenID user with no assigned policy has no permission to access any action or resource on the AIStor cluster.

This procedure uses mc for performing operations on the AIStor cluster. Install mc on a machine with network access to the cluster. See the mc Installation Quickstart for instructions on downloading and installing mc.

This procedure assumes a configured alias for the AIStor cluster.

1. Provide the OIDC configuration settings.

   You can configure the provider using either environment variables or server runtime configuration settings. You can also create the configuration in the AIStor console. All methods require starting/restarting the AIStor deployment to apply changes.

   Environment Variables

   For distributed deployments, specify these settings across all nodes in the deployment using the same values consistently.

   The following example code sets all environment variables related to an OIDC configuration. The minimum required variable is MINIO_IDENTITY_OPENID_CONFIG_URL:

   export MINIO_IDENTITY_OPENID_CONFIG_URL="https://openid-provider.example.net/.well-known/openid-configuration"
   export MINIO_IDENTITY_OPENID_CLIENT_ID="<string>"
   export MINIO_IDENTITY_OPENID_CLIENT_SECRET="<string>"
   export MINIO_IDENTITY_OPENID_CLAIM_NAME="<string>"
   export MINIO_IDENTITY_OPENID_CLAIM_PREFIX="<string>"
   export MINIO_IDENTITY_OPENID_SCOPES="<string>"
   export MINIO_IDENTITY_OPENID_REDIRECT_URI="<string>"
   export MINIO_IDENTITY_OPENID_COMMENT="<string>"
   

   Replace the MINIO_IDENTITY_OPENID_CONFIG_URL with the URL endpoint of the provider discovery document.

   For complete documentation of these variables, see OpenID Identity Management Settings.

   Configuration settings

   For distributed deployments, the mc admin config command applies the configuration to all nodes in the deployment.

   The following example code sets all configuration settings related to configuring a provider for external identity management. The minimum required setting is identity_openid config_url:

   mc admin config set ALIAS/ identity_openid \
     config_url="https://openid-provider.example.net/.well-known/openid-configuration" \
     client_id="<string>" \
     client_secret="<string>" \
     claim_name="<string>" \
     claim_prefix="<string>" \
     scopes="<string>" \
     redirect_uri="<string>" \
     comment="<string>"
   

   Replace the config_url value with the URL endpoint of the provider discovery document.

   For more complete documentation on these settings, see identity_openid.

2. Restart the AIStor Deployment

   You must restart the AIStor deployment to apply the configuration changes. Run the mc admin service restart command to restart the deployment.

   mc admin service restart ALIAS
   

   Replace ALIAS with the alias of the deployment to restart.

3. Use the console to log in with OIDC credentials

   The AIStor console supports the full workflow of authenticating to the provider, generating temporary credentials using the AIStor AssumeRoleWithWebIdentity Security Token Service (STS) endpoint, and logging the user into the AIStor deployment.

   Go to the root URL for the deployment, for example https://minio.example.net:9000.

   After you log in, you can perform any action for which your account is authorized.

4. Generate credentials for application authentication

   Clients should authenticate using AWS Signature Version 4 protocol, although AIStor maintains backward compatibility to support the deprecated Signature Version 2 protocol. Clients must present a valid access key and secret key to access any S3 or AIStor administrative API, such as PUT, GET, and DELETE operations.

   You can create access keys to support applications that must perform operations on AIStor. Access keys are long-lived credentials that inherit their permissions from the parent user.

   Alternatively, applications can generate temporary access credentials as needed with the AssumeRoleWithLDAPIdentity Security Token Service (STS) API endpoint and OIDC user credentials.

   The application must provide a workflow for logging into the provider and retrieving the JSON Web Token (JWT) associated with the authentication session. Refer to the provider documentation for obtaining and parsing the JWT token after successful authentication. See the example Go application web-identity.go for this workflow.

   Call the AssumeRoleWithWebIdentity endpoint with the JWT to generate the temporary credentials:

   POST https://aistor.example.net?Action=AssumeRoleWithWebIdentity
   &WebIdentityToken=TOKEN
   &Version=2011-06-15
   &DurationSeconds=86400
   &Policy=Policy
   

   • Replace TOKEN with the JWT token returned in the previous step.

   • Replace DurationSeconds with the duration in seconds until the temporary credentials expire. The example specifies a period of 86400 seconds, or 24 hours.

   • Replace Policy with an inline URL-encoded JSON policy that further restricts the permissions associated to the temporary credentials.

     Omit to use the policy associated with the OIDC user policy claim.

   The API response consists of an XML document containing the access key, secret key, session token, and expiration. Applications can use the access key and secret key to access and perform operations on AIStor.

   See the AssumeRoleWithLDAPIdentity for reference documentation.