Skip to content

This is the multi-page printable view of this section. .

Return to the regular view of this page.

External Identity Management

MinIO supports multiple external identity managers through the following IDentity Providers (IDP):

The following tutorials provide specific guidance for select IDP software:

Users can authenticate against MinIO using their externally managed credentials and the related Security Token Service (STS) API. Once authenticated, MinIO attempts to associate the user with one or more configured policies. A user with no associated policies has no permissions on the MinIO deployment.

OpenID Connect (OIDC)

MinIO supports using an OpenID Connect (OIDC) compatible IDentity Provider (IDP) such as Okta, KeyCloak, Dex, Google, or Facebook for external management of user identities. Configuring an external IDP enables Single-Sign On workflows, where applications authenticate against the external IDP before accessing MinIO.

MinIO uses Policy Based Access Control (PBAC) to define the actions and resources to which an authenticated user has access. MinIO supports creating and managing policies which an externally managed user can claim.

For identities managed by the external OpenID Connect (OIDC) compatible provider, MinIO uses a JSON Web Token claim to identify the policy to assign to the authenticated user.

MinIO by default looks for a policy claim and reads a list of one or more policies to assign. MinIO attempts to match existing policies to those specified in the JWT claim. If none of the specified policies exist on the MinIO deployment, MinIO denies authorization for any and all operations issued by that user. For example, consider a claim with the following key-value assignment:

policy="readwrite_data,read_analytics,read_logs"

The specified policy claim directs MinIO to attach the policies with names matching readwrite_data, read_analytics, and read_logs to the authenticated user.

You can set a custom policy claim using the MINIO_IDENTITY_OPENID_CLAIM_NAME environment variable or by using mc admin config set to set the identity_openid claim_name setting.

See OpenID Connect Access Management for more information on mapping MinIO policies to an OIDC-managed identity.

You can use a JWT Debugging tool to decode the returned JWT token and validate that the user attributes include the specified claim. See RFC 7519: JWT Claim for more information on JWT claims. Defer to the documentation for your preferred OIDC provider for instructions on configuring user claims.

Active Directory / LDAP

MinIO supports using an Active Directory or LDAP (AD/LDAP) service for external management of user identities. Configuring an external IDentity Provider (IDP) enables Single-Sign On (SSO) workflows, where applications authenticate against the external IDP before accessing MinIO.

Querying the Active Directory / LDAP Service

MinIO queries the configured Active Directory / LDAP server to verify the credentials specified by the application and optionally return a list of groups in which the user has membership. This process, called Lookup-Bind mode, uses an AD/LDAP user with minimal permissions, only sufficient to authenticate with the AD/LDAP server for user and group lookups.

The following tabs provide a reference of the environment variables and configuration settings required for enabling Lookup-Bind mode.

See the identity_ldap reference documentation for more information on these settings. The Configure MinIO for Authentication using Active Directory / LDAP tutorial includes complete instructions on setting these variables.

Access Control for AD/LDAP-Managed Identities

MinIO uses Policy Based Access Control (PBAC) to define the actions and resources to which an authenticated user has access. When using an Active Directory/LDAP server for identity management (authentication), MinIO maintains control over access (authorization) through PBAC.

When a user successfully authenticates to MinIO using their AD/LDAP credentials, MinIO searches for all policies which are explicitly associated to that user’s Distinguished Name (DN). Specifically, the policy must be assigned to a user with a matching DN using the mc idp ldap policy attach command.

MinIO also supports querying for the user’s AD/LDAP group membership. MinIO attempts to match existing policies to the DN for each of the user’s groups. The authenticated users complete set of permissions consists of its explicitly assigned and group-inherited policies. See Group Lookup for more information.

MinIO uses deny-by-default behavior where a user with no explicitly assigned or group-inherited policies cannot access any resource on the MinIO deployment.

MinIO provides built-in policies for basic access control. You can create new policies using the mc admin policy create command.

Group Lookup

MinIO supports querying the Active Directory / LDAP server for a list of groups in which the authenticated user has membership. MinIO attempts to match existing policies to each group DN and assigns each matching policy to the authenticated user.

The following tabs provide a reference of the environment variables and configuration settings required for enabling group lookups:

See the Active Directory / LDAP Settings reference documentation for more information on these variables. The Configure MinIO for Authentication using Active Directory / LDAP tutorial includes complete instructions on setting these values.

See the identity_ldap reference documentation for more information on these settings. The Configure MinIO for Authentication using Active Directory / LDAP tutorial includes complete instructions on setting these variables.

1 - Configure Silo Authentication with Active Directory / LDAP

Overview

MinIO supports configuring a single Active Directory / LDAP Connect for external management of user identities.

The procedure on this page provides instructions for:

For MinIO Tenants deployed using the MinIO Kubernetes Operator, this procedure covers:

  • Configuring a MinIO Tenant to use an external AD/LDAP provider
  • Accessing the Tenant Console using AD/LDAP Credentials.
  • Using the MinIO AssumeRoleWithLDAPIdentity Security Token Service (STS) API to generate temporary credentials for use by applications.

