Using an identity broker to augmenting existing login solution
summary
An identity broker isolates SMART on FHIR authorization from an unchanged central login by deploying Keycloak with a custom extension that calls a lambda lookup during login to query patient identifiers in the FHIR repo. The system enforces no cache so lookups run on each first login, performs auto-hydration to create missing Patient resources, and stores consent records for dependent access. It rejects logins when an identifier maps to multiple patients and raises alerts. Latency is acceptable because authZ and the repo are cohosted.
AI-written summary · about
chapters (9)
- 0:00Introduction and setup
- 1:09Project background and goals
- 3:15Identity broker concept and benefits
- 5:23Mapping identities to repository
- 7:13Handling missing patient records
- 9:17Dependent access and consent records
- 13:16Discovery process and challenges
- 15:25Q&A session part one
- 18:14Q&A session part two
related talks
01h 12mIdentity 2.0: the what, why and how of social and federated login
25mIdentities and Authentication for Your Agents With Keycloak
04mYou Don't Need a New Identity Platform for the AI Era
36mSecuring Agentic Platforms with Zero-Trust Workload Identities
01h 03mSingle Sign On with Keycloak: why and how
37mSMART on FHIR
01h 22mIdentity for AI Agents
25mThe Power of Combining Identity Wallets and Passkeys