Topics on this page
About SAML single sign-on
This page applies to new accounts created on or after August 4, 2021, and to accounts upgraded to the new sign in system.
Cloud One supports single sign-on (SSO) using an open authentication standard called Security Assertion Markup Language 2.0 (SAML). SSO enables users to authenticate to their applications using a single set of credentials, and organizations to more easily control employee access to applications using the organization's identity provider.
Cloud One SAML only supports Identity Provider-initiated SSO and customers will have to login via their Identity Providers in order to access Cloud One.
Previously, it was possible to configure SAML single sign-on directly to Cloud One Workload Security. It is now possible to log into all of Cloud One using SAML. However, this new single sign-on to all of Cloud One must be configured separately.
Cloud One continues to support a native sign-on using its usual web interface and Cloud One credentials, which is separate from its SAML SSO.
To implement SAML single sign-on, see Configure SAML single sign-on.
How SAML single sign-on works in Cloud One
In SAML single sign-on, you establish a trust relationship between two parties: the identity provider and the service provider.
The identity provider has the user identity information stored on a directory server. The service provider (which in this case is Cloud One) accepts requests from the identity providers to authenticate to the service provider on the user's behalf.
The identity provider and the service provider establish trust by exchanging a SAML metadata document with one another.
Once Cloud One and the identity provider have exchanged SAML metadata documents and established a trust relationship, Cloud One can accept assertions coming from the identity provider and use them to authenticate a user into a Cloud One account. In addition to the metadata document, Cloud One requires instructions for interpreting the data in the assertion in order to know how to authenticate the user. This is done using mappings, roles, and claims.
- Mappings are used to associate attributes in Cloud One with the user attributes in your identity provider
- Claims are pieces of information about the user provided by the identity provider in an assertion
- Roles specify how to map a user's groups in the identity provider with a role in a Cloud One account
Cloud One uses the following mappings:
- Name attribute (optional): Specifies the claim attribute that contains the user's name. This is used for display purposes.
- Locale attribute (optional): Specifies the claim attribute that contains the user's locale. This is used to set the locale setting in Cloud One.
- Timezone attribute (optional): Specifies the claim attribute that contains the user's time zone. This is used to set the timezone setting in Cloud One.
- Role attributes: Specifies the claim attribute that the contains the groups the user is part of. This is used with the roles mapping value to determine which roles inside an account the user has access to.
- Group: This is a list of name value pairs that specifies how to map the groups the user is a part of (which is read from the attribute given in the role mapping) to a role in the Cloud One account. A group can only be assigned to a single Cloud One role inside an account.
The identity provider configuration in Cloud One is tied to a specific Cloud One account. This means any roles specified in the roles mapping must be from the current Cloud One account. To log into multiple accounts with the same identity provider, the configuration information must be added to each Cloud One account separately.
When Cloud One receives an assertion, it uses the mappings to read which groups the user is part of and maps them to Cloud One roles the user can access. It does this mapping across all the Cloud One accounts for which the identity provider is configured, to give the user a list of accounts and roles they can use to sign in to Cloud One.
For users with multiple roles or Cloud One accounts, access to all roles and accounts can be granted through a single assertion from the identity provider. However, each Cloud One account is tied to its own specific identity provider configuration and, to enable access, each account must be configured separately with the identity provider.
Once configured, Cloud One uses the mappings provided in the assertion to list all the roles and accounts with which the user can sign in.
If a role is removed from Cloud One, it will not be reflected in your identity provider configuration. You must navigate to identity providers in Cloud One and take note of the warning tip beside the role that has been removed. Any users who are associated with this mapping will not be able to log in to Cloud One. You must manually update the mapping to a valid role or remove the mapping altogether.
Implement SAML single sign-on in Cloud One
Once trust has been established between Cloud One and an identity provider with a SAML metadata document exchange, users can use SAML single sign-on to sign in to Cloud One through your organization's portal.
For information, see Configure SAML single sign-on.