Distributed signing of Keystone Tokens

Registered by Adam Young on 2012-07-20

This blueprint has been superseded. See the newer blueprint "Multiple Keystone Signing Certificates" for updated plans.

Allow separate organizations to control their own sets of users and projects while continuing to provide security at the same level as Keystone currently does. Using PKI as the mechanism and Domains as the dividing point.

Changing the name to more clearly specify the scope of this blueprint. I'll update the Wiki as well.

Blueprint information

Status:
Complete
Approver:
Joseph Heck
Priority:
Undefined
Drafter:
Adam Young
Direction:
Approved
Assignee:
Adam Young
Definition:
Superseded
Series goal:
None
Implementation:
Not started
Milestone target:
None
Completed by
Morgan Fainberg on 2014-10-17

Related branches

Sprints

Whiteboard

https://etherpad.openstack.org/keystone-pki-future

I would like to alter the brief by removing the last sentence. The protocol and authentication mechanism that is used for federated access should be determined by the cloud service provider. Keystone should be able to support OpenID, SAML, Kerberos, PKI etc and be infinitely extensible
David Chadwick

I'm going to change this from Federation to Keystone Delegation, as I think we want to distinguish the two concepts. Keystone can and should support both.

(?)

Work Items