SAML SSO Deployment Guide for Cisco Unified Communications Applications, Release 12.5(1)

Americas Headquarters

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA

http://www.cisco.com

Tel: 408 526-4000

800 553-NETS (6387)

Fax: 408 527-0883

Preface

This document provides information on how to enable the Security Assertion Markup Language Single Sign-On (SAML SSO) solution, which allows administrators to access a defined set of Cisco collaboration applications seamlessly after signing into one of those applications. This document describes the various applications that can be used with the SAML-based SSO solution as well as the supported Identity Providers (IdPs) that provide the user authentication for the solution. This document provides links to product documentation for configuration of specific collaboration applications.

Audience

This document is intended for system administrators who are familiar with the SAML-based SSO solution for the various Cisco Unified Communications applications and supported IdPs. This guide also requires knowledge of Network Time Protocol (NTP) and Domain Name System (DNS) server settings.

Organization

Conventions

This document uses the following conventions:

Notes use the following conventions:

• Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the publication.
• Tip Means the information contains useful tips.

Additional Information

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What'sNew in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at: http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What'sNew in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.

Cisco Product Security Overview

This product contains cryptographic features and is subject to United States and local country laws governing import, export, transfer and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute or use encryption. Importers, exporters, distributors and users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately.

Further information regarding U.S. export regulations may be found at http://www.access.gpo.gov/bis/ear/ear_data.html

Chapter 1: SAML-Based SSO Solution

• About SAML SSO Solution, on page 1
• Single Sign on Single Service Provider Agreement, on page 2
• SAML-Based SSO Features, on page 2
• Basic Elements of a SAML SSO Solution, on page 2
• Cisco Unified Communications Applications that Support SAML SSO, on page 3
• SAML SSO Support for Cisco Unified Communications Manager Web Interfaces, on page 4
• Software Requirements, on page 6
• Selecting an Identity Provider (IdP), on page 6
• SAML Components, on page 7
• SAML SSO Call Flow, on page 8
• Java Requirements for SAML SSO Login to RTMT via Okta, on page 9

About SAML SSO Solution

Important When deploying Cisco Jabber with Cisco Webex meeting server, Unified Communications Manager and the Webex meeting server must be in the same domain.

SAML is an XML-based open standard data format that enables administrators to access a defined set of Cisco collaboration applications seamlessly after signing into one of those applications. SAML describes the exchange of security related information between trusted business partners. It is an authentication protocol used by service providers (for example, Unified Communications Manager) to authenticate a user. SAML enables exchange of security authentication information between an Identity Provider (IdP) and a service provider.

SAML SSO uses the SAML 2.0 protocol to offer cross-domain and cross-product single sign-on for Cisco collaboration solutions. SAML 2.0 enables SSO across Cisco applications and enables federation between Cisco applications and an IdP. SAML 2.0 allows Cisco administrative users to access secure web domains to exchange user authentication and authorization data, between an IdP and a Service Provider while maintaining high security levels. The feature provides secure mechanisms to use common credentials and relevant information across various applications.

The authorization for SAML SSO Admin access is based on Role-Based Access Control (RBAC) configured locally on Cisco collaboration applications.

Single Sign on Single Service Provider Agreement

SAML SSO establishes a Circle of Trust (CoT) by exchanging metadata and certificates as part of the provisioning process between the IdP and the Service Provider. The Service Provider trusts the IdP's user information to provide access to the various services or applications.

Important Service providers are no longer involved in authentication. SAML 2.0 delegates authentication away from the service providers and to the IdPs.

The client authenticates against the IdP, and the IdP grants an Assertion to the client. The client presents the Assertion to the Service Provider. Since there is a CoT established, the Service Provider trusts the Assertion and grants access to the client.

Single sign-on allows you to access multiple Cisco collaboration applications after logging on to one of them. In the releases earlier than Unified Communications Manager Release 11.5, when administrators enabled SSO, each cluster node generated its own service provider metadata (SP metadata) file with a URL and a certificate. Each generated file had to be uploaded separately on Identity Provider (IDP) server. As the IDP server considered each IDP and SAML exchange as a separate agreement, the number of agreements that were created was equivalent to the number of nodes in the cluster.

To improve the user experience and to reduce the total cost of the solution for large deployments, this release is enhanced. Now, it supports a single SAML agreement for a Unified Communications Manager cluster (Unified Communications Manager and Instant Messaging and Presence (IM and Presence)).

