Jump to: navigation, search

Keystone Virtual Identity Providers

Revision as of 21:09, 6 August 2013 by Jsavak (talk | contribs) (2. Private/Public cloud identity federation)

As OpenStack gains enterprise traction, the need to allow non-local identities to log-in to Horizon or execute APIs becomes more relevant. Consider the following use-cases:

1. Enterprise identity federation

Acme doesn't use cloud (boo) but does have their own Active Directory implementation. They would like certain employees to have single-sign-on access between an internal IT management portal and the public cloud management portal. They'd also like to control employee access within their Active Directory implementation so that should the employee be terminated, they don't have to go to the public cloud vendor to revoke access.

2. Private/Public cloud identity federation

Acme has their own cloud setup running Keystone against their back-end Active Directory. They would like to automatically burst VM provisioning and/or utilization to a public cloud service provider according to capacity and usage rules. They would like to enable identity federation so there is only one credential set needed between the 2 clouds.

3. Partner Identity federation

Acme would like to tweak Horizon to enable SSO with a vendor that tracks and monitors widgets for them. Any user setup in Keystone should only need that login to access the vendor portal.


Virtual Identity Providers.png

Potentially relevant specs: