Loading…
Wednesday, October 5 • 3:00pm - 3:25pm
Service identity and Flexible Keystone Roles

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

Right now keystone has support for just two roles within keystone. Keystone Admin and Keystone Service Admin. What operations a role could do is defined in the code. Build a layer that would allow us to map operations and keystone roles. This way we could provide a flexible way of tying roles and operations that a role is allowed to do within keystone. Users of keystone could then add their own roles specific to keystone and also dictate what a role could do. Right now keystone only has a concept of user who could talk to keystone.We also have a role called service admin role, which a user could get and do bunch of operations posing as a service that wants to communicate to keystone. My proposal is to support individual applications to talk to keystone by providing an service id exclusive to that service and a service credentials (Could be a Token). This way we also make a clear difference between what a user is and what a service is. Every service that wants to talk to keystone could register itself and get an application id and credentials. => Some one like a keystone admin does it. Every service then could be allowed to do a bunch of operations based on the nature of the service. => Ex validating token, CRUD on roles, endpoint templates specific to a service Benefits are - Tracking => Eventually we might have needs to build tracking on what calls keystone gets.This would allow us to differentiate between services and users making calls. - Limiting => We could set limits on no of calls a service could make - Separation of concerns => we make a clear separation between users and services

Wednesday October 5, 2011 3:00pm - 3:25pm EDT
Salon A

Attendees (0)