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. |
For information on adding an NTP server in order to synchronize clocks, see the "Core Settings for Device Pools" chapter of the System Configuration Guide for Cisco Unified Communications Manager.
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.
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.
Directory Setup
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:
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. |
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.
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
Step 1 |
Generate a Certificate Signing Request (CSR) on each product that can present a certificate to the client. |
Step 2 |
Submit each CSR to the CA. |
Step 3 |
Upload the certificates that the CA issues to each server. |
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.
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
Step 1 |
In Active Directory, Open Group Policy Management Console. |
Step 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. |
Step 3 |
Right-click the GPO, and select Edit. |
Step 4 |
In the navigation pane, open . |
Step 5 |
Click the Action menu, and click Import. |
Step 6 |
Follow the instructions in the Certificate Import Wizard to find and import the certificate. |
Step 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. |