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