Keystone/DistributedSigning

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.

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.

The following changes are required for this blueprint.

1. Each user will have zero or more Signing Certificates associated with them. The Keystone user will use this certificate to sign tokens.
2. Each signed token will have a unique identifier for the user who's certificate was used to sign it.
3. auth_token middleware will be able to serve up multiple CA certs for any certificates that were not signed by keystone, but that are considered acceptable for generating signing certificates.
4. Only users that have the *token_signing* role for their domain will be authorized to sign tokens. Users will only be allowed to sign for their own domain. The exception will be the Keystone user which will be allowed to sign for multiple domains.

Comment from David Chadwick

The issue I want to address is the following "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." My first comment is that this appears to be the wrong way around. User A would normally have a token issued by Keystone A. So it is Keystone B that needs to be able to accept tokens from Keystone A. In order for this to be enabled, there has to be a clear mechanism for Keystone B to be configured that it trusts the tokens of Keystone A (and only Keystone A). This trust shoud not need to be transitive or commutative i.e. If keystone A trusts Keystone C, then Keystone B need not trust Keystone C; similarly Keystone A need not trust the tokens from Keystone B. From the list of changes that Adam has suggested, I get no indication of how this trust can be managed in a controlled way. Adam can you update the blueprint to say how you propose this trust is managed. (FYI, the way we have addressed this issue of trust in our Federation work, is that we configure the Service Catalog of Keystone B to add Keystone A as an Identity Provider ie. Keystone A will issue the tokens to users, and not itself. We also configure Keystone A to say that Keystone B is another of its services that is able to consume its tokens, just like Swift, Glance etc.