This is the multi-page printable view of this section. .
External Identity Management
- 1: Configure Silo Authentication with Active Directory / LDAP
- 2: Configure Silo Authentication with Keycloak
- 3: Configure Silo Authentication with OpenID
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:
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.
MINIO_IDENTITY_LDAP_LOOKUP_BIND_DNMINIO_IDENTITY_LDAP_LOOKUP_BIND_PASSWORDMINIO_IDENTITY_LDAP_USER_DN_SEARCH_BASE_DNMINIO_IDENTITY_LDAP_USER_DN_SEARCH_FILTER
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.
identity_ldap lookup_bind_dnidentity_ldap lookup_bind_passwordidentity_ldap user_dn_search_base_dnidentity_ldap user_dn_search_filter
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
AssumeRoleWithLDAPIdentitySecurity 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
AssumeRoleWithLDAPIdentitySecurity 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
-
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 ldapcommands.For distributed deployments, the
mc idp ldapcommand 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:
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.Notemc idp ldaprecommendedmc idp ldapoffers additional features and improved validation overmc admin config setruntime configuration settings.mc idp ldapsupports the same settings asmc admin configand theidentity_ldapconfiguration key.The
identity_ldapconfiguration key remains available for existing scripts and tools.MinIO supports specifying the AD/LDAP provider settings using environment variables.
The
minio serverprocess 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:
MINIO_IDENTITY_LDAP_SERVER_ADDRMINIO_IDENTITY_LDAP_LOOKUP_BIND_DNMINIO_IDENTITY_LDAP_LOOKUP_BIND_PASSWORDMINIO_IDENTITY_LDAP_USER_DN_SEARCH_BASE_DNMINIO_IDENTITY_LDAP_USER_DN_SEARCH_FILTER
For complete documentation on these variables, see Active Directory / LDAP Settings.
-
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 restartcommand to restart the deployment:Replace
ALIASwith the alias of the deployment to restart. -
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.
-
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, andDELETEoperations.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.
-
Replace the
LDAPUsernamewith the username of the AD/LDAP user. -
Replace the
LDAPPasswordwith the password of the AD/LDAP user. -
Replace the
Policywith 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
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
AssumeRoleWithWebIdentitySecurity 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
AssumeRoleWithWebIdentitySecurity 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
-
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 ConnectAlways display in console
Toggle to
OnClient authentication
Toggle to
OnAuthentication 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
OnAdvanced -> Advanced Settings -> Access Token Lifespan
Set to
1 Hour. -
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
OnOnce 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
policyToken Claim Name
Set to
policyAdd to ID token
Set to
OnClaim JSON Type
Set to
StringMultivalued
Set to
OnThis allows setting multiple
policyvalues in the single claim.Aggregate attribute values
Set to
OnThis allows users to inherit any
policyset in their GroupsOnce created, assign the Client Scope to the MinIO client.
- Navigate to Clients and select the MinIO client.
- Select Client scopes, then select Add client scope.
- Select the previously created scope and set the Assigned type to
default.
-
Apply the Necessary Attribute to Keycloak Users/Groups
You must assign an attribute named
policyto 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
policyand value of any policy (consoleAdmin)For Groups, navigate to Groups and select or create the Group:
Attributes
Create a new attribute with key
policyand value of any policy (consoleAdmin)You can assign users to groups such that they inherit the specified
policyattribute. 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:
If successful, the
access_tokencontains 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
policykey with one or more MinIO policies listed. -
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:
|
Set to a unique identifier for the Keycloak service, such as |
MINIO_CLIENTMINIO_CLIENT_SECRET |
Set to the Keycloak client ID and secret configured in Step 1 |
|
Set to the address of the Keycloak OpenID configuration document (keycloak-url.example.net:8080) |
|
Set to a user-facing name the MinIO Console displays as part of the Single-Sign On (SSO) workflow for the configured Keycloak service |
|
Set to a list of OpenID scopes you want to include in the JWT, such as |
|
Set to 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 |
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.
-
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
curlutility:-
Authenticate as a Keycloak user and retrieve the JWT token
- Replace the
USERandPASSWORDwith the credentials of a Keycloak user on theREALM. - Replace the
CLIENTandSECRETwith the client ID and secret for the MinIO-specific Keycloak client on theREALM
You can process the results using
jqor a similar JSON-formatting utility. Extract theaccess_tokenfield to retrieve the necessary access token. Pay attention to theexpires_infield to note the number of seconds before the token expires. - Replace the
-
Generate MinIO Credentials using the
AssumeRoleWithWebIdentityAPIReplace the
TOKENwith theaccess_tokenvalue returned by Keycloak.The API returns an XML document on success containing the following keys:
Credentials.AccessKeyId- the Access Key for the Keycloak UserCredentials.SecretAccessKey- the Secret Key for the Keycloak UserCredentials.SessionToken- the Session Token for the Keycloak UserCredentials.Expiration- the Expiration Date for the generated credentials
-
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:
-
-
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.
-
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 ConnectAlways display in console
Toggle to
OnClient authentication
Toggle to
OnAuthentication 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
OnAdvanced -> Advanced Settings -> Access Token Lifespan
Set to
1 Hour. -
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
OnOnce 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
policyToken Claim Name
Set to
policyAdd to ID token
Set to
OnClaim JSON Type
Set to
StringMultivalued
Set to
OnThis allows setting multiple
policyvalues in the single claim.Aggregate attribute values
Set to
OnThis allows users to inherit any
policyset in their GroupsOnce created, assign the Client Scope to the MinIO client.
- Navigate to Clients and select the MinIO client.
- Select Client scopes, then select Add client scope.
- Select the previously created scope and set the Assigned type to
default.
-
Apply the Necessary Attribute to Keycloak Users/Groups
You must assign an attribute named
policyto 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
policyand value of any policy (consoleAdmin)For Groups, navigate to Groups and select or create the Group:
Attributes
Create a new attribute with key
policyand value of any policy (consoleAdmin)You can assign users to groups such that they inherit the specified
policyattribute. 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:
If successful, the
access_tokencontains 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
policykey with one or more MinIO policies listed. -
Configure MinIO for Keycloak Authentication
MinIO supports multiple methods for configuring Keycloak authentication:
- Using a terminal/shell and the
mc idp openidcommand - Using environment variables set prior to starting MinIO
You can use the
mc idp openid addcommand to create a new configuration for the Keycloak service. The command takes all supported OpenID Configuration Settings:PRIMARY_IAMSet to a unique identifier for the Keycloak service, such as
keycloak_primaryMINIO_CLIENTMINIO_CLIENT_SECRETSet to the Keycloak client ID and secret configured in Step 1
config_urlSet to the address of the Keycloak OpenID configuration document (keycloak-url.example.net:8080)
display_nameSet to a user-facing name the MinIO Console displays as part of the Single-Sign On (SSO) workflow for the configured Keycloak service
scopesSet to a list of OpenID scopes you want to include in the JWT, such as
preferred_usernameoremailredirect_uri_dynamicSet to
onSubstitutes 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_URLvariable to set the redirect address for Keycloak to use.Set the following environment variables prior to starting the container using the
-e ENVVAR=VALUEflag.The following example code sets the minimum required environment variables related to configuring Keycloak as an external identity management provider.
_PRIMARY_IAMReplace the suffix
_PRIMARY_IAMwith 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.
Specify the address of the Keycloak OpenID configuration document (keycloak-url.example.net:8080)
Ensure the
REALMmatches the Keycloak realm you want to use for authenticating users to MinIOCLIENT_IDCLIENT_SECRETSpecify the Keycloak client ID and secret configured in Step 1
Specify the user-facing name the MinIO Console displays as part of the Single-Sign On (SSO) workflow for the configured Keycloak service
Specify the OpenID scopes you want to include in the JWT, such as
preferred_usernameoremailSet to
onSubstitutes 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_URLvariable 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
curlutility:-
Authenticate as a Keycloak user and retrieve the JWT token
- Replace the
USERandPASSWORDwith the credentials of a Keycloak user on theREALM. - Replace the
CLIENTandSECRETwith the client ID and secret for the MinIO-specific Keycloak client on theREALM
You can process the results using
jqor a similar JSON-formatting utility. Extract theaccess_tokenfield to retrieve the necessary access token. Pay attention to theexpires_infield to note the number of seconds before the token expires. - Replace the
-
Generate MinIO Credentials using the
AssumeRoleWithWebIdentityAPIReplace the
TOKENwith theaccess_tokenvalue returned by Keycloak.The API returns an XML document on success containing the following keys:
Credentials.AccessKeyId- the Access Key for the Keycloak UserCredentials.SecretAccessKey- the Secret Key for the Keycloak UserCredentials.SessionToken- the Session Token for the Keycloak UserCredentials.Expiration- the Expiration Date for the generated credentials
-
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:
-
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.
- Using a terminal/shell and the
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 ( |
Mappers |
Select Configure a new mapper |
Audience |
Set the Name to any recognizable name for the mapping ( |
Included Client Audience |
Set to |
Navigate to Clients and select the MinIO client
- From Service account roles, select Assign role and assign the
adminrole - 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:
-
Retrieve the bearer token:
-
Use the value returned as the
access_tokento access the Admin API:Replace
UUIDwith the unique ID for the user which you want to retrieve. The response should resemble the following:MinIO would revoke access for an authenticated user if the returned value has
enabled: falseornull(user was removed from Keycloak).
3) Enable Keycloak Admin Support on MinIO
MinIO supports multiple methods for configuring Keycloak Admin API Support:
- Using a terminal/shell and the
mc idp openidcommand - Using environment variables set prior to starting MinIO
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:
- Replace
KEYCLOAK_IDENTIFIERwith the name of the configured Keycloak IDP. You can usemc idp openid lsto view all configured IDP configurations on the MinIO deployment - Specify the Keycloak admin URL in the
keycloak_admin_urlconfiguration 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.
- Specify the Keycloak admin URL in the
MINIO_IDENTITY_OPENID_KEYCLOAK_ADMIN_URL - Specify the Keycloak Realm name in the
MINIO_IDENTITY_OPENID_KEYCLOAK_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:
- Configuring a MinIO cluster for an external OIDC provider.
- Using the MinIO
AssumeRoleWithWebIdentitySecurity Token Service (STS) API to generate temporary credentials for use by applications.
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
-
Create a new OpenID Configuration
Use the
mc idp openid addcommand 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.You can also configure
RoleArn-based functionality where all authenticated users have a single policy dictated by therole_policysetting. For example, setrole_policy="readOnly"to assign all authenicated users the built-in read-only policy. -
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_policyfor one or more configurations, the output includes an ARN for use with the STS API. -
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, andDELETEoperations.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
AssumeRoleWithWebIdentityendpoint to generate the temporary credentials:-
Replace the
TOKENwith the JWT token returned in the previous step. -
Replace the
DurationSecondswith the duration in seconds until the temporary credentials expire. The example above specifies a period of86400seconds, or 24 hours. -
Replace the
Policywith 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
RoleArnparameter 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.
-