Single sign-on and Control Hub

Single sign-on (SSO) is a session or user authentication process that permits a user to provide credentials to access one or more applications. The process authenticates users for all the applications that they are given rights to. It eliminates further prompts when users switch applications during a particular session.

The Security Assertion Markup Language (SAML 2.0) Federation Protocol is used to provide SSO authentication between the Webex cloud and your identity provider (IdP).


Webex App only supports the web browser SSO profile. In the web browser SSO profile, Webex App supports the following bindings:

  • SP initiated POST -> POST binding

  • SP initiated REDIRECT -> POST binding

NameID format

The SAML 2.0 Protocol supports several NameID formats for communicating about a specific user. Webex App supports the following NameID formats.

  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

In the metadata that you load from your IdP, the first entry is configured for use in Webex.


Webex App supports the single logout profile. In Webex App, a user can sign out of the application, which uses the SAML single logout protocol to end the session and confirm that sign out with your IdP. Ensure your IdP is configured for SingleLogout.

Integrate Control Hub with PingFederate


The configuration guides show a specific example for SSO integration but do not provide exhaustive configuration for all possibilities. For example, the integration steps for nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient are documented. Other formats such as urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress will work for SSO integration but are outside the scope of our documentation.

Set up this integration for users in your Webex organization (including Webex App, Webex Meetings, and other services administered in Control Hub). If your Webex site is integrated in Control Hub, the Webex site inherits the user management. If you can't access Webex Meetings in this way and it is not managed in Control Hub, you must do a separate integration to enable SSO for Webex Meetings. (See Configure Single Sign-On for Webex for more information in SSO integration in Site Administration.)

Before you begin

For SSO and Control Hub, IdPs must conform to the SAML 2.0 specification. In addition, IdPs must be configured in the following manner:

Download the Webex metadata to your local system


From the customer view in, go to Management > Organization Settings, and then scroll to Authentication, and then toggle on the Single sign-on setting to start the setup wizard.


Choose the certificate type for your organization:

  • Self-signed by Cisco—We recommend this choice. Let us sign the certificate so you only need to renew it once every five years.
  • Signed by a public certificate authority—More secure but you'll need to frequently update the metadata (unless your IdP vendor supports trust anchors).


Trust anchors are public keys that act as an authority to verify a digital signature's certificate. For more information, refer to your IdP documentation.


Download the metadata file.

The Webex metadata filename is idb-meta-<org-ID>-SP.xml.

Configure a new service provider connection


Go to your PingFederate Administration portal (https://<FQDN of PingFederate>:9999/pingfederate/app).


Under SP CONNECTIONS, select Create New.


Select the Do not use a template for this connection radio button, then select Next.


Select Browser SSO Profiles, then click Next.


Select the Import Metadata tab.


Click Choose File to browse to and import the metadata file that you downloaded from Control Hub, and then click Next.


Review the information in the General Info tab, and then click Done.

Configure browser single-sign on


From the PingFederate Administration portal, select Configure Browser SSO.


Check the SP-Initiated SSO check box, then click Next.


Select Configure Assertion Creation.

  1. Change the NameID-format to Transient and check the Include attributes in addition to the transient identifier check box.

  2. Extend the contract attributes by adding mail and uid attributes in the format urn:oasis:names:tc:SAML:2.0:attrname-format-basic, then click Next.

  3. Select Map New Adapter Instance to pick an authentication mechanism. From the ADAPTER INSTANCE drop-down, select one of the previously configured authentication mechanisms, then click Next.

  4. Select the Retrieve additional attributes from multiple data stores using one mapping radio button, then click Next.

  5. Select Add Attribute Source to add the Active Directory Domain Controller for the domain, and then click Next.

  6. Specify the Base DN and select the root object class <Show All Attributes>. In the Filter text box, enter the LDAP filter, and then click Next.

    The entry must contain the attribute that you expect the user to provide. It also needs to contain the value that it maps to in the LDAP sources. For example, if your active directory is set to filter on the Windows login attribute, enter sAMAccountName=${Username}.

  7. Select the source and value to map the assertion attributes with the attributes provided by the AD datastore. (Don't enter anything for Issuance Criteria.)

  8. Verify that the Assertion Configuration has Identity Mapping set to Transient, Attribute Contract set to uid, and Adapter Instances set to 1.


    The uid attribute should map to the email address of the user.


Select Configure Protocol Settings.

  1. For Allowable SAML Bindings, check only the POST and Redirect checkboxes.

  2. For Signature Policy, select Always sign the SAML Assertion.

    The protocol settings should look like the following.

  3. Select Configure Credentials to configure the certificate for the assertion.

  4. Select the certificate that was already created for SAML assertions.


On the Activation and Summary screen, set the Connection Status to Active.

Export metadata from PingFederate


On the Main screen, click Manage All SP.


Find the connection that you just created and click Export Metadata.


Choose the certificate to use for signing the exported file from the drop-down.


Click Export.

Import the IdP metadata and enable single sign-on after a test

After you export the Webex metadata, configure your IdP, and download the IdP metadata to your local system, you are ready to import it into your Webex organization from Control Hub.

Before you begin

Do not test SSO integration from the identity provider (IdP) interface. We only support Service Provider-initiated (SP-initiated) flows, so you must use the Control Hub SSO test for this integration.


Choose one:

  • Return to the Control Hub – certificate selection page in your browser, and then click Next.
  • If Control Hub is no longer open in the browser tab, from the customer view in, go to Management > Organization Settings, scroll to Authentication, and then choose Actions > Import Metadata.

On the Import IdP Metadata page, either drag and drop the IdP metadata file onto the page or use the file browser option to locate and upload the metadata file. Click Next.

You should use the More secure option, if you can. This is only possible if your IdP used a public CA to sign its metadata.

In all other cases, you must use the Less secure option. This includes if the metadata is not signed, self-signed, or signed by a private CA.


Okta does not sign the metadata, so you must choose Less secure for an Okta SSO integration.


Select Test SSO setup, and when a new browser tab opens, authenticate with the IdP by signing in.


If you receive an authentication error there may be a problem with the credentials. Check the username and password and try again.

A Webex App error usually means an issue with the SSO setup. In this case, walk through the steps again, especially the steps where you copy and paste the Control Hub metadata into the IdP setup.


To see the SSO sign-in experience directly, you can also click Copy URL to clipboard from this screen and paste it in a private browser window. From there, you can walk through signing in with SSO. This step stops false positives because of an access token that might be in an existing session from you being signed in.


Return to the Control Hub browser tab.

  • If the test was successful, select Successful test. Turn on SSO and click Next.
  • If the test was unsuccessful, select Unsuccessful test. Turn off SSO and click Next.


The SSO configuration does not take effect in your organization unless you choose first radio button and activate SSO.

What to do next

Use the procedures in Synchronize Okta Users into Cisco Webex Control Hub if you want to do user provisioning out of Okta into the Webex cloud.

Use the procedures in Synchronize Azure Active Directory Users into Cisco Webex Control Hub if you want to do user provisioning out of Azure AD into the Webex cloud.

You can follow the procedure in Suppress Automated Emails to disable emails that are sent to new Webex App users in your organization. The document also contains best practices for sending out communications to users in your organization.