Service Isolation and Roles Delegation
The current model for validation Keystone tokens by OpenStack services using the middleware does not provide sufficient isolation of services. Scoping of tokens to a tenant/project level is not sufficient to isolate services and to prevent services from using the tokens issued by Keystone and scoped for a tenant to be used by services for accessing user’s resources on other services within the same tenant. Once the user passes a token to a service the user loses control on how the token is used by a service. The services may use the tokens provided by a user to access other services and confidential information without user’s knowledge. In some cases, this is a desired behavior where a service really needs to access some resources on another service on user’s behalf. However, the end user must explicitly grant permissions for using of his/her token to access other services.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Morgan Fainberg
Related branches
Related bugs
Sprints
Whiteboard
Etherpad:
https:/
This approach has serious overhead with regard to Key management. I don't think it is required or warranted.
Instead, a simpler approach is for the User to use X509 client certificates. When a user requests a token from Keystone, the signature for the X509 is embedded in the token.
As far as scoping the token to an endpoint or service, this approach is too limiting, as it will only be scoped to the holder of the key. If we want to scope a token to a class of service, or to a subset of endpoints, we cannot do that with this approach. Instead, the token should contain the set of acceptable recipients of the token. That can be any subset of the service catalog.
If we want to have Kerberos style two way verification of identity, lets just use Kerberos. We can embed the token data into the service ticket and have the same semantics.
This is superseded by the token constraints spec/discussion that is active.
