Files
minio/docs/iam/identity-management-plugin.md
T
Feng Ruohang fd2ca1c6d2 docs: rebrand the repository documentation, templates and dashboards
README, README_ZH, SECURITY, COMPLIANCE, CONTRIBUTING, NOTICE,
code_of_conduct, the vulnerability and PR-etiquette documents, the GitHub issue
and pull request templates, and the docs/ tree all present Silo as the product.
The Grafana dashboards under docs/metrics/prometheus/grafana/ have their panel
titles and descriptions rebranded while every minio_* query, label and
expression is left alone, so existing alerts and recording rules keep matching.

The distinction the review demanded is applied per hit rather than by
search-and-replace:

- Product and command text becomes Silo and silo: install and run instructions,
  systemd examples, compose services, download links, badges.
- Protocol and interface text keeps MinIO: MINIO_* variables, minio_* metrics,
  x-minio-* headers, /minio/* routes, .minio.sys, arn:minio, and API field and
  error names.
- Attribution keeps MinIO and gains the fork's own: the AGPL obligations,
  original copyright, CREDITS and NOTICE stay, with the modification notice
  added alongside rather than replacing them.
- Historical and third-party references are left as facts, not rewritten for
  brand tidiness.

README and README_ZH each carry an explicit non-affiliation notice, document
the side-by-side package migration including the
/etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in for keeping a
legacy UID/GID, and state that recursive chown is never performed. The trademark
attribution uses the policy's approved "based on MinIO technology" wording, not
the shortened form the policy rejects.

github.com/pgsty/minio links are left in place and labelled transitional. The
repository has not been renamed, and rewriting them now would produce documented
URLs that 404 until the cutover; they change in the cutover commit together with
the goreleaser release target, the OCI source label and the raw-content branch.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-06 08:49:30 +08:00

4.1 KiB

Identity Management Plugin Guide Slack

Introduction

To enable the integration of custom authentication methods, Silo can be configured with an Identity Management Plugin webhook. When configured, this plugin enables the AssumeRoleWithCustomToken STS API extension. A user or application can now present a token to the AssumeRoleWithCustomToken API, and Silo verifies this token by sending it to the Identity Management Plugin webhook. This plugin responds with some information and Silo is able to generate temporary STS credentials to interact with object storage.

The authentication flow is similar to that of OpenID, however the token is "opaque" to Silo - it is simply sent to the plugin for verification. CAVEAT: There is no console UI integration for this method of authentication and it is intended primarily for machine authentication.

It can be configured via Silo's standard configuration API (i.e. using mc admin config set/get), or equivalently with environment variables. For brevity we show only environment variables here:

$ mc admin config set mysilo identity_plugin --env
KEY:
identity_plugin  enable Identity Plugin via external hook

ARGS:
MINIO_IDENTITY_PLUGIN_URL*          (url)       plugin hook endpoint (HTTP(S)) e.g. "http://localhost:8181/path/to/endpoint"
MINIO_IDENTITY_PLUGIN_AUTH_TOKEN    (string)    authorization token for plugin hook endpoint
MINIO_IDENTITY_PLUGIN_ROLE_POLICY*  (string)    policies to apply for plugin authorized users
MINIO_IDENTITY_PLUGIN_ROLE_ID       (string)    unique ID to generate the ARN
MINIO_IDENTITY_PLUGIN_COMMENT       (sentence)  optionally add a comment to this setting

If provided, the auth token parameter is sent as an authorization header.

MINIO_IDENTITY_PLUGIN_ROLE_POLICY is a required parameter and can be list of comma separated policy names.

On setting up the plugin, the Silo server prints the Role ARN to its log. The Role ARN is generated by default based on the given plugin URL. To avoid this and use a configurable value set a unique role ID via MINIO_IDENTITY_PLUGIN_ROLE_ID.

REST API call to plugin

To verify the custom token presented in the AssumeRoleWithCustomToken API, Silo makes a POST request to the configured identity management plugin endpoint and expects a response with some details as shown below:

Request POST to plugin endpoint

Query parameters:

Parameter Name Value Type Purpose
token string Token from the AssumeRoleWithCustomToken call for external verification

Response

If the token is valid and access is approved, the plugin must return a 200 (OK) HTTP status code.

A 200 OK Response should have application/json content-type and body with the following structure:

{
    "user": <string>,
    "maxValiditySeconds": <integer>,
    "claims": <key-value-pairs>
}
Parameter Name Value Type Purpose
user string Identifier for owner of requested credentials
maxValiditySeconds integer (>= 900 seconds and < 365 days) Maximum allowed expiry duration for the credentials
claims key-value pairs Claims to be associated with the requested credentials

The keys "exp", "parent" and "sub" in the claims object are reserved and if present are ignored by Silo.

If the token is not valid or access is not approved, the plugin must return a 403 (forbidden) HTTP status code. The body must have an application/json content-type with the following structure:

{
    "reason": <string>
}

The reason message is returned to the client.

Example Plugin Implementation

A toy example for the Identity Management Plugin is given here.