If you have your own identity provider (IdP) in your organization, you can integrate the SAML IdP with your organization in Control Hub for single sign-on (SSO). SSO lets your users use a single, common set of credentials for Webex App applications and other applications in your organization.
The following web access management and federation solutions were tested for Webex organizations. The documents linked below walk you through how to integrate that specific identity provider (IdP) with your Webex organization.
These guides cover SSO integration for Webex services that are managed in Control Hub ( https://admin.webex.com). If you're looking for SSO integration of a Webex Meetings site (managed in Site Administration), read Configure Single Sign-On for Cisco Webex Site. |
If you don't see your IdP listed below, follow the high-level steps in the SSO Setup tab in this article.
Single sign-on (SSO) enables users to sign in to Webex securely by authenticating to your organizations common identity provider (IdP). The Webex App uses the Webex service to communicate with the Webex Platform Identity Service. The identity service authenticates with your identity provider (IdP).
You start configuration in Control Hub. This section captures high-level, generic steps for integrating a third-party IdP.
When you configure SSO with your IdP, you can map any attribute to the uid. For example, map the userPrincipalName, an email alias, an alternative email address or any other suitable attribute to the uid. The IdP needs to match one of the user’s email addresses to the uid when signing in. Webex supports mapping up to 5 email addresses to the uid. |
For SSO and Control Hub, IdPs must conform to the SAML 2.0 specification. In addition, IdPs must be configured in the following manner:
-
Set the NameID Format attribute to urn:oasis:names:tc:SAML:2.0:nameid-format:transient
-
Configure a claim on the IdP according to the type of SSO that you are deploying:
-
SSO (for an organization)—If you are configuring SSO on behalf of an organization, configure the IdP claim to include the uid attribute name with a value that is mapped to the attribute that is chosen in the Directory Connector, or the user attribute that matches the one that is chosen in the Webex identity service. (This attribute could be E-mail-Addresses or User-Principal-Name, for example.)
-
Partner SSO (for Service Providers only)—If you are a Service Provider administrator who is configuring Partner SSO to be used by the customer organizations that the Service Provider manages, configure the IdP claim to include the mail attribute (rather than uid). The value must map to the attribute that is chosen in the Directory Connector, or the user attribute that matches the one that is chosen in the Webex identity service.
For more information on mapping custom attributes for either SSO or Partner SSO, see https://www.cisco.com/go/hybrid-services-directory.
-
-
Partner SSO only. The Identity Provider must support multiple Assertion Consumer Service (ACS) URLs. For examples of how to configure multiple ACS URLs on an Identity Provider, see:
-
Use a supported browser: we recommend the latest version of Mozilla Firefox or Google Chrome.
-
Disable any popup blockers in your browser.
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 |
You must establish a SAML agreement between the Webex Platform Identity Service and your IdP.
You need two files to achieve a successful SAML agreement:
-
A metadata file from the IdP, to give to Webex.
-
A metadata file from Webex, to give to the IdP.
This is an example of a PingFederate metadata file with metadata from the IdP.
Metadata file from the identity service.
The following is what you expect to see in the metadata file from the identity service.
-
EntityID—This is used to identify the SAML agreement in the IdP configuration
-
There is no requirement for a signed AuthN request or any sign assertions, it complies with what the IdP requests in the metadata file.
-
A signed metadata file for the IdP to verify that the metadata belongs to the identity service.
1 | From the customer view in Control Hub ( https://admin.webex.com), go to , scroll to Authentication and toggle on the Single Sign-On setting to start the configuration wizard. | ||
2 | Choose the certificate type:
| ||
3 | Click Download metadata and click Next. | ||
4 | Webex Platform Identity service validates the metadata file from the IdP. There are two possible ways to validate the metadata from the Customer IdP:
| ||
5 | Test the SSO Connection before you enable it. This step works like a dry run and doesn't affect your organization settings until you enable SSO in the next step.
| ||
6 | If the test succeeds, then turn SSO and save the changes. You must save changes for SSO to take effect in your organization. |
Whether you received a notice about an expiring certificate or want to check on your existing SSO configuration, you can use the Single Sign-On (SSO) management features in Control Hub for certificate management and general SSO maintenance activities.
If you run into problems with your SSO integration, use the requirements and procedure in this section to troubleshoot the SAML Flow between your IdP and Webex.
-
To troubleshoot, use the web browser where you installed the SAML trace debug tool and go to the web version of Webex at https://web.webex.com.
The following is the flow of messages between the Webex App, Webex Services, Webex Platform Identity Service, and the Identity provider (IdP).

1 | Go to https://admin.webex.com and, with SSO enabled, the app prompts for an email address.
![]() The app sends the information to the Webex service which verifies the email address. |
2 | The app sends a GET request to the OAuth authorization server for a token. The request is redirected to the identity service to the SSO or username and password flow. The URL for the authentication server is returned. ![]() You can see the GET request in the trace file. In the parameters section the service looks for an OAuth code, email of the user who sent the request, and other OAuth details such as ClientID, redirectURI and Scope. |
3 | The Webex App requests a SAML assertion from the IdP using a SAML HTTP POST. When SSO is enabled, the authentication engine in the identity service redirects to the IdP URL for SSO. The IdP URL provided when the metadata was exchanged. Check in the trace tool for a SAML POST message. You see an HTTP POST message to the IdP requested by the IdPbroker. The RelayState parameter shows the correct reply from the IdP. Review the decode version of the SAML request, there is no mandate AuthN and the destination of the answer should go to the destination URL of the IdP. Ensure that the nameid-format is correctly configured in the IdP under the correct entityID (SPNameQualifier) The IdP nameid-format is specified and the name of the agreement configured when the SAML agreement was created. |
4 | The authentication for the app happens between the operating system web resources and the IdP. Depending on your IdP and the authentication mechanisms configured in the IdP, different flows are started from the IdP. |
5 | The app sends an HTTP Post back to the identity service and includes the attributes provided by the IdP and agreed in the initial agreement. When authentication is successful, the app sends the information in a SAML POST message to the identity service. The RelayState is the same as the previous HTTP POST message where the app tells the IdP which EntityID is requesting the assertion. |
6 | SAML Assertion from IdP to Webex. |
7 | The identity service receives an authorization code that is replaced with an OAuth access and refresh token. This token is used to access resources on behalf of the user. After the identity service validates the answer from the IdP, they issue an OAuth token that allows the Webex App to access the different Webex services. |