Difference between revisions of "Keystone Virtual Identity Providers"
| Line 1: | Line 1: | ||
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: | 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 | + | === 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 | + | === 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. | 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 | + | === 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. | |
[[File:Virtual Identity Providers.png|framed]] | [[File:Virtual Identity Providers.png|framed]] | ||
| − | Potentially relevant specs: | + | === Potentially relevant specs: === |
* https://blueprints.launchpad.net/keystone/+spec/saml-id | * https://blueprints.launchpad.net/keystone/+spec/saml-id | ||
* https://blueprints.launchpad.net/keystone/+spec/distributed-signing | * https://blueprints.launchpad.net/keystone/+spec/distributed-signing | ||
* https://blueprints.launchpad.net/keystone/+spec/federation | * https://blueprints.launchpad.net/keystone/+spec/federation | ||
Revision as of 21:09, 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:
Contents
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.
