Multi-tenancy Support

In CSA, an organization is an entity such as a Company, Business Unit, Department, or Group that is defined by the CSA Administrator. The Administrator also determines a member's entry point into the cloud and associates each member with services and resources. The membership in an organization is determined by the Organization's Identity Management configuration. CSA accesses the Identity configuration to authenticate the user's login credentials with OpenLDAP or Microsoft Active Directory.

CSA identity management (IdM), apart from the primary authentication with OpenLDAP or Microsoft Active Directory also supports the configuration of secondary authentication with OpenStack Identity (keystone) service to enable an integration account or transport user to perform OpenStack actions on behalf of another user. On successful secondary authentication against keystone, a Keystone Trust ID is generated using the authenticated user as the Trustor and the configured integration account as the Trustee.

In OpenStack, a project is a logical grouping of users, and is used to define quotas and access to virtual machine images.

In OpenStack, an administrator implements multi-tenancy by manually mapping CSA organizations to OpenStack projects. This mapping is established through the use of a directory service: OpenLDAP or Microsoft Active Directory.

The following table lists the example for supported mapping:

CSA	OpenStack
CSA Organization (Marketing) mkt_user1 mkt_user2	Project (MARKETING) mkt_user1 mkt_user2
CSA Organization (Engineering) engg_user1 engg_user2	Project (ENGINEERING) engg_user1 engg_user2

Mapping organizations to project and identity management through secondary authentication using keystone ensures that all subscription requests from an Organization's user are accomplished for the users and the corresponding project.

CSA organization user can then use the Marketplace Portal to check out an offering and create a subscription in CSA market place portal. CSA logs in to OpenStack using the relevant project user credentials and orchestrates the provisioning of instances.

OpenStack-Multi-Tenant Support v4.0

This design supports multi-tenancy in the form of subscriber option: Enable User Impersonation Mode and Tenant Name.

If the User Impersonation Mode is set to false, the tenant is fetched from Provider (Tenant/ Project is entered in Provider). If the User Impersonation is set to true, the list of OpenStack tenants that the user has access to is displayed. The provider service access point must be configured with Keystone API v3 endpoint.

CSA administrator must update this option with appropriate value while creating service offering and make it invisible to consumers.

Implement Multi-tenancy

Follow the steps to implement multi-tenancy:

1. Enable Keystone authentication in IdM:

   Set idm.keystone.enabled = true in the file C:\Program Files\Hewlett-Packard\CSA\jboss-as\standalone\deployments\idm-service.war\WEB-INF\spring\applicationContext.properties.

2. Create an OpenStack Resource Provider in CSA Management console:

   Provide the Service Access Point for Keystone service and the IdM Keystone Integration account credentials.

   Specify the following properties for the OpenStack provider:

   • Enter the project in OpenStack while provisioning sequence designs in which enableUserContext is set to False for every OpenStack component in the design. If for all OpenStack designs, enableUserContext is set to True, then the project is left empty and the subscriber must select the project at provisioning time from the set of projects to which the subscriber is authorized.
   • Domain - Enter the domain in OpenStack. This domain must be configured for authentication in the same manner as the consumer organizations for which this provider is used.
   • Transport Token - If checked a domain-scoped transport token is used for communication with OpenStack. If unchecked, a project-scoped transport token is used. The provider user must have administrative rights on the domain in order to use domain-scoped transport tokens.
3. Setup organization in CSA with a directory service endpoint: OpenLDAP or Microsoft Active Directory that is also configured in the OpenStack Keystone instance.

Map LDAP of the CSA organization to LDAP of OpenStack Keystone instance and identity management secondary authentication with Keystone. Ensure that all subscription requests from organization users are fulfilled in the context of user and the selected project.

The sequence of operations performed in multi-tenancy is shown in the following figure:

In general, this feature works as follows:

1. After a successful authentication against one of the primary mechanisms (LDAP, Active Directory), IdM attempts to authenticate against a secondary mechanism (Keystone) using the same credentials.
2. After successful authentication against Keystone, it generates Keystone trust IDs using the authenticated user as the Trustor and the configured integration account (provider user) as the Trustee, for all the OpenStack project that the user has access to.
3. Choose one of the project and associated Keystone trust ID and use it to generate a Keystone impersonation token so that configured provider account can perform OpenStack actions on behalf of the Trustor.

Verify Secondary Authentication

Follow the steps after IdM secondary authentication:

1. Either setup the organization’s LDAP server as the LDAP back-end for CSA or replicate all the organization’s users in Keystone (same username / password).

   All Keystone users must belong to a project whose name exactly matches the CSA organization name used to log in. These names are case-sensitive, that is, a Keystone project name 'project_name' will not match a CSA organization ID 'PROJECT_NAME'.

   To find the actual name:

   1. Log on to CSA admin console and click Organizations.

   2. Go to the respective organization, and click General Information. The Organization URL is displayed.

      The last word in the URL after /org/ is the organization name which must exactly match the project name in OpenStack.

2. Log on to CSA Organization consumer portal (example: ENGINEERING/engg_user1) and verify the IdM logs at <CSA install path>\<Jboss…>\standalone\log\hpcloud-idm-service.log

For example:

2014-11-13 16:02:29,731 [http-/0.0.0.0:8444-7] INFO com.hp.ccue.identity.authn.MultiTenantAuthenticationProvider - Authentication succeeded for user engg_user1

2014-11-13 16:02:30,786 [AsyncAppender-Dispatcher-Thread-80] INFO com.hp.ccue.identity.audit.CSAAuditor - Audited event: {1415923350685:AUTHENTICATION:LOGIN:IDM:engg_user1:ENGINEERING:CSA42-OO1020:null:Authentication success}