Keycloak in daily operations: what a central identity provider taught us
Running a central identity provider for several applications: OIDC and SAML, a role model, and an audit approach that stays manageable.
For the past months we have been running a central Keycloak as the identity provider for several internal and external applications at an enterprise customer. The move is less spectacular than it sounds. Nobody notices a login that works, and that is precisely the standard an identity provider has to meet every day. What follows is the practitioner view, anonymized beyond the shape of the setup, about what changed in daily operations once logins had one home.
The setup in one paragraph
One Keycloak realm holds the users that several applications trust. Internal tools talk to it via OIDC, a number of established applications that speak SAML sit behind the same broker, and each application owns a client with a defined scope instead of holding its own directory. The effect compounds slowly: new access for an existing user is a role change in one place, and leaving the organization is one action instead of a tour through five admin panels.
Why the role model fights back
The honest lesson is that a central IdP does not simplify authorization; it forces you to actually model it. Roles in Keycloak are cheap to create and expensive to maintain, so the discipline that stuck for us is separation: roles answer "what may this identity do inside application X", while attributes answer "what is true about this identity across applications", and the application maps one into the other instead of the IdP knowing each app's fine print. The moment that rule slipped, we had applications making decisions on attributes that only made sense in another application's context, and the cleanup was worse than up front discipline would have been.
OIDC and SAML in the same house
Running OIDC and SAML clients side by side works, but the protocols leak their history into operations. OIDC made every change easy: a config value, a redeploy of the app, done. SAML, being XML-heavy by temperament, prefers ceremony: signed requests, precise clock agreement, and a metadata exchange that punishes the casual edit. Two operational rules emerged from that contrast. First, every SAML change goes through a test tenant and a documented diff of the metadata. Second, certificate rotation for the SAML signing keys is an event on the calendar, with its own runbook, not a task discovered by user reports.
Audit that stays tractable
An identity provider sees every authenticated event in the estate, which makes it both the best and the noisiest audit source. Logging everything produced a stream nobody read. What works instead is a small decision triangle: which events are security-relevant (login failures, permission changes, admin actions, token anomalies), which are merely volume (routine successful logins), and which fields are worth keeping vs. which personal data must not outlive its purpose. We keep full detail on the first category with a longer retention, aggregate the second, and drop personal fields from the third at the source. The audit question that is genuinely hard is not capture; it is deciding what you will actually read, and under which routine. Ours became a fixed fifteen-minute weekly review with a standing query list, and the list has a named owner. When the owner changes, the list is walked through once, together. Two quarters in, the standing questions carry stable names, so an anomaly report can reference them unambiguously; before that, the same finding was described in three different dialects by three different reviewers. The names stuck immediately, and every new reviewer reads them before writing their first finding report.
Operations in the day-to-day
Running Keycloak is ordinary operations work, and that is a compliment. Upgrades matter and get a staging pass, because the schema and theme surface move between versions. Sessions get an explicit policy, because "until the token is invalid" is not a policy but a surprise. And the break-glass account is tested on schedule, because the one login that must survive every failure is a thing you want proven at rest, not remembered under pressure. A final footnote lands on the user side: the realm's visible language drifts with every migration, and labels are part of operations as much as certificates are. A login page that suddenly speaks the wrong dialect produces support tickets that are indistinguishable from a real outage. A restore drill discipline applies here as well: the IdP's export is part of the estate's backups, and it gets restored at least once to prove the loop.
If you are considering centralizing your applications' logins: the decision is mostly about your role model and your audit appetite, not about the product. The blog post on restore drills explains why testable state beats stored hope in operations, the blog and the support pages carry more of the daily-practice context, and the contact page is the direct way to reach us for an exchange on identity projects.