For MinIO deployments on baremetal infrastructure, this procedure covers:

  • Configuring a MinIO cluster for an external AD/LDAP provider.
  • Accessing the MinIO Console using AD/LDAP credentials.
  • Using the MinIO AssumeRoleWithLDAPIdentity Security Token Service (STS) API to generate temporary credentials for use by applications.

This procedure is generic for AD/LDAP services. See the documentation for the AD/LDAP provider of your choice for specific instructions or procedures on configuration of user identities.

Prerequisites

Access to MinIO Cluster

You must have access to the MinIO Operator Console web UI. You can either expose the MinIO Operator Console service using your preferred Kubernetes routing component, or use temporary port forwarding to expose the Console service port on your local machine.

This procedure uses mc for performing operations on the MinIO 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 MinIO cluster.

Active Directory / LDAP Compatible IDentity Provider

This procedure assumes an existing Active Directory or LDAP service. Instructions on configuring AD/LDAP are out of scope for this procedure.

  • For AD/LDAP deployments within the same Kubernetes cluster as the MinIO Tenant, you can use Kubernetes service names to allow the MinIO Tenant to establish connectivity to the AD/LDAP service.
  • For AD/LDAP deployments external to the Kubernetes cluster, you must ensure the cluster supports routing communications between Kubernetes services and pods and the external network. This may require configuration or deployment of additional Kubernetes network components and/or enabling access to the public internet.

The MinIO deployment must have bidirectional network connectivity to the target AD / LDAP service.

MinIO requires a read-only access keys with which it binds to perform authenticated user and group queries. Ensure each AD/LDAP user and group intended for use with MinIO has a corresponding policy on the MinIO deployment. An AD/LDAP user with no assigned policy and with membership in groups with no assigned policy has no permission to access any action or resource on the MinIO cluster.

Configure MinIO with Active Directory or LDAP External Identity Management

  1. Set the Active Directory / LDAP Configuration Settings

    Configure the AD/LDAP provider using one of the following:

    • MinIO Client
    • Environment variables

    All methods require starting/restarting the MinIO deployment to apply changes.

    The following tabs provide a quick reference for the available configuration methods:

    MinIO supports specifying the AD/LDAP provider settings using mc idp ldap commands.

    For distributed deployments, the mc idp ldap command applies the configuration to all nodes in the deployment.

    The following example code sets all configuration settings related to configuring an AD/LDAP provider for external identity management.

    The minimum required settings are:

    mc idp ldap add ALIAS                                                  \
      server_addr="ldaps.example.net:636"                                  \
      lookup_bind_dn="CN=xxxxx,OU=xxxxx,OU=xxxxx,DC=example,DC=net"        \
      lookup_bind_password="xxxxxxxx"                                      \
      user_dn_search_base_dn="DC=example,DC=net"                           \
      user_dn_search_filter="(&(objectCategory=user)(sAMAccountName=%s))"  \
      group_search_filter= "(&(objectClass=group)(member=%d))"             \
      group_search_base_dn="ou=MinIO Users,dc=example,dc=net"              \
      tls_skip_verify="off"                                                \
      server_insecure=off                                                  \
      server_starttls="off"                                                \
      srv_record_name=""                                                   \
      comment="Test LDAP server"

    For Kubernetes deployments, ensure the ALIAS corresponds to the externally accessible hostname for the MinIO Tenant.

    For more complete documentation on these settings, see mc idp ldap.

    Note

    mc idp ldap recommended

    mc idp ldap offers additional features and improved validation over mc admin config set runtime configuration settings. mc idp ldap supports the same settings as mc admin config and the identity_ldap configuration key.

    The identity_ldap configuration key remains available for existing scripts and tools.

    MinIO supports specifying the AD/LDAP provider settings using environment variables.

    The minio server process applies the specified settings on its next startup. For distributed deployments, specify these settings across all nodes in the deployment using the same values. Any differences in server configurations between nodes will result in startup or configuration failures.

    The following example code sets all environment variables related to configuring an AD/LDAP provider for external identity management. The minimum required variable are:

    export MINIO_IDENTITY_LDAP_SERVER_ADDR="ldaps.example.net:636"
    export MINIO_IDENTITY_LDAP_LOOKUP_BIND_DN="CN=xxxxx,OU=xxxxx,OU=xxxxx,DC=example,DC=net"
    export MINIO_IDENTITY_LDAP_USER_DN_SEARCH_BASE_DN="dc=example,dc=net"
    export MINIO_IDENTITY_LDAP_USER_DN_SEARCH_FILTER="(&(objectCategory=user)(sAMAccountName=%s))"
    export MINIO_IDENTITY_LDAP_LOOKUP_BIND_PASSWORD="xxxxxxxxx"
    export MINIO_IDENTITY_LDAP_GROUP_SEARCH_FILTER="(&(objectClass=group)(member=%d))"
    export MINIO_IDENTITY_LDAP_GROUP_SEARCH_BASE_DN="ou=MinIO Users,dc=example,dc=net"
    export MINIO_IDENTITY_LDAP_TLS_SKIP_VERIFY="off"
    export MINIO_IDENTITY_LDAP_SERVER_INSECURE="off"
    export MINIO_IDENTITY_LDAP_SERVER_STARTTLS="off"
    export MINIO_IDENTITY_LDAP_SRV_RECORD_NAME=""
    export MINIO_IDENTITY_LDAP_COMMENT="LDAP test server"

    For complete documentation on these variables, see Active Directory / LDAP Settings.

  2. Restart the MinIO Deployment

    You must restart the MinIO deployment to apply the configuration changes.

    If you configured AD/LDAP from the MinIO Console, no additional action is required. The MinIO Console automatically restarts the deployment after saving the new AD/LDAP configuration.

    For MinIO Client and environment variable configuration, use 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 MinIO Console to Log In with AD/LDAP Credentials

    The MinIO Console supports the full workflow of authenticating to the AD/LDAP provider, generating temporary credentials using the MinIO AssumeRoleWithLDAPIdentity Security Token Service (STS) endpoint, and logging the user into the MinIO deployment.

    You can access the Console by opening the root URL for the MinIO cluster. For example, https://minio.example.net:9000.

    Once logged in, you can perform any action for which the authenticated user is authorized.

    You can also create access keys for supporting applications which must perform operations on MinIO. Access Keys are long-lived credentials which inherit their privileges from the parent user. The parent user can further restrict those privileges while creating the service account.

  4. Generate S3-Compatible Temporary Credentials using AD/LDAP Credentials

    MinIO requires clients to authenticate using AWS Signature Version 4 protocol with support for the deprecated Signature Version 2 protocol. Specifically, clients must present a valid access key and secret key to access any S3 or MinIO administrative API, such as PUT, GET, and DELETE operations.

    Applications can generate temporary access credentials as-needed using the AssumeRoleWithLDAPIdentity Security Token Service (STS) API endpoint and AD/LDAP user credentials. MinIO provides an example Go application ldap.go that manages this workflow.

    POST https://minio.example.net?Action=AssumeRoleWithLDAPIdentity
    &LDAPUsername=USERNAME
    &LDAPPassword=PASSWORD
    &Version=2011-06-15
    &Policy={}
    • Replace the LDAPUsername with the username of the AD/LDAP user.

    • Replace the LDAPPassword with the password of the AD/LDAP user.

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

      Omit to use the policy whose name matches the Distinguished Name (DN) of the AD/LDAP user.

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

    See the AssumeRoleWithLDAPIdentity for reference documentation.

