Keycloak for coworking identity

Keycloak centralizes identity, SSO, brokering, and federation for internal tools. A coworking operator should begin with one staging application and staff identities, not door access or a whole member estate.

Manual tasks reduced: applying approved sign-in and session policies across a bounded staff application pilot. People still approve identity, privileges, emergency access, terminations, and security exceptions.

Fit and non-fit

Good fit: a technically operated self-hosted stack with duplicate staff accounts across a wiki, help desk, or booking tool and a need for consistent joiner/leaver controls.

Poor fit: a team without identity, OIDC/OAuth, Linux, Postgres, and break-glass expertise; a direct assumption that SSO secures physical access; or a migration that cannot tolerate identity-provider downtime.

License and cost boundary

Keycloak is OSI-approved open source under Apache-2.0. Software cost is separate from production cost. Budget for compute, Postgres, reverse proxy/TLS, setup and client migration, high-availability and update work, any external extensions, and specialist support. No paid feature or price is inferred from the license.

Record software, hosting, setup, maintenance, plugins/extensions, and support separately; mark each as applicable, not applicable, or unknown rather than assuming a zero cost.

Prerequisites and data map

Define an identity owner, security owner, recovery owner, authoritative staff roster, MFA policy, realm boundaries, client inventory, and break-glass procedure.

Data	Source	Keycloak use	Exit/fallback
Staff identity	Approved staff roster	User identity	Reconcile to roster
Group membership	Role matrix	App authorization claims	Export role matrix
Credentials/MFA	User enrollment	Authentication	Recovery process, never informal sharing
Session metadata	Keycloak	Security and operations	Retention-limited logs

Keycloak holds personal data, credential hashes, groups, and session metadata. Payment data is not in scope.

Smallest useful experiment

Follow official documentation to create one staging realm, connect one non-critical application through OIDC, add two staff users, and practice disabling a test user. Prove the app fails safely and the break-glass route works before any production dependency.

Implementation sequence

1. Inventory the single pilot application’s current login and emergency access.
2. Review deployment, realm, client, OIDC, backup, and upgrade guidance in the official docs.
3. Build isolated staging with TLS, Postgres, restricted administration, and monitored availability.
4. Configure least-privilege client settings and two test identities.
5. Test login, logout, disablement, failed login, recovery, and IdP outage behavior.
6. Document joiner/leaver approval, MFA, realm/client review, and break-glass use.
7. Complete realm/data backup and clean restore before adding another application.

Security and privacy controls

• Separate administration from routine staff access and protect break-glass credentials.
• Require TLS and an approved MFA policy; restrict redirect URIs and client secrets.
• Minimize identity attributes and group claims released to each application.
• Apply supported security updates and review logs with a defined retention period.
• Review client and realm configuration changes; test recovery outside the primary identity path.
• Keep physical access decisions and member enrollment outside the pilot.

Backup, export, and restore test

Use only officially documented database and realm export/restore methods appropriate to the deployment. Back up Postgres, configuration, realm/client definitions, and required keys while protecting backup access separately.

Restore to a clean isolated environment. Verify both users, groups, client configuration, login, disablement, and break-glass access. Record what secrets or keys need separate recovery. A file existing in backup storage is not a passed restore test.

Integrations and manual handoffs

No integrations are catalog-verified. OIDC to one staging app is the only assumed pilot connection and must follow that app’s and Keycloak’s official docs. HR/staff roster changes remain a manual approved handoff to identity administrators until a separate integration is verified.

Human oversight

People own realm/client reviews, MFA policy, access approval, leaver timing, incident response, and break-glass use. Keycloak standardizes authentication and access changes; it does not decide who should have access.

Automation and approval boundaries

Keycloak may authenticate enrolled identities, enforce approved authentication flows, issue protocol tokens/claims, expire sessions, and disable an account after an approved administrator action. It must not decide employment status, membership eligibility, role entitlement, physical access, disciplinary action, identity proofing exceptions, or emergency access. A manager approves staff entitlement; the identity owner approves roster/group mapping and leaver requests; the application owner approves client claims and fallback; security approves MFA, redirect URIs, secrets, flows, federation, and break-glass; the recovery owner approves restore/rollback; two named people review production realm changes where staffing permits.

Acceptance, operations, and failure handling

In isolated staging, test valid login/logout, wrong password behavior, MFA/recovery if in scope, disabled-user denial, session termination, least-privilege claims, invalid redirect rejection, secret handling, application-local fallback, Keycloak/DB outage behavior, admin lockout recovery, break-glass audit, backup, clean restore, and rollback to the prior app login. Use test identities only. OIDC success with one app does not prove federation, other clients, HA, security, scale, or physical-access suitability.

