Improvements to Identity Federation in Keystone
summary
During the Ussuri cycle Keystone adds two concrete federation features: expiring group memberships persisted in the DB with a configurable per‑IdP TTL that refreshes on each login, enabling creation and use of application credentials and trusts where previously only token‑lifelong mappings existed; and CRUD for federated attributes via the OpenStack API, letting operators create, update or delete shadow users and link multiple federated accounts ahead of first login so role assignments can be prepopulated.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:24We'll talk about • What is identity federation • How keystone implements it • Approaches to authorization and limitations • Improvements • Future work
- 1:15Identity federation primer
- 1:41Glossary • Identity provider - source of the identity information, authenticates and
- 2:33Federated identity in keystone
- 3:42Mappings continued • Temporarily grant membership to a group • Create a project and associate a role to the authenticating user • Restrict authentication to members of a specific
- 4:31Application credentials
- 8:02What about authorization? • Assign group membership through mappings • Assign roles manually to the created user • Create project and assign roles automatically through mappings
- 8:37Authorization via groups
- 9:59Previous limitations Group membership was only valid for the duration of the token and was not persisted in the database.
- 10:38Expiring group memberships Ussuri introduced the concept of expiring group memberships. Group in IdP Group in Keystone (expires) Group membership is persisted in database • Validity is configured per-IdP • Validity is reset every time user authenticates as member of group
- 12:16Authorization via assignments After authentication, a representation of the user is stored in the database. Called a shadow user.
- 12:49Comparing to group mappings • Shadow user only created after initial authentication • Burden on operators to keep role/group memberships in sync
- 13:05CRUD operations on federated users Ussuri introduced the possibility to create and modify the federated user attributes in keystone. Possible now to create users ahead of time, rather than having to wait on initial authentication
- 13:56Authorization future steps • Assign group membership through mappings • Assign roles manually to the created user • Create project and assign roles automatically through mappings
related talks
22mThe Future of Identity (Keystone)
33mPractical Federated Identity
29mUnify Your OpenStack with Your Identity Provider
35mAuthentication Challenges In Multi-Region Deployments
29mCompliance and Identity Management in Kubernetes
12mWhat Is New and Coming for Managing Cloud Native Identities in…
01h 12mIdentity 2.0: the what, why and how of social and federated login
19mIdentity:The missing link in API security