Disable a Configured Active Directory / LDAP Connection

Note

Added: RELEASE.2023-03-20T20-16-18Z

You can enable and disable the configured AD/LDAP connection as needed.

Use mc idp ldap disable to deactivate a configured connection. Use mc idp ldap enable to activate a previously configured connection.

2 - Configure Silo Authentication with Keycloak

Overview

This procedure configures MinIO to use Keycloak as an external IDentity Provider (IDP) for authentication of users via the OpenID Connect (OIDC) protocol.

This page has procedures for configuring OIDC for MinIO deployments in Kubernetes and Baremetal infrastructures.

Select the tab corresponding to your infrastructure to switch between instruction sets.

For MinIO Tenants deployed using the MinIO Kubernetes Operator, this procedure covers:

  • Configure Keycloak for use with MinIO authentication and authorization
  • Configure a new or existing MinIO Tenant to use Keycloak as the OIDC provider
  • Create policies to control access of Keycloak-authenticated users
  • Log into the MinIO Tenant Console using SSO and a Keycloak-managed identity
  • Generate temporary S3 access credentials using the AssumeRoleWithWebIdentity Security Token Service (STS) API

For MinIO deployments on baremetal infrastructure, this procedure covers:

  • Configure Keycloak for use with MinIO authentication and authorization
  • Configure a new or existing MinIO cluster to use Keycloak as the OIDC provider
  • Create policies to control access of Keycloak-authenticated users
  • Log into the MinIO Console using SSO and a Keycloak-managed identity
  • Generate temporary S3 access credentials using the AssumeRoleWithWebIdentity Security Token Service (STS) API

This procedure was written and tested against Keycloak 21.0.0. The provided instructions may work against other Keycloak versions. This procedure assumes you have prior experience with Keycloak and have reviewed their documentation for guidance and best practices in deploying, configuring, and managing the service.

Prerequisites

Keycloak Deployment and Realm Configuration

This procedure assumes an existing Keycloak deployment to which you have administrative access. Specifically, you must have permission to create and configure Realms, Clients, Client Scopes, Realm Roles, Users, and Groups on the Keycloak deployment.

For Keycloak deployments within the same Kubernetes cluster as the MinIO Tenant, this procedure assumes bidirectional access between the Keycloak and MinIO pods/services. For Keycloak deployments external to the Kubernetes cluster, this procedure assumes an existing Ingress, Load Balancer, or similar Kubernetes network control component that manages network access to and from the MinIO Tenant.

The MinIO deployment must have bidirectional access to the target OIDC service.

Ensure each user identity intended for use with MinIO has the appropriate claim configured such that MinIO 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 MinIO cluster.

Access to MinIO Cluster

You must have access to the MinIO Operator Console web UI. You can either expose the MinIO Operator Console service using your preferred Kubernetes routing component, or use temporary port forwarding to expose the Console service port on your local machine.

This procedure uses mc for performing operations on the MinIO 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 MinIO cluster.

