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 want to set up SSO for multiple identity providers in your organization, refer to SSO with multiple IdPs in Webex.

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.

 
We recommend that you include Single Log Out (SLO) to your metadata configuration while setting up Webex SAML federation. This step is crucial to ensure that user tokens are invalidated at both, the Identity Provider (IdP) and the Service Provider (SP). If this configuration is not performed by an administrator, then Webex alerts users to close their browsers to invalidate any sessions left open.

Requirements for Identity Providers

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 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.

Establish a SAML Agreement

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.

Configure Webex Identity Service

1

From the customer view in Control Hub ( https://admin.webex.com), go to Management > Organization Settings, scroll to Authentication and click Activate SSO setting to start the configuration wizard.

2

Select Webex as your IdP and click Next.

3

Check I've read and understood how Webex IdP works and click Next.

4

Set up a routing rule.

Once you've added a routing rule, your IdP is added and is shown under the Identity provider tab.
For more information, refer to SSO with multiple IdPs in Webex.

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.

Requirements for Troubleshooting SSO

  • Use the SAML tracer add-on for Firefox, Chrome, or Edge.

  • 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.

Troubleshoot the SAML Flow Between Webex App, Your IdP, and Webex Services

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.

Troubleshoot SSO errors

This section explains how to troubleshoot some common SSO errors you may encounter when using SAML.

We recommend using SAML tracer to help debug issues related to SAML authentication and authorization. Use the SAML tracer add-on for Firefox, Chrome, or Edge.

Error: Your account is not authorized. Please contact your administrator.

This error occurs when the SAML assertion time validation fails. The SAML assertion contains a condition that specifies the NotBefore and NotAfter attributes. The assertion validation time needs to be between these attributes. For example, if we allow a 30-second time skew, then the assertion time (broker system time) should be NotBefore - 30 seconds and NotAfter + 30 seconds. In this case, we recommend that you check if the system is Network Time Protocol (NTP) synced.

For ADFS, set the following attribute:

-ADFSRelyingPartyTrust
-TargetIdentifier " https://idbroker.webex.com/$ENTITY_ID_HEX_VALUE"; 
-NotBeforeSkew 3"

Error: Please use the same email. The email used to authenticate was different than the email provided by the identity provider.

When we receive a SAML assertion from the customer, the status code of the SAML assertion should be urn:oasis:names:tc:SAML:2.0:status:Success. An error occurs if any other status code is received. This means that your IdP has rejected or denied SSO.

Our logs don’t provide enough information to determine the cause of the issue. Therefore, we require assistance from your IdP team to review the logs.

Error: Could not invalidate browser session of the identity provider. The SLO URL may not be configured. Please contact your administrator.

This error occurs if we’re unable to verify the signature of the SAML assertion or the URL for the SLO isn’t available. There are many scenarios that can cause this issue, such as the IdP using a new signing certificate and the customer not updating their metadata in Control Hub.

Error: Invalid digital signature.

This error occurs if we’re unable to locate the signing certificate necessary to validate the signature of the SAML assertion. This could happen under the following circumstances:

  • If the IdP's metadata, imported into the Control Hub, doesn’t include a signing certificate.
  • The error occurs if your IdP SAML metadata doesn’t comply with SAML 2.0 standards. We recommend that you check the sequence of the attributes. The KeyDescriptor should be the first element listed under IdPSSODescriptor.

Error: Missing assertion in response.

When importing metadata in Control Hub, you have two options to choose from:

  • The first option is the 'Requires Signature Verification' which is more secure. By selecting this option, Control Hub verifies the signature of the metadata during the import process.
  • The second option is the 'Less Secure Option' where Control Hub skips validating the signature of the metadata.
But, we’ve observed that sometimes you choose the more secure option when the metadata isn’t signed. Although the metadata may contain a signing certificate, if not signed, selecting the more secure option doesn’t provide any additional security.

Error: Failed to decrypt SAML assertion.

Since November 2017, we have been supporting SHA-256 for SAML metadata. But, any organization created before this date continues to use SHA-1 unless it's explicitly reconfigured.

Now, this reconfiguration can be manually run by updating the extended metadata for the organization. Here's how you can do it:

  1. Go to the Distinguished Name (DN), and make sure to replace 'Org ID' with your actual organization ID.
  2. Open the SunKeyValue that begins with sun-fm-aml2-entityconfig.
  3. Append the XML in the entity config.

Error: This service provider isn’t the intended audience.

In the SAML response, we check for the AudienceRestriction element and ensure that the audience is set to the Cisco Entity ID. If it's not set to the Cisco Entity ID, the SAML response is rejected and SSO fails.

</Subject>
        <Conditions NotBefore="2020-05-22T12:35:39.629Z"
                    NotOnOrAfter="2020-05-22T13:40:39.629Z"
                    >
          <AudienceRestriction>
            <Audience>https://idbroker.webex.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</Audience>
          </AudienceRestriction>
        </Conditions>