Keycloak
gunkanmaki.keycloak
A Docker Compose file for Keycloak alone, generated from the catalog and checked by the safety inspector. No account needed.
Identity and access management server implementing OIDC, OAuth 2.0 and SAML, with user federation, identity brokering, fine-grained authorisation and per-realm isolation of tenants.
Keycloak divides configuration into realms, each with its own users, clients, roles and login theme, so one server can serve several unrelated applications or tenants without them seeing one another. It federates users from LDAP and Active Directory, brokers logins to external identity providers, and issues tokens whose claims are shaped by configurable mappers. An authorisation service adds resource-and-policy evaluation for applications needing decisions rather than only identity. The container starts in development mode by default; production mode requires an external database, a hostname and explicit TLS or proxy configuration.
You know it worked when
- The administration console loads and the initial administrator can sign in.
- A realm other than master exists with at least one client registered.
- A user created in that realm completes a login.
- A client obtains a token whose claims contain the expected roles.
- An exported realm file reproduces the configuration on a fresh instance.
Known sharp edges
- The default start command runs in development mode against an embedded database, and everything written there is lost when the container is recreated.
- Production mode refuses to start until hostname and either TLS or a proxy mode are set, which is the most common first-run failure.
- Realm configuration is held only in the database; without an export, the entire identity configuration exists in one place with no file representation.
- Successive major versions have renamed configuration options and changed defaults, so a moving tag can break a working deployment on restart.