Configure MinIO for Keycloak Identity Management

  1. Configure or Create a Client for Accessing Keycloak

    Authenticate to the Keycloak Administrative Console and navigate to Clients.

    Select Create client and follow the instructions to create a new Keycloak client for MinIO. Fill in the specified inputs as follows:

    Client ID

    Set to a unique identifier for MinIO (minio)

    Client type

    Set to OpenID Connect

    Always display in console

    Toggle to On

    Client authentication

    Toggle to On

    Authentication flow

    Toggle on Standard flow

    (Optional) Authentication flow

    Toggle on Direct access grants (API testing)

    Keycloak deploys the client with a default set of configuration values. Modify these values as necessary for your Keycloak setup and desired behavior. The following table provides a baseline of settings and values to configure:

    Root URL

    Set to ${authBaseUrl}

    Home URL

    Set to the Realm you want MinIO to use (/realms/master/account/)

    Valid Redirect URI

    Set to *

    Keys -> Use JWKS URL

    Toggle to On

    Advanced -> Advanced Settings -> Access Token Lifespan

    Set to 1 Hour.

  2. Create Client Scope for MinIO Client

    Client scopes allow Keycloak to map user attributes as part of the JSON Web Token (JWT) returned in authentication requests. This allows MinIO to reference those attributes when assigning policies to the user. This step creates the necessary client scope to support MinIO authorization after successful Keycloak authentication.

    Navigate to the Client scopes view and create a new client scope for MinIO authorization:

    Name

    Set to any recognizable name for the policy (minio-authorization)

    Include in token scope

    Toggle to On

    Once created, select the scope from the list and navigate to Mappers.

    Select Configure a new mapper to create a new mapping:

    User Attribute

    Select the Mapper Type

    Name

    Set to any recognizable name for the mapping (minio-policy-mapper)

    User Attribute

    Set to policy

    Token Claim Name

    Set to policy

    Add to ID token

    Set to On

    Claim JSON Type

    Set to String

    Multivalued

    Set to On

    This allows setting multiple policy values in the single claim.

    Aggregate attribute values

    Set to On

    This allows users to inherit any policy set in their Groups

    Once created, assign the Client Scope to the MinIO client.

    1. Navigate to Clients and select the MinIO client.
    2. Select Client scopes, then select Add client scope.
    3. Select the previously created scope and set the Assigned type to default.
  3. Apply the Necessary Attribute to Keycloak Users/Groups

    You must assign an attribute named policy to the Keycloak Users or Groups. Set the value to any policy on the MinIO deployment.

    For Users, navigate to Users and select or create the User:

    Credentials

    Set the user password to a permanent value if not already set

    Attributes

    Create a new attribute with key policy and value of any policy (consoleAdmin)

    For Groups, navigate to Groups and select or create the Group:

    Attributes

    Create a new attribute with key policy and value of any policy (consoleAdmin)

    You can assign users to groups such that they inherit the specified policy attribute. If you set the Mapper settings to enable Aggregate attribute values, Keycloak includes the aggregated array of policies as part of the authenticated user’s JWT token. MinIO can use this list of policies when authorizing the user.

    You can test the configured policies of a user by using the Keycloak API:

    curl -d "client_id=minio" \
         -d "client_secret=secretvalue" \
         -d "grant_type=password" \
         -d "username=minio-user-1" \
         -d "password=minio-user-1-password" \
         http://keycloak-service.keycloak-namespace.svc.cluster-domain.example/realms/REALM/protocol/openid-connect/token

    If successful, the access_token contains the JWT necessary to use the MinIO AssumeRoleWithWebIdentity STS API and generate S3 credentials.

    You can use a JWT decoder to review the payload and ensure it contains the policy key with one or more MinIO policies listed.

  4. Configure MinIO for Keycloak Authentication

You can use the mc idp openid add command to create a new configuration for the Keycloak service. The command takes all supported OpenID Configuration Settings:

mc idp openid add ALIAS PRIMARY_IAM \
   client_id=MINIO_CLIENT \
   client_secret=MINIO_CLIENT_SECRET \
   config_url="https://keycloak-service.keycloak-namespace.svc.cluster-domain.example/realms/REALM/.well-known/openid-configuration" \
   display_name="SSO_IDENTIFIER"
   scopes="openid,email,preferred_username" \
   redirect_uri_dynamic="on"

PRIMARY_IAM

Set to a unique identifier for the Keycloak service, such as keycloak_primary

MINIO_CLIENT
MINIO_CLIENT_SECRET

Set to the Keycloak client ID and secret configured in Step 1

config_url

Set to the address of the Keycloak OpenID configuration document (keycloak-url.example.net:8080)

display_name

Set to a user-facing name the MinIO Console displays as part of the Single-Sign On (SSO) workflow for the configured Keycloak service

scopes

Set to a list of OpenID scopes you want to include in the JWT, such as preferred_username or email

redirect_uri_dynamic

Set to on

Substitutes the MinIO Console address used by the client as part of the Keycloak redirect URI. Keycloak returns authenticated users to the Console using the provided URI.

For MinIO Console deployments behind a reverse proxy, load balancer, or similar network control plane, you can instead use the MINIO_BROWSER_REDIRECT_URL variable to set the redirect address for Keycloak to use.