On identity outage, freeze realm/client changes, preserve time-correlated Keycloak, database, proxy, and application evidence under retention rules, and invoke only the application’s approved fallback or break-glass path. Do not broadly bypass authorization. Reconcile every emergency access event and invalidate temporary credentials/sessions after recovery.

Professional help threshold

Use an experienced identity/security engineer before production Internet exposure, federation to HR/directories/social providers, custom authentication flows, cryptographic key changes, multi-site HA, or migration of a critical application. Obtain privacy/legal advice for identity proofing, biometrics, employee monitoring, data residency/retention, or cross-border identity data. Physical-access and life-safety designs require the relevant access-control and safety professionals; this pilot excludes them.

Operational checklist

• Identity, security, and recovery owners named
• Authoritative staff roster and role matrix recorded
• TLS, MFA, admin separation, and redirect restrictions reviewed
• Pilot app fallback documented
• Disablement and outage tests passed
• Realm/client changes are reviewed
• Database/realm restore passed on clean staging
• Break-glass access tested and audited

Rollback and exit

Preserve the pilot application’s previous authentication until acceptance. Roll back by disabling the new login path, restoring the prior app configuration, revoking the test client, and reconciling identities. Before broader adoption, export realm/client configuration, retain an independent role matrix, and document how every application returns to local or replacement identity without locking out operators.

Verification and unknowns

Snapshot verified 2026-07-17 from Keycloak, the official repository, and documentation.

Unknown until designed and tested: version-specific deployment details, HA sizing, extension licenses, application compatibility, migration behavior, support arrangements, recovery objectives, and regulatory requirements.

Flagship requirement coverage (33 points)

1. Coworking purpose: centralize staff login for one non-critical staging application.
2. Outcome: consistent approved authentication and reversible joiner/leaver control.
3. Good fit: technically operated stack with identity, application, and recovery ownership.
4. Non-fit: no identity expertise, physical-access assumption, or intolerable IdP dependency.
5. Named owners: manager, identity, application, security, privacy, technical, and recovery owners.
6. Prerequisites: roster, role matrix, realm/client scope, MFA, fallback, and break-glass design.
7. Skills: OIDC/OAuth, identity security, Keycloak, Linux, Postgres, TLS, and recovery.
8. License: Apache-2.0; extensions and support have independent terms.
9. Cost model: compute, database, proxy, setup, HA, upgrades, extensions, and support.
10. Official sources: official site, repository, and documentation are linked and dated.
11. Evidence limit: one staging client proves no federation, HA, scale, compliance, or physical access.
12. Data map: identities, groups, credentials/MFA, claims, sessions, logs, clients, and keys.
13. Privacy: minimize attributes/claims; approve retention, federation, and identity-data use.
14. Security: admin separation, MFA, TLS, redirects, secrets, updates, keys, and break-glass.
15. Compliance: identity/privacy and physical-access professional-help boundaries are explicit.
16. Allowed automation: approved authentication, tokens/claims, sessions, and requested disablement.
17. Prohibited decisions: status, eligibility, entitlement, discipline, proofing exceptions, and access.
18. Human approvals: manager, identity, app, security, and recovery gates are explicit.
19. Smallest experiment: one realm, one app, two test users, and one disablement.
20. Implementation: inventory, stage, configure, test, document controls, restore, then decide.
21. Configuration baseline: realm, client, redirect, claims, flows, roles, secrets, keys, and fallback.
22. Integrations: only the tested staging OIDC client is in scope; none is catalog-verified.
23. Exceptions: bad login, disabled user, outage, lockout, invalid redirect, and break-glass.
24. Acceptance tests: authentication, authorization claims, outage, recovery, restore, and rollback.
25. Monitoring: availability, database, failed login, admin event, certificate, backup, and updates.
26. Routine operations: approved joiner/leaver, client review, patching, key/secret, and restore tests.
27. Backup: database, realm/client config, keys, secrets, and external dependencies are covered.
28. Restore: clean isolated restore verifies identities, client, claims, disablement, and admin recovery.
29. Upgrade: read version-specific official guidance; stage database and client regressions first.
30. Rollback: return the app to preserved prior authentication and reconcile emergency access.
31. Exit: export config/role mapping and document every app’s local/replacement login route.
32. Manual fallback: only approved app-local or break-glass access; never broad authorization bypass.
33. Expert review and cadence: identity/security review precedes production and material topology changes.