4.5 User Account Requirements for Multisite Access
To transfer user sessions between member organizations, the source member site must authenticate the new user session on the destination member site before redirecting the user’s browser session. At the point at which it does so, it only has access to the user identity and organization authentication method from the current session. Currently, to transfer the session to another member site, both the user identity and organization authentication method must match. Similarly, when the user switches to another member site, their roles and rights are determined from those effective at the site to which they have switched. The user identity management types, member configuration requirements, and roles and rights configuration required for effective multisite operation are detailed in the following tables.
vCloud Director can validate user identities from three different sources.
Table 2. vCloud Director User identity Management Types
User Type | Identity Management |
Local users | User name, password and permissible roles are all managed entirely within vCloud Director. |
Local users with LDAP | User names are managed through LDAP (either Provider or Tenant managed) but are imported into vCloud Director. Their passwords are managed in LDAP and their roles are managed by vCloud Director. |
External Identity Provider (for example, SSO/SAML/OAuth) | User names and passwords are managed within the external identity provider (IDP) but roles can either be managed by vCloud Director or by group membership in the IDP (“Defer_to_IDP” in vCloud Director user configuration). The IDP is external to vCloud Director but can be either Provider or Tenant managed. |
To switch between sites, the associated organizations must acquire their user identities in the same way. Because the initial vCloud Director site only has access to the user ID and password it validated during the user’s login, the follow requirements must be met.
Table 3. vCloud Director Multisite Tenant Configuration Requirements
User Type | Tenant Configuration Requirements |
Local users | Associated organizations must all be set to use local users. The same user names and passwords must exist at all sites. The use of Local User account is not recommended because there is currently no mechanism for validating password matching between member organizations and, when password changes are necessary, they must be carried out manually at all sites. |
Local users with LDAP | Member organizations must be set to use the same LDAP servers (or federated/synchronized equivalents). Member organizations must have imported the same set of user names from their LDAP sources. |
External Identity Provider | Member organizations must use the same external IDP servers (or federated/synchronized equivalents). |
Roles and rights are not propagated between associated organizations and are, therefore, determined by the user account at the currently selected member site. The method in which this is controlled varies between user types and is detailed in the following table.
Table 4. vCloud Director Multisite User Roles and Rights Control
User Type | Roles and Rights Configuration |
Local users | Roles and rights constrained by the user account on the current site. |
Local users with LDAP | Roles and rights constrained by the user account on the current site. |
External Identity Provider | Roles and rights set explicitly at each site. | These settings take precedence over other roles and rights settings. |
Defer to IDP with identical group mapping at each site. | Users will have the same rights at all sites. |
Defer to IDP with different group mapping at each site. | Users will have rights dependent upon the specific group mappings at each site. |
Note For predictable operation it is recommended that wherever possible user roles and rights are the same in all member organizations. It is however recognized that if different member organizations contain workloads with different security and access considerations, this might not be possible. Where this is the case, and roles and rights are different, users might be able to switch to a site at which they have either no access, or access with limited (or no) effective rights. While this is expected behavior, it might confuse users.