Restart the MinIO deployment for the changes to apply.

Check the MinIO logs and verify that startup succeeded with no errors related to the OIDC configuration.

  1. Generate Application Credentials using the Security Token Service (STS)

    Applications using an S3-compatible SDK must specify credentials in the form of an access key and secret key. The MinIO AssumeRoleWithWebIdentity API returns the necessary temporary credentials, including a required session token, using a JWT returned by Keycloak after authentication.

    You can test this workflow using the following sequence of HTTP calls and the curl utility:

    1. Authenticate as a Keycloak user and retrieve the JWT token

      curl -X POST "https://keycloak-service.keycloak-namespace.svc.cluster-domain.example/realms/REALM/protocol/openid-connect/token" \
           -H "Content-Type: application/x-www-form-urlencoded" \
           -d "username=USER" \
           -d "password=PASSWORD" \
           -d "grant_type=password" \
           -d "client_id=CLIENT" \
           -d "client_secret=SECRET"
      • Replace the USER and PASSWORD with the credentials of a Keycloak user on the REALM.
      • Replace the CLIENT and SECRET with the client ID and secret for the MinIO-specific Keycloak client on the REALM

      You can process the results using jq or a similar JSON-formatting utility. Extract the access_token field to retrieve the necessary access token. Pay attention to the expires_in field to note the number of seconds before the token expires.

    2. Generate MinIO Credentials using the AssumeRoleWithWebIdentity API

      curl -X POST "https://minio.minio-tenant.svc.cluster-domain.example" \
           -H "Content-Type: application/x-www-form-urlencoded" \
           -d "Action=AssumeRoleWithWebIdentity" \
           -d "Version=2011-06-15" \
           -d "DurationSeconds=86000" \
           -d "WebIdentityToken=TOKEN"

      Replace the TOKEN with the access_token value returned by Keycloak.

      The API returns an XML document on success containing the following keys:

      • Credentials.AccessKeyId - the Access Key for the Keycloak User
      • Credentials.SecretAccessKey - the Secret Key for the Keycloak User
      • Credentials.SessionToken - the Session Token for the Keycloak User
      • Credentials.Expiration - the Expiration Date for the generated credentials
    3. Test the Credentials

      Use your preferred S3-compatible SDK to connect to MinIO using the generated credentials.

      For example, the following Python code using the MinIO Python SDK connects to the MinIO deployment and returns a list of buckets:

      from minio import Minio
      
      client = MinIO(
         "minio.minio-tenant.svc.cluster-domain.example",
         access_key = "ACCESS_KEY",
         secret_key = "SECRET_KEY",
         session_token = "SESSION_TOKEN"
         secure = True
      )
      
      client.list_buckets()
  2. Next Steps

Applications should implement the STS AssumeRoleWithWebIdentity flow using their SDK of choice. When STS credentials expire, applications should have logic in place to regenerate the JWT token, STS token, and MinIO credentials before retrying and continuing operations.

Alternatively, users can generate access keys through the MinIO Console for the purpose of creating long-lived API-key like access using their Keycloak credentials.

  1. Configure or Create a Client for Accessing Keycloak

    Authenticate to the Keycloak Administrative Console and navigate to Clients.

    Select Create client and follow the instructions to create a new Keycloak client for MinIO. Fill in the specified inputs as follows:

    Client ID

    Set to a unique identifier for MinIO (minio)

    Client type

    Set to OpenID Connect

    Always display in console

    Toggle to On

    Client authentication

    Toggle to On

    Authentication flow

    Toggle on Standard flow

    (Optional) Authentication flow

    Toggle on Direct access grants (API testing)

    Keycloak deploys the client with a default set of configuration values. Modify these values as necessary for your Keycloak setup and desired behavior. The following table provides a baseline of settings and values to configure:

    Root URL

    Set to ${authBaseUrl}

    Home URL

    Set to the Realm you want MinIO to use (/realms/master/account/)

    Valid Redirect URI

    Set to *

    Keys -> Use JWKS URL

    Toggle to On

    Advanced -> Advanced Settings -> Access Token Lifespan

    Set to 1 Hour.

  2. Create Client Scope for MinIO Client

    Client scopes allow Keycloak to map user attributes as part of the JSON Web Token (JWT) returned in authentication requests. This allows MinIO to reference those attributes when assigning policies to the user. This step creates the necessary client scope to support MinIO authorization after successful Keycloak authentication.

    Navigate to the Client scopes view and create a new client scope for MinIO authorization:

    Name

    Set to any recognizable name for the policy (minio-authorization)

    Include in token scope

    Toggle to On

    Once created, select the scope from the list and navigate to Mappers.

    Select Configure a new mapper to create a new mapping:

    User Attribute

    Select the Mapper Type

    Name

    Set to any recognizable name for the mapping (minio-policy-mapper)

    User Attribute

    Set to policy

    Token Claim Name

    Set to policy

    Add to ID token

    Set to On

    Claim JSON Type

    Set to String

    Multivalued

    Set to On

    This allows setting multiple policy values in the single claim.

    Aggregate attribute values

    Set to On

    This allows users to inherit any policy set in their Groups

    Once created, assign the Client Scope to the MinIO client.

    1. Navigate to Clients and select the MinIO client.
    2. Select Client scopes, then select Add client scope.
    3. Select the previously created scope and set the Assigned type to default.
  3. Apply the Necessary Attribute to Keycloak Users/Groups

    You must assign an attribute named policy to the Keycloak Users or Groups. Set the value to any policy on the MinIO deployment.

    For Users, navigate to Users and select or create the User:

    Credentials

    Set the user password to a permanent value if not already set

    Attributes

    Create a new attribute with key policy and value of any policy (consoleAdmin)

    For Groups, navigate to Groups and select or create the Group:

    Attributes

    Create a new attribute with key policy and value of any policy (consoleAdmin)

    You can assign users to groups such that they inherit the specified policy attribute. If you set the Mapper settings to enable Aggregate attribute values, Keycloak includes the aggregated array of policies as part of the authenticated user’s JWT token. MinIO can use this list of policies when authorizing the user.

    You can test the configured policies of a user by using the Keycloak API:

    curl -d "client_id=minio" \
         -d "client_secret=secretvalue" \
         -d "grant_type=password" \
         -d "username=minio-user-1" \
         -d "password=minio-user-1-password" \
         http://keycloak-url.example.net:8080/realms/REALM/protocol/openid-connect/token

    If successful, the access_token contains the JWT necessary to use the MinIO AssumeRoleWithWebIdentity STS API and generate S3 credentials.

    You can use a JWT decoder to review the payload and ensure it contains the policy key with one or more MinIO policies listed.

  4. Configure MinIO for Keycloak Authentication

    MinIO supports multiple methods for configuring Keycloak authentication:

    • Using a terminal/shell and the mc idp openid command
    • Using environment variables set prior to starting MinIO

