The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Prerequisites
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. |
For information about synchronizing clocks, see the NTP Settings section in Cisco Unified Communications Operating System Administration Guide.
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.
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 following URL:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab10/directry.html
Cisco strongly recommends that server certificates are signed for SAML SSO and that multiserver certificates are used where product support is available.
Note |
|
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.
Cisco recommends using server certificates that are signed by one of the following types of Certificate Authority (CA):
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:
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 CUCM 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.
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.
To enable SAML SSO across Unified Communications applications, the administrator must establish a Circle of Trust (CoT) between the Service Provider and the IdP. The following steps provide a high-level overview of the procedure.
If there is no existing CoT to add Cisco Unified Communications Manager to, then a CoT must be created before SAML SSO becomes active.
This example uses OpenAM to create a CoT.
SAML SSO Configuration Workflow
There are three required tasks and one optional task to enable SAML SSO regardless of the IdP used:
Tip | For SAML SSO to work, the Cisco Unified Communications Manager and the IdP (in this case OpenAM) clocks must be synchronized. |
Step 1 | Log in to the Cisco Unified CM Administration user interface. | ||
Step 2 | Choose SAML Single Sign-On Configuration window opens. and the | ||
Step 3 | To enable SAML SSO on the cluster, click on the Enable SAML SSO link. | ||
Step 4 | In the
Reset
Warning window, click
Continue.
|
If you have not yet created a Circle of Trust, you can do it now or shift tasks while configuring the IdP. We recommend that the Circle of Trust be created before you configure the IdP for SAML SSO.
This example uses the OpenAM IdP. This task involves switching actions between the OpenAM IdP server and Cisco Unified Communication Manager nodes.
Create a Circle of Trust (CoT)
Configure Cisco Unified Communications Manager for SAML SSO
Step 1 | Log in to the
OpenAM
IdP server and download the metadata trust file.
| ||
Step 2 | Access the
Cisco
Unified CM Administration user interface, and perform the following
tasks:
| ||
Step 3 | Access the
OpenAM server user interface and upload the Metadata files for each node in the
cluster.
| ||
Step 4 | Once the CoT has been created, the
Cisco Unified Communications Manager node(s) need to
be added as Entity providers. To do this:
| ||
Step 5 | In the OpenAM server you will also need to add a user whose credentials match the administrator level user, which were used to enable SSO on the Cisco Unified Communications Manager. |
After the OpenAM server and Cisco Unified Communications Manager node(s) have been configured, you can verify a successful enablement of SAML SSO on the Cisco Unified CM Administration user interface.
What to Do Next
Step 1 | On the Cisco Unified CM Administration user interface, choose and the SAML Single Sign-On Configuration window opens, click Next. | ||
Step 2 | Choose an administrative user form the Valid Administrator Usernames area and click the Run SSO Test… button.
|
If the test succeeds, then SAML SSO has been successfully configured.
Cisco collaboration applications favor SAML SSO over the proprietary OpenAM SSO solution because OpenAM is complex in nature and the deployment does not scale as per the customers’ requirements.
Note | The OpenAM SSO that is deployed using Agent Flow is still available in release 10.5(1) to facilitate partners who are currently using that solution. You can reuse the existing OpenAM deployment for SAML SSO after you reconfigure OpenAM SSO. |
Note | From release 10.0(1) and later, Agent Flow SSO is not compatible with FIPS mode. |
To reconfigure OpenAM SSO to SAML SSO, the administrator must create a new federation service and service account. For SAML SSO to work as expected, the service provider and IdP must be in the same Circle of Trust (CoT). The administrator needs to configure a trust relationship between the service provider and IdP. The following steps describe the configuration of OpenAM SSO to SAML SSO on Cisco Unified Communications Manager.
In this case, you continue to use OpenAM as the IdP, however OpenAM must be reconfigured to SAML.
Step 1 | Disable
OpenAM Agent Flow mode of operation on all servers where it is enabled by using
CLI commands.
| ||||
Step 2 | Enable SAML
SSO on those servers.
| ||||
Step 3 | Log in to the OpenAM server user interface. | ||||
Step 4 | Choose the Federation tab and under Circle of Trust, click New. | ||||
Step 5 | Create a CoT by entering a unique name for the IdP Circle of Trust. | ||||
Step 6 | To create a hosted IdP, choose the Common Tasks tab and click Create hosted Identity Provider. | ||||
Step 7 | Use the
default values for other parameters and click
Save.
| ||||
Step 8 | Choose the Federation tab and under the Entity Providers section, click the Hosted Identity Provider you created. | ||||
Step 9 | Choose the Assertion Content tab and under the Certificate Aliases section, enter <test> as an alias for signing SAML assertions in the Signing field . | ||||
Step 10 | Choose the Federation tab, and in the Entity Providers section, click Import Entity. | ||||
Step 11 | Upload the
Cisco Unified Communications Manager metadata file
(sp.xml), and click
Save.
| ||||
Step 12 | Choose the entity imported in Step 10. | ||||
Step 13 | Choose the
Assertion Processing tab and add a mapping attribute
for uid as per the Directory and OpenAM settings.
| ||||
Step 14 | Choose the Federation tab, and click Circle of Trust. | ||||
Step 15 | To assign the IdP and the Cisco Unified Communications Manager to be in the same CoT: in the Entity Providers area, move the IdP (OpenAM server) and the Cisco Unified Communications Manager entities from the Available section to the Selected section. The OpenAM server is successfully configured as IdP. |