Much of the future work we need to do on Keystone falls into issued of scope. I’m going to merely try and define the problems here, and avoid talking about solutions. I’ll try to address more specific aspects in future posts.

There are two phases to the problem.

1. Administration
2. Use

Here are the scope issues of the Definitions stage:

1. Different services need different role-names to document specific functions, but there is no easy way to delegate the creation of those role names.
2. Role names are often in conflict. What is meant by Admin? Depends on who you ask.
3. There is no cross checking between the set of role assignments available and the policy rules for a given service.
4. Any administrator can create any role assignment for any user within the scope of their project or domain. To be honest, this might not be a problem, but it keeps coming up.

Here are the scope issues of the Use stage:

1.  The service catalog is too big. By default, every endpoint for every service is included, and most are rarely used.
2. A user cannot request a token for a specific service
3. A user cannot request a token for a limited set of roles.
4. A token can be used multiple times even if it was intended for a single use
5. Tokens live a long time, which means, that they are susceptible to abuse long after their intended use.
6. Almost all token used by the CLI are used once, but don’t expire until the default expiry.
7. Domain scoping and unscoped tokens are confusing.
8. Only an administrator can check if a token is valid.
9. Tokens can only be signed by a single private key, regardless of the number of Keystone servers deployed.
10. There is no way to explicitly limit what scope Keystone can sign for, or what roles-assignments should be allowed from a specific Keystone server.