You can use the mc idp openid add command to create a new configuration for the Keycloak service. The command takes all supported OpenID Configuration Settings:

mc idp openid add ALIAS PRIMARY_IAM \
   client_id=MINIO_CLIENT \
   client_secret=MINIO_CLIENT_SECRET \
   config_url="https://keycloak-url.example.net:8080/realms/REALM/.well-known/openid-configuration" \
   display_name="SSO_IDENTIFIER"
   scopes="openid,email,preferred_username" \
   redirect_uri_dynamic="on"

PRIMARY_IAM

Set to a unique identifier for the Keycloak service, such as keycloak_primary

MINIO_CLIENT
MINIO_CLIENT_SECRET

Set to the Keycloak client ID and secret configured in Step 1

config_url

Set to the address of the Keycloak OpenID configuration document (keycloak-url.example.net:8080)

display_name

Set to a user-facing name the MinIO Console displays as part of the Single-Sign On (SSO) workflow for the configured Keycloak service

scopes

Set to a list of OpenID scopes you want to include in the JWT, such as preferred_username or email

redirect_uri_dynamic

Set to on

Substitutes the MinIO Console address used by the client as part of the Keycloak redirect URI. Keycloak returns authenticated users to the Console using the provided URI.

For MinIO Console deployments behind a reverse proxy, load balancer, or similar network control plane, you can instead use the MINIO_BROWSER_REDIRECT_URL variable to set the redirect address for Keycloak to use.

Set the following environment variables prior to starting the container using the -e ENVVAR=VALUE flag.

The following example code sets the minimum required environment variables related to configuring Keycloak as an external identity management provider.

MINIO_IDENTITY_OPENID_CONFIG_URL_PRIMARY_IAM="https://keycloak-url.example.net:8080/realms/REALM/.well-known/openid-configuration"
MINIO_IDENTITY_OPENID_CLIENT_ID_PRIMARY_IAM="MINIO_CLIENT"
MINIO_IDENTITY_OPENID_CLIENT_SECRET_PRIMARY_IAM="MINIO_CLIENT_SECRET"
MINIO_IDENTITY_OPENID_DISPLAY_NAME_PRIMARY_IAM="SSO_IDENTIFIER"
MINIO_IDENTITY_OPENID_SCOPES_PRIMARY_IAM="openid,email,preferred_username"
MINIO_IDENTITY_OPENID_REDIRECT_URI_DYNAMIC_PRIMARY_IAM="on"

_PRIMARY_IAM

Replace the suffix _PRIMARY_IAM with a unique identifier for this Keycloak configuration. For example, MINIO_IDENTITY_OPENID_CONFIG_URL_KEYCLOAK_PRIMARY.

You can omit the suffix if you intend to only configure a single OIDC provider for the deployment.

CONFIG_URL

Specify the address of the Keycloak OpenID configuration document (keycloak-url.example.net:8080)

Ensure the REALM matches the Keycloak realm you want to use for authenticating users to MinIO

CLIENT_ID
CLIENT_SECRET

Specify the Keycloak client ID and secret configured in Step 1

DISPLAY_NAME

Specify the user-facing name the MinIO Console displays as part of the Single-Sign On (SSO) workflow for the configured Keycloak service

OPENID_SCOPES

Specify the OpenID scopes you want to include in the JWT, such as preferred_username or email

REDIRECT_URI_DYNAMIC

Set to on

Substitutes the MinIO Console address used by the client as part of the Keycloak redirect URI. Keycloak returns authenticated users to the Console using the provided URI.

