Sovereign FerrisKey IAM (OIDC SSO)
Centralizing authentication across an organization is convenient: one login opens every service. But that single gateway also becomes the most sensitive point of your information system. Every login, every identity, every group transits through it. Handing it to Okta, Auth0 or Entra ID means placing that identity directory on infrastructure subject to US law.
Bunker runs FerrisKey instead, an open-source identity and access management (IAM) server written in Rust and released under the Apache-2.0 licence, hosted in Europe. Your identities stay on the continent, and the service stays re-internalizable: both the software and the data can move back onto your own infrastructure.
Access: a FerrisKey server dedicated to your project, for example managed-yourslug-ferriskey-yourproject.apps.france-nuage.fr.
What an IAM does
An IAM (Identity and Access Management) is the central directory that answers two questions for all your applications: who are you? (authentication) and what are you allowed to do? (authorization). Instead of each piece of software managing its own accounts and passwords, they all delegate that responsibility to FerrisKey.
Concretely, FerrisKey provides:
- OIDC single sign-on (SSO): the user logs in once, then reaches every connected service without re-entering credentials.
- Multi-organization realms: each organization (or entity, or client) gets its own isolated space, with its users, groups and rules.
- Identity brokering: FerrisKey can delegate authentication to another identity provider, which enables the federation described below.
- A self-service admin UI: create a realm, declare an application (OIDC client), manage users and roles, without filing a ticket.
OIDC-compatible with Keycloak
FerrisKey exposes the same OpenID Connect URLs as Keycloak. The discovery document sits at the standard location:
https://managed-yourslug-ferriskey-yourproject.apps.france-nuage.fr/realms/<your-realm>/.well-known/openid-configuration
and the endpoints follow the same /realms/<your-realm>/... convention (authorization, token, userinfo, JWKS). The practical upshot: an application already configured for Keycloak connects to FerrisKey by simply changing the issuer URL. Any standard OIDC client library (on the application side) works without adaptation.
Hub-and-spoke federation
The managed service is built on a hub-and-spoke federation. Bunker runs a central FerrisKey (the hub) that brokers authentication to a FerrisKey dedicated to your organization (the spoke). Each organization keeps its own realm, users and rules.
The benefit: your applications only talk to your FerrisKey, and that space is yours. At any time you can export its configuration and users to re-internalize it on your own infrastructure.
Comparison
| Criterion | Bunker (managed FerrisKey) | Okta / Auth0 / Entra ID (SaaS) | Self-hosting |
|---|---|---|---|
| Identity directory hosting | In Europe | In the US | Up to you |
| Law governing the identities | EU law | Subject to US law | Up to you |
| Protocol | OpenID Connect (Keycloak-compatible) | Proprietary + standards | Up to you |
| Reversibility | Open source (Apache-2.0), re-internalizable | Proprietary SaaS | Total |
| Cost | Monthly plan, users included | Often per active user | On you |
| Updates & availability | Managed | Managed | On you |
Getting started
- Receive your realm: Bunker provisions a dedicated realm on your FerrisKey server.
- Declare your applications: in the admin UI, create one OIDC client per application to connect (redirect URI, client type).
- Configure each application: point the application's OIDC configuration at your realm's discovery URL (above). Most frameworks only ask for the issuer URL, the client id and its secret.
- Create your users and groups, or connect an existing identity provider through brokering.
The First login tutorial walks through bringing up a first service on Bunker, and the Authentication page describes the IAM's role in the platform.
Use cases
- Unify access to your managed services: one login for your OIDC-connected tools (Grafana, Metabase, and any compatible software).
- Partition several entities: one subsidiary, client or team per realm, isolated from one another.
- Take back a directory subject to US law: migrate from Okta, Auth0 or Entra ID to an IAM hosted in Europe.
Current limitations
FerrisKey is a young project, and the managed offer is deliberately transparent about its scope. At this stage:
- OIDC only: FerrisKey supports OpenID Connect. SAML and LDAP are not supported. An application that can only authenticate via SAML, or a service that queries an LDAP directory directly, cannot go through FerrisKey yet.
- Logout is per service: back-channel single logout is not yet propagated to all connected applications. In practice, logging out happens service by service today; a session open on another application may stay active until it expires.
These items are on the roadmap. If your need depends on them, flag it before you start: we'll tell you where support stands and scope the rollout with you.
Reversibility
Everything is open source. You could run FerrisKey yourself: that is exactly what an Apache-2.0 licence allows. Bunker operates it for you (updates, availability, backups) without locking you in. Your realm configuration and your users export cleanly, and you keep the right to bring everything back onto your own hardware whenever you decide. You are not swapping a US lock-in for a European one.
References
- FerrisKey repository to dig deeper into the project
- OpenID Connect specification on the authentication protocol
- Authentication to understand the IAM's role in the Bunker platform
Okta is a trademark of Okta, Inc. Auth0 is a trademark of Okta, Inc. Microsoft Entra ID is a trademark of Microsoft Corporation. Keycloak is a trademark of Red Hat, Inc. Rust is a trademark of the Rust Foundation. Bunker is neither affiliated with nor endorsed by these companies; these names are used descriptively, to refer to the technologies deployed or compared.