Difference between revisions of "Keystone Virtual Identity Providers"
(→2. Private/Public cloud identity federation) |
(→3. Partner Identity federation) |
||
| Line 9: | Line 9: | ||
=== 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. | 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. | ||
| + | |||
| + | David Chadwick -> Sorry, but I cannot make much sense of this blueprint. What is it trying to say about how how keystone operates with federated IDPs? I think we need a lot more explanatory text with this diagram if we are to be able to understand it properly. Thanks. | ||
Latest revision as of 08:15, 15 December 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.
David Chadwick -> Sorry, but I cannot make much sense of this blueprint. What is it trying to say about how how keystone operates with federated IDPs? I think we need a lot more explanatory text with this diagram if we are to be able to understand it properly. Thanks.