For MinIO Console deployments behind a reverse proxy, load balancer, or similar network control plane, you can instead use the MINIO_BROWSER_REDIRECT_URL variable to set the redirect address for Keycloak to use.

For complete documentation on these variables, see OpenID Identity Management Settings

Restart the MinIO deployment for the changes to apply.

Check the MinIO logs and verify that startup succeeded with no errors related to the OIDC configuration.

If you attempt to log in with the Console, you should now see an (SSO) button using the configured Display Name.

Specify a configured user and attempt to log in. MinIO should automatically redirect you to the Keycloak login entry. Upon successful authentication, Keycloak should redirect you back to the MinIO Console using either the originating Console URL or the Redirect URI if configured. 5. Generate Application Credentials using the Security Token Service (STS)

Applications using an S3-compatible SDK must specify credentials in the form of an access key and secret key. The MinIO AssumeRoleWithWebIdentity API returns the necessary temporary credentials, including a required session token, using a JWT returned by Keycloak after authentication.

You can test this workflow using the following sequence of HTTP calls and the curl utility:

  1. Authenticate as a Keycloak user and retrieve the JWT token

    curl -X POST "https://keycloak-url.example.net:8080/realms/REALM/protocol/openid-connect/token" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         -d "username=USER" \
         -d "password=PASSWORD" \
         -d "grant_type=password" \
         -d "client_id=CLIENT" \
         -d "client_secret=SECRET"
    • Replace the USER and PASSWORD with the credentials of a Keycloak user on the REALM.
    • Replace the CLIENT and SECRET with the client ID and secret for the MinIO-specific Keycloak client on the REALM

    You can process the results using jq or a similar JSON-formatting utility. Extract the access_token field to retrieve the necessary access token. Pay attention to the expires_in field to note the number of seconds before the token expires.

  2. Generate MinIO Credentials using the AssumeRoleWithWebIdentity API

    curl -X POST "https://minio-url.example.net:9000" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         -d "Action=AssumeRoleWithWebIdentity" \
         -d "Version=2011-06-15" \
         -d "DurationSeconds=86000" \
         -d "WebIdentityToken=TOKEN"

    Replace the TOKEN with the access_token value returned by Keycloak.

    The API returns an XML document on success containing the following keys:

    • Credentials.AccessKeyId - the Access Key for the Keycloak User
    • Credentials.SecretAccessKey - the Secret Key for the Keycloak User
    • Credentials.SessionToken - the Session Token for the Keycloak User
    • Credentials.Expiration - the Expiration Date for the generated credentials
  3. Test the Credentials

    Use your preferred S3-compatible SDK to connect to MinIO using the generated credentials.

    For example, the following Python code using the MinIO Python SDK connects to the MinIO deployment and returns a list of buckets:

    from minio import Minio
    
    client = MinIO(
       "minio-url.example.net:9000",
       access_key = "ACCESS_KEY",
       secret_key = "SECRET_KEY",
       session_token = "SESSION_TOKEN"
       secure = True
    )
    
    client.list_buckets()
  4. Next Steps

    Applications should implement the STS AssumeRoleWithWebIdentity flow using their SDK of choice. When STS credentials expire, applications should have logic in place to regenerate the JWT token, STS token, and MinIO credentials before retrying and continuing operations.

    Alternatively, users can generate access keys through the MinIO Console for the purpose of creating long-lived API-key like access using their Keycloak credentials.

Enable the Keycloak Admin REST API

MinIO supports using the Keycloak Admin REST API for checking if an authenticated user exists and is enabled on the Keycloak realm. This functionality allows MinIO to more quickly remove access from previously authenticated Keycloak users. Without this functionality, the earliest point in time that MinIO could disable access for a disabled or removed user is when the last retrieved authentication token expires.

This procedure assumes an existing MinIO deployment configured with Keycloak as an external identity manager.

1) Create the Necessary Client Scopes

Navigate to the Client scopes view and create a new scope:

Name

Set to a recognizable name for the scope (minio-admin-API-access)

Mappers

Select Configure a new mapper

Audience

Set the Name to any recognizable name for the mapping (minio-admin-api-access-mapper)

Included Client Audience

Set to security-admin-console.

Navigate to Clients and select the MinIO client

  1. From Service account roles, select Assign role and assign the admin role
  2. From Client scopes, select Add client scope and add the previously created scope

Navigate to Settings and ensure Authentication flow includes Service accounts roles.

2) Validate Admin API Access

You can validate the functionality by using the Admin REST API with the MinIO client credentials to retrieve a bearer token and user data:

  1. Retrieve the bearer token:

    curl -d "client_id=minio" \
         -d "client_secret=secretvalue" \
         -d "grant_type=password" \
         http://keycloak-url:port/admin/realms/REALM/protocol/openid-connect/token
  2. Use the value returned as the access_token to access the Admin API:

    curl -H "Authentication: Bearer ACCESS_TOKEN_VALUE" \
         http://keycloak-url:port/admin/realms/REALM/users/UUID

    Replace UUID with the unique ID for the user which you want to retrieve. The response should resemble the following:

    {
       "id": "954de141-781b-4eaf-81bf-bf3751cdc5f2",
       "createdTimestamp": 1675866684976,
       "username": "minio-user-1",
       "enabled": true,
       "totp": false,
       "emailVerified": false,
       "firstName": "",
       "lastName": "",
       "attributes": {
          "policy": [
             "readWrite"
          ]
       },
       "disableableCredentialTypes": [],
       "requiredActions": [],
       "notBefore": 0,
       "access": {
          "manageGroupMembership": true,
          "view": true,
          "mapRoles": true,
          "impersonate": true,
          "manage": true
       }
    }

    MinIO would revoke access for an authenticated user if the returned value has enabled: false or null (user was removed from Keycloak).

