Difference between revisions of "Keystone/Delegation"

Revision as of 15:02, 21 October 2012

<<TableOfContents()>>

Overview

Keystone currently supports a single Identity management store. This document describes an extension to Keystone that will allow multiple user databases to interoperate in a single cloud environment. With PKI authentication, the remote services no longer need direct access to a Keystone server for the majority of their operations. Instead, Keystone will primarily serve them as place to distribute the signing certificates for tokens. Most Keystone data will come into the systems in the form of a signed document attached to the request. While the first implementation has this information coming from the same Keystone server, there is no reason that is has to in the future. Keystone is changing from calling the grouping mechanism Tenants to Proejcts. For this document, I will refer to them as projects. It will be possible to set up a system where the Keystone server used to sign the token is behind a firewall and is not accessible to the Nova server. The user goes to the keystone server, requests and receives a token whose signature can be verified by a signing certificate. All the Nova instance needs now is to be able to fetch the signing certificate from Keystone. This ability to separate the Keystone servers provides the mechanism to Federate the authentication and authorization mechanisms used in OpenStack. With Domains, we have a natural boundary for responsibility. An OpenStack Deployment that has two domains could have two Keystone servers, one for each domain. So long as users only seek access to resources in their own domain, they can perform all operations through their own Keystone server. This keystone server could potentially be hosted at a different data center than hosts the rest of the OpenStack Deployment. What if a user from Domain A wants access to a resource managed by Domain B? The keystone server for Domain A has to be willing to accept tokens generated from the Keystone server that manages Domain B.

Scenario

Here is an example scenario to demonstrate the process.

• Cumulus, Inc is a Cloud Provider running OpenStack. It will has domains for two towns: Stoughton and Canton. A resident of Stoughton has a username composed of their first initial and last name: ayoung. The usernames used in Keystone are then username@stoughton. A resident of Canton might also have the same username, but it will be qualified with their doman name. So ayoung@canton is a different user from ayoung@stoughton. The Canton domain has a project deployed a Cumulus. We'll call this Project Turing. The administrator of the Canton domain grants the Role *user* to ayoung@stoughton in their Keystone. Here are the sequence of events.

Sequence of Events

In the following scenario, I'll use ayoung to refer to the real person, and ayoung@stoughton as his userid.

• ayoung performs a keystone token-get against the Stoughton Keystone instance, passing in his userId and password. To limit the scope of this token, he requests it for the canton project, a special project set up only for access to Canton resources.
• Stoughton Keystone issues a new token for the Stoughton domain.
• ayoung performs a keystone token-get against the Canton Keystone, passing in the Stoughton token. He requests a token for the Canton Turing Project.
• The Canton Keystone server uses the Stoughton Certificate to validate the Stoughton token.
• The Canton Keystone server issues a new token for ayoung@Stoughton for the project turing@canton. I'll refer to this ticket as ayoung@stoughton/turing@canton.
• ayoung sends a request to a Nova server running at Cumulus to start a virtual machine inside the turing@canton project, passing on the token for ayoung@stoughton/turing@canton.
• The nova server sees that the ticket was issued by the Canton Keystone server, and uses the Canton Signing certificate in order to validate it.
• Nova sends the start command and returns a success code to ayoung.

The mechanism described is very similar to how Kerberos does cross domain trusts. Security Concerns: The python-keystoneclient should enforce that the initial token are for requesting services from another domains Keystone server. If the user requests a general purpose ticket, and then hands that off to the Canton Keystone server, someone with access to that server now could impersonate ayoung@stoughton by reusing his token. TO compare with Kerberos, this would be like handing over at TGT to an untrusted service. It is also essential that an internal Keystone server not allow token re-authentication for signed tokens from the delegated servers. If a user with access to the Canton server then passes in the initial ayoung@stought token to an internal Keystone, the internal Keystone server should deny it. The current way that tokens are implemented are that they are verified against an internal data store. The only exception to this rule should be for explicit trust relationships like the one described above.

Comment by David

Hi Adam

I think you are mixing up two issues

i) access to services from foreign domains (the main thrust of this blueprint), and

ii) copying and using tokens belonging to someone else

The second issue is one that needs addressing for all users of Keystone, and is not restricted to multiple keystones and access from foreign domains. The issue arises because the tokens issued by keystone are "bearer" tokens, and there is nothing in them to link the token to the client that is submitting it. This issue has been dealt with in SAML through the use of the "holder of key" feature, in which the client has a key pair, and its public key is included in the token. The client can then prove that the token is his by signing the message with his private key. In this way the token is protected from copying and replaying by someone else.