Difference between revisions of "Keystone/Trusts"
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
| + | = Trusts = | ||
<< [[TableOfContents]]() >> | << [[TableOfContents]]() >> | ||
| + | == Use Cases == | ||
| + | # HEAT and failover. It needs to move a virtual machine from one host to another. | ||
| + | # Content production. Something generates a large file and needs to store it in swift. | ||
| + | |||
| + | In both cases, the users authorizes it at setup time to perform this action any time in the future, long after the token is expired. | ||
| + | |||
| + | == Discussion == | ||
"Keystone is the Delegation Service that handles all the delegations for users. It is trusted to ensure that | "Keystone is the Delegation Service that handles all the delegations for users. It is trusted to ensure that | ||
| − | + | * a delegator cannot delegate an attribute he has not already been assigned | |
| − | + | * a delegator cannot delegate once the delegation depth has been consumed | |
| − | + | * a delegator cannot delegate outside the validity period of his own delegation. | |
| − | |||
| − | |||
| − | + | In other words, a delegator can only delegate less than (or equal to) what he already has, and not more than it. | |
Right now, a user delegates in a short term fashion using tokens. Once a token has been granted to a user, he hands that off to another (service) user in order to prove his identity and authorization to perform some set of actions. In addition, since tokens are not scoped to a specific endpoint, they are currently passed on from one endpoint to another. This is not a secure approach. If any endpoint along the way is compromised, all the tokens in that endpoint are usable against any other service that accepts tokens. | Right now, a user delegates in a short term fashion using tokens. Once a token has been granted to a user, he hands that off to another (service) user in order to prove his identity and authorization to perform some set of actions. In addition, since tokens are not scoped to a specific endpoint, they are currently passed on from one endpoint to another. This is not a secure approach. If any endpoint along the way is compromised, all the tokens in that endpoint are usable against any other service that accepts tokens. | ||
| Line 18: | Line 24: | ||
A trust is a promise to allow delegation at some point in the future. The actual delegation is performed in the token. The trust is used to get the token. | A trust is a promise to allow delegation at some point in the future. The actual delegation is performed in the token. The trust is used to get the token. | ||
| − | + | == APIs == | |
| + | To support this, add two new APIs. One is POST trust, and the other is GET trusts/{trust_id} | ||
| + | |||
| + | When POSTing to trusts, the trustor supplies | ||
| + | |||
| + | When GETting tokens/trusts/{user_id} only the specified user will be able to fetch a token for the user that performed the trusted action. | ||
| + | |||
| + | We could potentially add an additional PATCH to modify a pre-auth arraingement. We would certainly want a DELETE. | ||
| + | |||
| + | The preauthentication id should be just a UUID. It should be useless to anyone but the user that creates it. No other user should be able to view it. The user should be able to enumerate her preauthentications, in order to view, modify, and delete them. /users/preauthentications | ||
| + | == Implementation == | ||
Implemented in two phases. | Implemented in two phases. | ||
| − | 1. Trusts get implemented today "hard wired" with the attributes that are currently exposed in a token: (trustor) user, tenant, roles, endpoints. | + | 1. Trusts get implemented today "hard wired" with the attributes that are currently exposed in a token: (trustor) user, tenant, roles, endpoints. 2. Tokens that get generated from the trusts will look just like normal tokens. They will have an additional field "trustee". This will allow the current consumers of tokens to continue to use a trust token just like they do now. |
| − | 2. Tokens that get generated from the trusts will look just like normal tokens. They will have an additional field "trustee". This will allow the current consumers of tokens to continue to use a trust token just like they do now. | ||
| − | Phase 2. | + | Phase 2. 1. Modify the token architecture to allow arbitrary sets of attributes. 2. Modify the trust architecture to specify arbitrary sets of attributes to be used in a token. |
| − | 1. Modify the token architecture to allow arbitrary sets of attributes. | ||
| − | 2. Modify the trust architecture to specify arbitrary sets of attributes to be used in a token. | ||
Revision as of 16:00, 3 December 2012
Trusts
<< TableOfContents() >>
Use Cases
- HEAT and failover. It needs to move a virtual machine from one host to another.
- Content production. Something generates a large file and needs to store it in swift.
In both cases, the users authorizes it at setup time to perform this action any time in the future, long after the token is expired.
Discussion
"Keystone is the Delegation Service that handles all the delegations for users. It is trusted to ensure that
- a delegator cannot delegate an attribute he has not already been assigned
- a delegator cannot delegate once the delegation depth has been consumed
- a delegator cannot delegate outside the validity period of his own delegation.
In other words, a delegator can only delegate less than (or equal to) what he already has, and not more than it.
Right now, a user delegates in a short term fashion using tokens. Once a token has been granted to a user, he hands that off to another (service) user in order to prove his identity and authorization to perform some set of actions. In addition, since tokens are not scoped to a specific endpoint, they are currently passed on from one endpoint to another. This is not a secure approach. If any endpoint along the way is compromised, all the tokens in that endpoint are usable against any other service that accepts tokens.
So we limit the scope of tokens to only that single endpoint, and we remove the attack. As a result, we also remove the ability of the remote service user to request additional operations from additional remote services on behalf of the original user. This is a problem that the trusts are designed to serve.
A trust is a promise to allow delegation at some point in the future. The actual delegation is performed in the token. The trust is used to get the token.
APIs
To support this, add two new APIs. One is POST trust, and the other is GET trusts/{trust_id}
When POSTing to trusts, the trustor supplies
When GETting tokens/trusts/{user_id} only the specified user will be able to fetch a token for the user that performed the trusted action.
We could potentially add an additional PATCH to modify a pre-auth arraingement. We would certainly want a DELETE.
The preauthentication id should be just a UUID. It should be useless to anyone but the user that creates it. No other user should be able to view it. The user should be able to enumerate her preauthentications, in order to view, modify, and delete them. /users/preauthentications
Implementation
Implemented in two phases.
1. Trusts get implemented today "hard wired" with the attributes that are currently exposed in a token: (trustor) user, tenant, roles, endpoints. 2. Tokens that get generated from the trusts will look just like normal tokens. They will have an additional field "trustee". This will allow the current consumers of tokens to continue to use a trust token just like they do now.
Phase 2. 1. Modify the token architecture to allow arbitrary sets of attributes. 2. Modify the trust architecture to specify arbitrary sets of attributes to be used in a token.
