CloudCenter 4.8 has reached End of Life (EOL) as of November 14, 2018. See End of Support Notices for additional context.

SAML SSO Integration


CloudCenter does not authenticate directly to LDAP or AD.

CloudCenter only interacts with LDAP/AD through a SSO IDentity Provider (IDP) that supports SAML 2.0 protocol (for example, Ping Identity, ADFS, Shibboleth, and so forth).

To implement SSO using CloudCenter:

  1. You must then configure the CCM to re-direct the authentication to the SSO IDP.

  2. You must also map some additional user custom properties (returned by the SAML IDP) to the user activation profile.

  3. Once you complete all these steps successfully, CloudCenter automatically assigns the proper user group membership and additional roles and permissions.

A CCM instance supports Security Assertion Markup Language (SAML) 2.0 SSO through Spring Security SAML Extension.

The SysAdmin can set up SAML integration at the root level or the tenant level. To accurately configure this integration, you must have the following information for the root tenant or sub-tenant (as applicable to your deployment):

  • Tenant configuration information

  • Activation profile information

CloudCenter Support

Cisco CloudCenter supports the following Secure hash algorithms when signing SAML messages:

  • SHA-1

  • SHA-256 (configured as the out-of-box default)

  • SHA-512

Contact CloudCenter Support for additional information.

SAML Authentication Configuration

To configure a tenant to use SSO, follow this procedure:

  1. Create a tenant (see Sub-Tenants)

    1. Short Name – give a string without spaces and special characters.

    2. External Id – enter the ID of the organization in the external system with which the tenant is associated.

    3. Tenant – the CCM server domain name alias for the tenant. This will serve as the end point of the Service Provider (SP) from the SSO perspective.

  2. Login as the newly created tenant admin and create an Activation Profiles.

  3. Click the Tenant Info tab and select the newly created activation profile as Default Activation Profile.

  4. Gather the IDP information to see what Subject Attribute the IDP will provide and create a IDP Subject Attribute to the User Property mapping plan.

  5. Login as SysAdmin (see Admin Users > Login as a System Admin), click the Manage Vendor Admins tab and select the Authentication Settings action item.

  6. Enter the information in the IDP Settings, SP Settings and Attribute Mappings sections and click Update.

    The following screenshot shows the IDP Settings.

    The following screenshot shows the SP Settings.

    The following screenshot shows the Attribute Mappings.

    • IDP Metadata: To establish the mutual trust between the CloudCenter platform and the IDP.

    • Entity ID: The target domain name for this tenant URL. For example:
      This field supports sub-domains or different domains from the CCM domain.

    • Logout URL: If you are logging into your company's SAML page, you must specify the URL of the page that you want the logged in users to be redirected to when they log out of the SAML page.

    • Attribute Mapping Section: These are the fields from the IDP that will be mapped to user attributes within the CloudCenter platform. If you are unsure about these fields, please contact your IDP administrator. At a minimum, you need to provide the first name, last name, email address, and external User ID.

    • User Group: Specify the field name from the IDP that will be used to determine the group to which the user belongs.

    • Activation Profiles Reference: Identify an attribute in your metadata to pick an associated activation profile instead of the default profile.

    • 1st/2nd Level Vendor External ID: Used to automate the placement of the SSO self signup users in the correct tenant.

      • Used in conjunction with setting an External ID when creating a sub-tenant to automate SSO user placement in the right tenants. The following screenshot shows an example.

        • If an organization has a 3-level hierarchy with :

          • The top level organization = the root organization

            • Each user has a unique User ID (UID) regardless of their organization.

          • The 1st-level organization (sub-tenant)= Company1

            • Each Company1 user has an unique external identifier = Company1_uid.

          • The 2nd-level organization (sub-tenant) = Company1_c (each Company can have zero or more departments or customers within)

            • Each department or customer user has a unique external identifier = Company1_c_uid

        • The combination of Company1_uid and Company1_c_uid is used to locate the organization for a user:

          • A user without Company1_uid and Company1_c_uid is placed in the root organization 

          • A user with only Company1_uid  is placed in the:

            • 1st-level sub-tenant

            • External ID matches the user's Company1_uid

          • A user with both a Company1_uid and Company1_c_uid is placed in the:

            • 2nd-level sub-tenant   

            • External ID  

              • 2nd-level sub-tenant matches the user's Company1_c_uid   

              • 1st-level sub-tenant matches the user's Company1_uid

      • The default behavior is that if the value of the field mapped to Vendor IDs is blank then users are placed in the root tenant.

      • You can configure the default mapping and block users by providing a value in the Vendor ID fields, but it doesn't match the value set for the tenant(s)

        If you map values for the 1st and 2nd level vendor and the External IDs that don't match the External IDs of any tenant, then these users are not granted access.

  7. Download the SP Metadata and send it to the IDP administrator to register the SP.

Other References

See the Ping Identity knowledge Base for an example of mapping IDP groups to SP groups.

  • No labels
Terms & Conditions Privacy Statement Cookies Trademarks