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
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.
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.
Enable SAML SSO through the OpenAM IdP
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 OpenAM. We recommend that the Circle of Trust be created before you configure OpenAM for SAML SSO.
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. |
Once 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 NextVerify the SAML SSO Configuration.
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 currently offers the following types of Single Sign-On (SSO) solutions:
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 | 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. |