SAML-Based SSO Features

Enabling SAML SSO results in several advantages:

• It reduces password fatigue by removing the need for entering different user name and password combinations.
• It transfers the authentication from your system that hosts the applications to a third party system. Using SAML SSO, you can create a circle of trust between an IdP and a service provider. The service provider trusts and relies on the IdP to authenticate the users.
• It protects and secures authentication information. It provides encryption functions to protect authentication information passed between the IdP, service provider, and user. SAML SSO can also hide authentication messages passed between the IdP and the service provider from any external user.
• It improves productivity because you spend less time re-entering credentials for the same identity.
• It reduces costs as fewer help desk calls are made for password reset, thereby leading to more savings.

Basic Elements of a SAML SSO Solution

• Client (the user's client): This is a browser-based client or a client that can leverage a browser instance for authentication. For example, a system administrator's browser.
• Service provider: This is the application or service that the client is trying to access. For example, Unified Communications Manager.
• An Identity Provider (IdP) server: This is the entity that authenticates user credentials and issues SAML Assertions.
• Lightweight Directory Access Protocol (LDAP) users: These users are integrated with an LDAP directory, for example Microsoft Active Directory or OpenLDAP. Non-LDAP users reside locally on the Unified Communications server.
• SAML Assertion: It consists of pieces of security information that are transferred from IdPs to the service provider for user authentication. An assertion is an XML document that contains trusted statements about a subject including, for example, a username and privileges. SAML assertions are usually digitally signed to ensure their authenticity.
• SAML Request: This is an authentication request that is generated by a Unified Communications application. To authenticate the LDAP user, Unified Communications application delegates an authentication request to the IdP.
• Circle of Trust (CoT): It consists of the various service providers that share and authenticate against one IdP in common.
• Metadata: This is an XML file generated by an SSO-enabled Unified Communications application (for example, Unified Communications Manager, Cisco Unity Connection, and so on) as well as an IdP. The exchange of SAML metadata builds a trust relationship between the IdP and the service provider.
• Assertion Consumer Service (ACS) URL: This URL instructs the IdPs where to post assertions. The ACS URL tells the IdP to post the final SAML response to a particular URL.

Note: All in-scope services requiring authentication use SAML 2.0 as the SSO mechanism.

See the following figure for the identity framework of a SAML SSO solution.

Cisco Unified Communications Applications that Support SAML SSO

• Unified Communications Manager
• Unified Communications Manager IM and Presence Service

Chapter 2: SAML SSO Requirements for Identity Providers

• Requirements for Identity Providers, on page 11
• SAML Agreement Types, on page 12
• Metadata Exchange, on page 13
• SAML Assertions, on page 15
• SAML OAuth Authentication Flow, on page 17

Requirements for Identity Providers

This section provides an outline of the requirements that Identity Providers must meet in order to deploy SAML SSO services for Cisco Collaboration applications.

Identity Providers must adhere to the following guidelines:

• Support is for SAML 2.0 only.
• Supports Service-Provider initiated SSO only.
• Set the NameID Format attribute to urn:oasis:names:tc:SAML:2.0:nameid-format:transient
• Configure a claim on the IdP to include the uid attribute name with a value that is mapped to LDAP attributes (for example SAMAccountName).
• Cisco Unified Communications Manager uses ACS url index in the Authentication Request. The IdP must be able the index to the ACS url in the Service Provider metadata. This is compliant with SAML standards.
• It's not supported to have multiple certificates in the Signing and Encryption portion of the SAML Assertion. See CSCvq78479.

When configuring SAML SSO, make sure to deploy the following in your Cisco Collaboration Deployment:

• Network Time Protocol—Deploy NTP in your environment so that the times in your Cisco Collaboration Deployment and your Identity Provider are synced. Make sure that the time difference between the IdP and the Cisco Collaboration deployment does not exceed 3 seconds.
• DNS—Your Cisco Collaboration applications and your Identity Provider must be able to resolve each other's addresses.
• LDAP—You must have an LDAP Directory sync configured in your Cisco Collaboration deployment. However, we recommend that you disable LDAP authentication.
• Certificates—You must exchange metadata files between your Cisco Collaboration deployment and the Identity Provider. The metadata contains the certificates that are required to create a trust relationship between your Collaboration deployment and the Identity Provider. You can use either a tomcat certificate or a system-generated self-signed certificate to establish trust.

SAML Agreement Types

Cisco Unified Communications Manager supports two types of SAML metadata agreements:

• Cluster Wide—With this deployment, a single metadata agreement must be configured, which covers the entire cluster.
• Per Node—With this deployment, you must configure multiple metadata agreements, with a separate agreement for each cluster node. Each cluster node has a separate metadata exchange with the Identity Provider.

The following image illustrates the contents of a metadata zip file that was generated on Cisco Unified Communications Manager using a per node agreement. In this example, the IM and Presence Service is deployed using a Standard Deployment (non-centralized) so the zip file contains separate metadata xml files for each Unified Communications Manager and IM and Presence Service cluster node.

Note If you have a Centralized Deployment for the IM and Presence Service, your IM and Presence deployment is in a separate cluster from your telephony cluster. With Cluster Wide agreements, you must generate metadata separately for your telephony cluster, and for your IM and Presence cluster.

Metadata Exchange

As a part of the process for setting up SAML SSO, you must exchange metadata files between your UC deployment and the Identity Provider.

Following is an example of a UC metadata file that was generated from the Service Provider (Cisco Unified Communications Manager).

Following is an example of a metadata file that was generated from an Identity Provider. In this example, the metadata file was generated from the PingFederate Identity Provider.

SAML Assertions

Following is an example of the SAML Assertion that is sent from the Identity Provider to Cisco Unified Communications Manager:

SAML OAuth Authentication Flow

Following is an example of the authentication flow for an OAuth authentication request with the Identity Provider.

Chapter 3: SAML SSO Configuration

• SAML-Based SSO Prerequisites, on page 19
• SAML SSO Configuration Task Flow, on page 23
• SAML SSO Additional Tasks, on page 28
• SAML SSO Deployment Interactions and Restrictions, on page 32

SAML-Based SSO Prerequisites

The following system setup is required for SAML-Based SSO configuration:

• NTP Setup
• DNS Setup
• Directory Setup

NTP Setup

In SAML SSO, Network Time Protocol (NTP) enables clock synchronization between the Unified Communications applications and IdP. SAML is a time sensitive protocol and the IdP determines the time-based validity of a SAML assertion. If the IdP and the Unified Communications applications clocks are not synchronized, the assertion becomes invalid and stops the SAML SSO feature. The maximum allowed time difference between the IdP and the Unified Communications applications is 3 seconds.

Note For SAML SSO to work, you must install the correct NTP setup and make sure that the time difference between the IdP and the Unified Communications applications does not exceed 3 seconds.

DNS Setup

Domain Name System (DNS) enables the mapping of host names and network services to IP addresses within a network or networks. DNS server(s) deployed within a network provide a database that maps network services to hostnames and, in turn, hostnames to IP addresses. Devices on the network can query the DNS server and receive IP addresses for other devices in the network, thereby facilitating communication between network devices.

Directory Setup

Unified Communications applications can use DNS to resolve fully qualified domain names to IP addresses. The service providers and the IdP must be resolvable by the browser. For example, when the administrator enters the service provider hostname (http://www.cucm.com/ccmadmin) in the browser, the browser must resolve the hostname. When the service provider redirects the browser to IdP (http://www.idp.com/saml) for SAML SSO, the browser must also resolve the IdP hostname. Moreover, when the IdP redirects back to the service provider ACS URL, the browser must resolve that as well.

LDAP directory synchronization is a prerequisite and a mandatory step to enable SAML SSO across various Unified Communications applications. Synchronization of Unified Communications applications with an LDAP directory allows the administrator to provision users easily by mapping Unified Communications applications data fields to directory attributes.

Note To enable SAML SSO, the LDAP server must be trusted by the IdP server and supported by Unified Communications applications.

For more information, see the "Directory Integration and Identity Management" chapter of the Cisco Collaboration System Solution Reference Network Designs at: https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-system/products-implementation-design-guides-list.html

Certificate Management and Validation

Important Cisco strongly recommends that server certificates are signed for SAML SSO and that multiserver certificates are used where product support is available.

• Common Names (CN) and Subject Alternative Names (SAN) are references to the IP address or Fully Qualified Domain Name (FQDN) of the address that is requested. For instance, if you enter https://www.cisco.com, then the CN or SAN must have “www.cisco.com” in the header.
• If the Unified Communications Manager is already in Mixed/Secure Mode and there are changes made to the certificates, then the CTL certificate must be updated using the secure USB token. Otherwise the Cisco Jabber client will not be able to acquire telephony capability. The CTL token update requires a Unified Communications Manager restart.

In SAML SSO, each entity participating in the SAML message exchange, including the user's web browser, must establish a seamless secure HTTPS connections to the required entities. Cisco strongly recommends that signed certificates issued by a trusted Certificate Authority be configured on each UC product participating in the SAML SSO deployment.

Unified Communications applications use certificate validation to establish secure connections with servers. Certificates are used between end points to build a trust/authentication and encryption of data. This confirms that the endpoints communicate with the intended device and have the option to encrypt the data between the two endpoints.

When attempting to establish secure connections, servers present Unified Communications clients with certificates. If the client cannot validate a certificate, it prompts the user to confirm if they want to accept the certificate.

Certificates Signed by a Certificate Authority

Cisco recommends using server certificates that are signed by one of the following types of Certificate Authority (CA):

• Public CA - A third-party company verifies the server identity and issues a trusted certificate.
• Private CA - You create and manage a local CA and issue trusted certificates.

The signing process varies for each product and can vary between server versions. It is beyond the scope of this document to provide detailed steps for every version of each server. Refer the appropriate server documentation for detailed instructions on how to get certificates signed by a CA.

However, the following steps provide a high-level overview of the procedure:

Procedure

1. Generate a Certificate Signing Request (CSR) on each product that can present a certificate to the client.
2. Submit each CSR to the CA.
3. Upload the certificates that the CA issues to each server.

Every server certificate should have an associated root certificate present in the trust store on client computers. Cisco UC applications validate the certificates that servers present against the root certificates in the trust store.

If you get server certificates signed by a public CA, the public CA should already have a root certificate present in the trust store on the client computer. In this case, you do not need to import root certificates on the client computers.

You should import root certificates if the certificates are signed by a CA that does not already exist in the trust store, such as a private CA.

In SAML SSO, the IdP and service providers must have CA signed certificates with the correct domains in the CN or SAN. If the correct CA certificates are not validated, the browser issues a pop up warning.

For example, when the administrator points the browser to https://www.cucm.com/ccmadmin; the Unified Communications Manager portal presents a CA certificate to the browser. When the browser is redirected to https://www.idp.com/saml, the IdP presents a CA certificate. The browser will check that the certificate presented by the servers contains CN or SAN fields for that domain, and that the certificate is signed by a trusted CA.

Alternatively, if the customer has their own private CA, then that CA must be installed as a root trust anchor on the computers that the administrator is launching their browser from.

Configure Multiserver SAN Certificates

Each Cisco product has its own process for generating multiserver SAN certificates. For information about the Cisco products that support multiserver SAN certificates see the relevant guide.

Related Topics

• Release Notes for Cisco Unified Communications Manager, Release 10.5(1)
• Cisco Unified Communications Operating System Administration Guide for Cisco Unity Connection Release 10.x
• Cisco Prime Collaboration

Deploy Certificate Issuer for Microsoft Edge Interoperability

An interoperability issue exists within SAML SSO deployments where the Microsoft Edge Browser is deployed. If the Edge Browser is deployed on an SSO-enabled machine, the Edge browser does not recognize the certificate issuer of the Unified Communications Manager certificate and does not provide access.

Use this procedure to fix this issue via the Group Policy Object (GPO) and Active Directory whereby you can push the certificate issuer of the Unified Communications Manager certificate to the Trusted Root Certification of local machines that use the Edge browser.

Note The "certificate issuer" depends on how your certificates are set up. For example, for third-party CA certificates, You may need to push the CA certificate only if the CA itself signs the Unified Communications Manager certificate. However, if an intermediate CA signs the Unified Communications Manager certificate, you may need to push the complete certificate chain, which will include the root certificate, intermediate certificate, and any leaf certificates.

Before you begin

Membership in the local Administrators group, or equivalent, of the local machine is the minimum required to complete this procedure

Procedure

1. In Active Directory, Open Group Policy Management Console.
2. Find an existing GPO or create a new GPO to contain the certificate settings. The GPO must be associated with the domain, site, or organizational unit whose users you want affected by the policy.
3. Right-click the GPO, and select Edit.
4. The Group Policy Management Editor opens, and displays the current contents of the policy object. In the navigation pane, open Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Publishers.
5. Click the Action menu, and click Import.
6. Follow the instructions in the Certificate Import Wizard to find and import the certificate.
7. If the certificate is self-signed, and cannot be traced back to a certificate that is in the Trusted Root Certification Authorities certificate store, then you must also copy the certificate to that store. In the navigation pane, click Trusted Root Certification Authorities, and then repeat steps 5 and 6 to install a copy of the certificate to that store.

Note For additional information on Managing Trusted Root Certificates in Active Directory, see https://technet.microsoft.com/en-us/library/cc754841(v=ws.11).aspx.

SAML SSO Configuration Task Flow

Complete these tasks to configure SAML SSO in your Cisco Collaboration environment. This process includes procedures for the following applications:

• Cisco Unified Communications Manager
• IM and Presence Service
• Cisco Unity Connection
• Cisco Expressway (with MRA Deployments)

Procedure

Initiate SSO Configuration on Collaboration Applications

In your Cisco Collaboration environment, begin the SAML SSO configuration and export UC metadata for upload into your Identity Provider. Depending on the applications for which you are configuring SAML SSO, and the options chosen, you may have multiple download files.

Before you begin

Make sure that you plan beforehand what type of SAML SSO agreement you want (cluster wide or per node), along with the certificate type.

Procedure

1. On Cisco Unified Communications Manager, export a UC metadata file:
   • From Cisco Unified CM Administration, choose System > SAML Single Sign On.
   • Select an SSO Mode option: Cluster wide or Per Node.
   • Select a Certificate option: System generated self-signed certificate or a Cisco Tomcat certificate.
   • Click Export All Metadata and save the metadata file to a secure location.
   With cluster wide agreements, you will receive a single metadata file. With per node agreements, the zip file download contains a separate XML files for each cluster node. If you have IM and Presence Service deployed in a Standard deployment,
2. IM and Presence Service—If you have a Centralized Deployment for the IM and Presence Service, repeat step 1 on the standalone Unified CM publisher node that is a part of your IM and Presence central cluster.
   Note With IM and Presence Service Standard Deployments you can skip this task because the the metadata file that you downloaded from Unified Communications Manager in the previous step includes metadata for the IM and Presence Service cluster.
3. On Cisco Unity Connection, export a metadata file:
   • From Cisco Unity Connection Administration, choose System Settings > SAML Single Sign On.
   • Select the SSO Mode option: Cluster wide or Per node.
   • Click Export All Metadata.
4. On Cisco Expressway-C, export a metadata file:
   • On the Expressway-C primary peer, go to Configuration > Unified Communications > Configuration
   • In the MRA Access Control section, choose either of the following options for the Authentication path:
     • SAML SSO authentication
     • SAML SSO and UCM/LDAP—Allows either method.
   • Choose a SAML Metadata option: Cluster or Peer
     • Cluster-Single metadata file for cluster
     • Peer-Separate metadata files per node.
   • Click Export SAML data.
   • For Cluster agreements, click Generate Certificate and then Download the certificate.
   • For Peer agreements, Download All.
   • Save in a secure location.

At the completion of this procedure, you will have metadata files for each of your Collaboration applications. The number of metadata files depends on your configuration and deployment type.

Metadata Download Example

Refer to the following for an example of the number of file downloads you can expect from your Cisco Collaboration deployment. Assume that you are configuring SSO for the following applications:

• A five-node Cisco Unified Communications Manager cluster
• A three-node IM and Presence Service cluster
• A two-node Cisco Unity Connection cluster
• A three-node Expressway-C cluster accompanied with a 3-node Expressway-E cluster (MRA deployment)

The following table provides a breakdown of the total download files that you can expect depending on whether you are uisng cluster-wide agreements, and whether the IM and Presence Service is in a Standard Deployment or Centralized Deployment.

Configure SAML SSO on Identity Provider

On the Identity Provider, you need to:

• Import the UC metadata files that you downloaded from your Cisco Collaboration environment
• Configure SAML SSO agreements to your Cisco Collaboration applications
• Export an Identity Provider metadata file that you will later import into your Cisco Collaboration applications

Cisco provides the following Idp-specific configuration examples as a guide for you to use:

• Microsoft Active Directory Federation Services 2.0
• Microsoft Active Directory Federation Services 3.0
• Microsoft Azure
• Okta
• Open AM
• PingFederate

Note The above links are examples only. Refer to your IdP documentation for official documentation.

Enable SAML SSO for Cisco Collaboration Applications

Before you begin

Import the Identity Provider metadata into your Cisco Collaboration applications and complete the SAML SSO configuration.

Procedure

1. On Cisco Unified Communications Manager, complete the SSO configuration:
   1. Restart the Cisco Tomcat server before enabling SAML SSO.
   2. From Cisco Unified CM Administration, choose System > SAML Single Sign On.
   3. Click Enable SAML SSO.
   4. Click Continue and follow the prompts.
   5. Cluster wide agreements only. Click Test for Multi-server tomcat certificates.
   6. Click Next
   7. Browse to select your IdP metadata file. After you have opened the file, click Import IdP Metadata.
   8. Click Next.
   9. Select an LDAP-synchronized whom has Standard CCM Super User permissions and Run SSO test.
   10. Sign in with the user's credentials.
   11. Click Finish to complete the SAML SSO setup.
   12. Restart the Cisco Tomcat server.
   13. Per node agreements only. Repeat this process on each Unified Communications Manager node.
2. IM and Presence Service—If you have a Centralized Deployment of the IM and Presence Service, repeat the previous step on the standalone Unified CM publisher node that is a part of the IM and Presence central cluster.
3. On Cisco Unity Connection, complete the SAML SSO configuration:
   1. Restart the Cisco Tomcat server before enabling SAML SSO.
   2. In Cisco Unity Connection Administration, go to System Settings > SAML Single Sign On.
   3. Click Enable SAML Single Sign On.
   4. Click Continue and follow the prompts
   5. Import the IdP metadata file into Cisco Unity Connection.
   6. Test the SSO Connection.
   7. Restart the Cisco Tomcat server.
   8. Per node agreements only. Repeat this process for each cluster node.
4. On the Expressway-C primary peer, complete the SAML SSO configuration:
   1. Go to Configuration > Unified Communications > Identity providers.
   2. Click Import new IdP from SAML.
   3. Use Import SAML file control to locate the IdP metadata file.
   4. Set the Digest to the required SHA hash algorithm.
   5. Click Upload.
      Note You can change the signing algorithm after you have imported the metadata, by going to Configuration > Unified Communications > Identity Providers (IdP) locating your IdP row then, in the Actions column, clicking Configure Digest).
   6. Verify that the IdP appears in the list of Identity Providers.
   7. Click Associate Domains in the IdP row.
   8. Check the domains that you want to assign to this Identity Provider.
   9. Click Save.
      Note If you are deploying Cisco Expressway with Active Directory Federation Services (ADFS) for SAML SSO, refer to Additional Expressway Configuration for ADFS, on page 28 for additional Expressway settings.

Chapter 4: End User SAML SSO

• End User SAML SSO Configuration, on page 33

End User SAML SSO Configuration

End user or federated SSO is a standard that allows products to meet customer compliance requirements, reduce the total cost of ownership, and improve end user experience. The foundation for this support in the collaboration products has been introduced in the 10.0 and 10.5 releases. This allows administrators to configure the infrastructure in preparation for end user clients such as Cisco Unity Connection and Cisco Jabber, which is rolling out support for users with release 10.5 in the second half of 2014.

Once an Administrator enables this feature for users it will allow users in a Cisco collaboration application to log in to supported applications with their corporate username and password. If the Cisco application is accessed by way of a browser the user can use the same corporate username and password to log in. If the user has already logged in to another corporate application in that same browser they should be able to access the application without having to provide a username and password. All of these features are available within the customer network or accessible by way of a VPN.

The supported products are:

The supported end user clients are:

Note

• When deploying Cisco Jabber with Cisco WebEx Meeting Server, Unified Communications Manager and the WebEx Meeting Server must be in the same domain.
• When Cisco Jabber is running with SSO on a Mac, Jabber cannot automatically set a cookie once authorized for Jabber services. Mac behavior, by default, only allows cookies for sites the user navigates to. Each time Jabber needs to check for authentication it has to go to the IdP.
• The SAML Assertion must include the email address for WebEx; the SAML Schemas should be aligned to cover that.
• To trigger OAuth timer expiration correctly, ensure that the OAuthTokenExpiry value on Unified Communications Manager is greater than the WebsessionApp expiry value on Tomcat.