Federating with Identity Providers

Many companies use an identity provider to manage user logins and passwords and to authenticate users for access to secure websites, services, and resources. To access the Private Cloud Appliance Compute Web UI, people must also sign in with a user name and password. An administrator can federate with a supported identity provider so that each user can use an existing login and password, rather than having to create new credentials to access and use cloud resources.

Federation involves setting up a trust relationship between the identity provider and Private Cloud Appliance. When the administrator has established that relationship, any user who goes to the Compute Web UI is prompted with a single sign-on experience offered by the identity provider.

Supported Identity Providers

For identity federation, Private Cloud Appliance supports the Security Assertion Markup Language (SAML) 2.0 protocol. However, the only identity provider supported in version 3.0.1 is Microsoft Active Directory, via Active Directory Federation Services.

Your organization can have multiple Active Directory accounts; for example one for each division of the organization. You can federate multiple Active Directory accounts with Private Cloud Appliance, but each federation trust that you set up must be for a single Active Directory account. Identity federation is available in the Compute Web UI as well as the Service Web UI.

Private Cloud Appliance version 3.0.1 does not currently support the System for Cross-domain Identity Management (SCIM), a standard protocol that enables user provisioning across identity systems. Without SCIM, user accounts from an identity provider cannot be automatically provisioned in a tenancy and synchronized. Consequently, the credentials of federated users cannot be managed within the tenancy.

Experience for Federated Users

When browsing to the Compute Web UI, the user is prompted to enter the name of the tenancy. Federated users then choose which identity provider to use, and are redirected to the identity provider's sign-in interface for authentication. After entering the user name and password that they already set up, they are authenticated by the identity provider, and redirected back to the Private Cloud Appliance Compute Web UI. From here, they can access the resources in their tenancy, in accordance with the permissions granted to them.

Federated user accounts are created and managed within the identity provider; they are not replicated or synchronized within Private Cloud Appliance. Federated users are granted access based on their membership of identity provider groups that are mapped to Private Cloud Appliance groups in the tenancy. Unlike local users, federated users cannot manage their credentials through the Compute Web UI. They have no User Settings page, cannot change or reset their password, and cannot upload API signing keys to use the API and CLI.

Federation Process Overview

To set up the federation trust between Private Cloud Appliance and an identity provider, you perform certain steps of the procedure on both systems respectively. In general, identity federation consists of these steps:

  1. Configuring groups in the identity provider, so they can be mapped to groups in the Private Cloud Appliance tenancy.

  2. Downloading the SAML metadata document from the identity provider and collecting the names of the groups you intend to map.

  3. Setting up the new identity provider in your Private Cloud Appliance tenancy. You need to upload the identity provider metadata file. Create the group mappings at this stage, or return to add them later.

  4. Downloading the Private Cloud Appliance federation metadata document from the Federation page in your tenancy.

  5. Setting up Private Cloud Appliance as a trusted application or trusted relying party in your identity provider. You need to upload the Private Cloud Appliance federation metadata document, or provide the URL to it.

    The identity provider SAML authentication response must be configured to include name ID and groups, which are parameters required by Private Cloud Appliance.

  6. Setting up IAM policies for the mapped groups.

  7. Providing federated users the name of the tenancy and the URL to the Private Cloud Appliance Compute Web UI.