Difference between revisions of "Keystone Virtual Identity Providers"
(Created page with "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...") |
|||
| Line 5: | Line 5: | ||
2. Private/Public cloud identity federation - | 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. | + | 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. |
| − | They would like to enable identity federation so there is only one credential set needed between the 2 clouds. | ||
3. Partner Identity federation | 3. Partner Identity federation | ||
| Line 12: | Line 11: | ||
| − | Potentially relevant | + | [[File:Virtual Identity Providers.png|framed]] |
| + | |||
| + | Potentially relevant specs: | ||
| + | * https://blueprints.launchpad.net/keystone/+spec/saml-id | ||
| + | * https://blueprints.launchpad.net/keystone/+spec/distributed-signing | ||
| + | * https://blueprints.launchpad.net/keystone/+spec/federation | ||
Revision as of 19:42, 6 August 2013
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.
Potentially relevant specs:
