Grounded in the Cloud
cancel
Showing results for 
Search instead for 
Did you mean: 

Create a common identity authentication system supporting multiple, independent HPE Helion OpenStack

Stephen_Spector

Guest Author: Tim Cuddy, Sr Product Management, HPE Helion

Our Helion OpenStack customer conversations are increasingly expanding from how to get a single Helion OpenStack cloud up and running to the question of how to deploy, integrate and support multiple, independent Helion OpenStack clouds.  There are a variety of potential use cases and requirements driving these conversations including supporting independent, geographically dispersed organization departments and business units, storage and application redundancy, and support for inter-cloud disaster recovery.  

A starting point for multi-cloud integration is to establish a common identity authentication configuration.  Typically user information is already stored in a central system like Microsoft Active Directory.  As new employees join or leave an organization their user information is updated in the central system.  This system is in turn is used by multiple applications and systems as a single source of truth to establish authentication access. 

The OpenStack Keystone service provides authentication and authorization functions for Helion OpenStack and can be configured to integrate with external identity management systems.  When a user logs in to Helion OpenStack their credentials are forwarded to the configured authentication system that provides or denies authentication credentials back to Keystone.  Keystone in turn creates an access token for the authenticated user.  The access token contains all the relevant information for the given user and is used by all Helion OpenStack services to provide resource access. 

Currently there are a couple different options for integrating multiple Helion OpenStack clouds with a central authentication source.

Basic Authentication Federation

Each independent Helion OpenStack cloud quite probably will have unique domains, projects and user role assignments.   These functions are defined and managed by the local Keystone configured for each independent cloud.  However, each separate Keystone deployment can be configured to integrate with a central system for user authentication.  This ensures that user names, passwords, and user status are all centrally managed outside of Helion OpenStack and removes the requirement to store and synchronize this information within and between each separate Keystone deployment.  Users still need to authenticate separately with each Helion OpenStack cloud but they can use the same enterprise credentials with each cloud.  This design provides a basic level of identity federation.  More information on LDAP integration is available at: http://docs.hpcloud.com/#3.x/helion/operations/configuring/identity/identity_ldap.html.

Inter-cloud Keystone-to-Keystone Federation

Helion OpenStack v3 now supports an advanced form of federation targeted specifically at providing inter-cloud Single Sign On (SSO) authentication.  This function is known as Keystone-to-Keystone federation and is built on top of the basic authentication model.  With this function, users initially login to their “home” Helion OpenStack cloud via the various Keystone authentication options.  When a user wants to access a resource in a different Helion OpenStack cloud they select the API endpoint of the resource on the remote cloud either via API, CLI or the region option in Helion OpenStack.  Tokens are generated for accessing the remote cloud services by an inter-Keystone authentication event that does not require the user to manually authenticate with the external cloud.  This inter-cloud authentication event is enabled by creating a set of relationships between each separate Keystone service that establishes entities known as Identity Providers and Service Providers.  These relationships enable the passing of credentials and the issuing of access tokens between each separate Keystone service thus creating the effect of SSO.  Domains, projects and user role assignment are still created and managed separately on each cloud but mapping files can be created to automatically place external users into a local cloud domain and project and define the role for the remote user.  More information on this option, including current limitations, is available at: http://docs.hpcloud.com/#3.x/helion/operations/configuring/identity/keystone_federation.html.

In summary, independent Helion OpenStack clouds can be integrated via a common identity authentication framework.  But there is still quite a bit of work to be done in future OpenStack releases to enable additional federation authorization functions like roles and quotas and user resource organization functions like domains and projects.  Those functions are currently defined and managed on a per-cloud basis. 

Senior Manager, Cloud Online Marketing
  • HPE Cloud
0 Kudos
About the Author

Stephen_Spector

I manage the HPE Helion social media and website teams promoting the enterprise cloud solutions at HPE for hybrid, public, and private clouds. I was previously at Dell promoting their Cloud solutions and was the open source community manager for OpenStack and Xen.org at Rackspace and Citrix Systems. While at Citrix Systems, I founded the Citrix Developer Network, developed global alliance and licensing programs, and even once added audio to the DOS ICA client with assembler. Follow me at @SpectorID

Events
28-30 November
Madrid, Spain
Discover 2017 Madrid
Join us for Hewlett Packard Enterprise Discover 2017 Madrid, taking place 28-30 November at the Feria de Madrid Convention Center
Read more
See posts for dates
Online
HPE Webinars - 2017
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all