3) Enable Keycloak Admin Support on MinIO

MinIO supports multiple methods for configuring Keycloak Admin API Support:

You can use the mc idp openid update command to modify the configuration settings for an existing Keycloak service. You can alternatively include the following configuration settings when setting up Keycloak for the first time. The command takes all supported OpenID Configuration Settings:

mc idp openid update ALIAS KEYCLOAK_IDENTIFIER \
   vendor="keycloak" \
   keycloak_admin_url="https://keycloak-url:port/admin"
   keycloak_realm="REALM"
  • Replace KEYCLOAK_IDENTIFIER with the name of the configured Keycloak IDP. You can use mc idp openid ls to view all configured IDP configurations on the MinIO deployment
  • Specify the Keycloak admin URL in the keycloak_admin_url configuration setting
  • Specify the Keycloak Realm name in the keycloak_realm

Set the following environment variables in the appropriate configuration location, such as /etc/default/minio.

The following example code sets the minimum required environment variables related to enabling the Keycloak Admin API for an existing Keycloak configuration. Replace the suffix _PRIMARY_IAM with the unique identifier for the target Keycloak configuration.

MINIO_IDENTITY_OPENID_VENDOR_PRIMARY_IAM="keycloak"
MINIO_IDENTITY_OPENID_KEYCLOAK_ADMIN_URL_PRIMARY_IAM="https://keycloak-url:port/admin"
MINIO_IDENTITY_OPENID_KEYCLOAK_REALM_PRIMARY_IAM="REALM"

3 - Configure Silo Authentication with OpenID

Overview

MinIO supports using an OpenID Connect (OIDC) compatible IDentity Provider (IDP) such as Okta, KeyCloak, Dex, Google, or Facebook for external management of user identities.

This page has procedures for configuring OIDC for MinIO deployments in Kubernetes and Baremetal infrastructures.

This procedure covers:

This procedure is generic for OIDC compatible providers. Defer to the documentation for the OIDC provider of your choice for specific instructions or procedures on authentication and JWT retrieval.

Prerequisites

OpenID-Connect (OIDC) Compatible IDentity Provider

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 MinIO cluster must have bidirectional access to the OIDC provider.

Review Access Management Behavior

Ensure each user identity intended for use with MinIO has the appropriate claim configured such that MinIO 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 MinIO cluster.

For JWT claim-based authentication, MinIO only supports OIDC flows using the OpenID Authorization Code Flow.

Access to MinIO Cluster

This procedure uses mc for performing operations on the MinIO 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 MinIO cluster.

Configure MinIO with OpenID External Identity Management

  1. Create a new OpenID Configuration

    Use the mc idp openid add command to create a new OIDC configuration for the MinIO cluster. The following example command assumes using the JWT claims returned by the OIDC provider for authorization through policy assignment.

    mc idp openid add ALIAS \
      client_id=minio-oidc-client-id \
      client_secret=minio-oidc-client-secret \
      config_url="https://openid-provider.example.net/REALM/.well-known/openid-configuration" \
      claim_name="minio-policies" \
      scopes="openid,groups"

    You can also configure RoleArn-based functionality where all authenticated users have a single policy dictated by the role_policy setting. For example, set role_policy="readOnly" to assign all authenicated users the built-in read-only policy.

  2. Review the MinIO Server logs

    The MinIO process restarts as part of the new configuration. Examine the logs to ensure the OIDC configuration persisted successfully.

    If configuring role_policy for one or more configurations, the output includes an ARN for use with the STS API.

  3. Generate S3-Compatible Temporary Credentials using OIDC Credentials

    MinIO requires clients authenticate using AWS Signature Version 4 protocol with support for the deprecated Signature Version 2 protocol. Specifically, clients must present a valid access key and secret key to access any S3 or MinIO administrative API, such as PUT, GET, and DELETE operations.

    Applications can generate temporary access credentials as-needed using the AssumeRoleWithWebIdentity Security Token Service (STS) API endpoint and the JSON Web Token (JWT) returned by the OIDC provider.

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

    Once the application retrieves the JWT token, use the AssumeRoleWithWebIdentity endpoint to generate the temporary credentials:

    POST https://minio.example.net?Action=AssumeRoleWithWebIdentity
    &WebIdentityToken=TOKEN
    &Version=2011-06-15
    &DurationSeconds=86400
    &Policy=Policy
    • Replace the TOKEN with the JWT token returned in the previous step.

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

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

      Omit to use the policy associated to the OpenID user policy claim.

    You can optionally include the RoleArn parameter with the ARN string of your preferred single-policy OIDC configuration.

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

    See the AssumeRoleWithWebIdentity for reference documentation.