Jump to: navigation, search

Keystone/Trusts

< Keystone
Revision as of 15:56, 3 December 2012 by Admiyo (talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

<< TableOfContents() >>

"Keystone is the Delegation Service that handles all the delegations for users. It is trusted to ensure that

i) a delegator cannot delegate an attribute he has not already been assigned ii) a delegator cannot delegate once the delegation depth has been consumed iv) 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. "

I think that is a great prelude to the design discussion.

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.

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.