Difference between revisions of "Multi-Realm Keystone"
Line 8: | Line 8: | ||
== The “Realm” == | == The “Realm” == | ||
− | + | A “''realm''”, in the context of [[OpenStack]], consists of a set of services which all rely on a single Keystone data set for authentication. Note that this is not necessarily a single Keystone service: multiple Keystone services could be in use; the defining characteristic is that they all use the same data set, however that set is distributed. As an example, consider a large hosting provider: they may have many compute instances distributed across a number of zones, but all of them would use a common, possibly distributed, Keystone service. | |
---- | ---- | ||
[[Category:Proposal]] | [[Category:Proposal]] |
Revision as of 19:50, 25 January 2012
Multi-realm Keystone
Introduction
Currently, in order to make use of a given OpenStack service—when Keystone is in use—, a token issued by Keystone must be presented in the request. This falls short of the federation goal, where a customer running an OpenStack instance could issue a request to a contracted service provider also running OpenStack, using their existing authentication tokens. In this proposal, I put forward a mechanism by which this federation can be accomplished, along with a terminology that can help simplify future discussions.
The “Realm”
A “realm”, in the context of OpenStack, consists of a set of services which all rely on a single Keystone data set for authentication. Note that this is not necessarily a single Keystone service: multiple Keystone services could be in use; the defining characteristic is that they all use the same data set, however that set is distributed. As an example, consider a large hosting provider: they may have many compute instances distributed across a number of zones, but all of them would use a common, possibly distributed, Keystone service.