Single Sign-On

Single Sign-On

Single sign-on (SSO) is an authentication process that allows users to sign in to one application and then securely access other authorized applications without needing to resupply user credentials. SSO permits Cisco supervisors or agents to sign on only once with a username and password to gain access to all of their Cisco browser-based applications and services within a single browser instance. By using SSO, Cisco administrators can manage all users from a common directory and enforce password policies for all users consistently.


Note

  • SSO is an optional feature.

  • The implementation requires you to use the HTTPS protocol only to access all the web applications. The HTTP access to web applications is not supported when the SSO is enabled.

  • Use Fully Qualified Domain Names and not IP addresses to access the web applications.

SAML 2.0 Authentication

SSO uses Security Assertion Markup Language (SAML) to exchange authentication details between an Identity Provider (IdP) and a service provider. The identity provider authenticates user credentials and issues SAML assertions, which are pieces of security information transferred from the identity provider to the service provider for user authentication. Each assertion is an XML document that contains trusted statements about a subject including, for example, username and privileges. SAML assertions are usually digitally signed to ensure their authenticity.

A generic SAML authentication flow consists of:

  • Client - A browser-based user client used to access a service.

  • Service Provider - An application or service the user tries accessing.

  • Identity Provider - An entity performing the user authentication.

The identity provider keeps actual credentials and authentication mechanism hidden. Based on the authentication process result, the identity provider issues SAML assertions.

Elements Used in SAML 2.0

The following is the list of elements that are used in SSO SAML 2.0 authentication:

  • Client (the user’s client)—A browser-based client or a client that can leverage a browser instance for authentication. For example, a system administrator’s browser.

  • Lightweight Directory Access Protocol (LDAP) users—Users are integrated with an LDAP directory. For example, Microsoft Active Directory or OpenLDAP.

  • Security Assertion Markup Language (SAML) assertion—An assertion is an XML document that contains trusted statements about a subject. For example, a username. SAML assertions are digitally signed to ensure their authenticity. It consists of pieces of security information that are transferred from Identity Providers (IdPs) to the service provider for user authentication.

  • Service Provider (SP)—An application or service that trusts the SAML assertion and relies on the IdP to authenticate the users. For example, Cisco Identity Service (IdS).

  • An Identity Provider (IdP) server—This is the entity that authenticates user credentials and issues SAML assertions.

  • SAML Request—An authentication request that is generated by a Cisco Identity Service (IdS). To authenticate the LDAP user, IdS delegates an authentication request to the IdP.

  • Circle of Trust (Co-T)—It consists of the various service providers that share and authenticate against one IdP in common.

  • Metadata—An XML file generated by the Cisco IdS (for example, Cisco Identity Service Management) and an IdP. The exchange of SAML metadata builds a trust relationship between the IdP and the service provider.

  • Assertion Consumer Service (ACS) URL—A URL that instructs the IdPs where to post SAML assertions.

Cisco Identity Service (IdS)

Authentication is managed for the contact center solution by the Cisco Identity Service (Cisco IdS). When an SSO-enabled user signs in, the Cisco IdS interacts first with the customer's Identity Provider (IdP) to authenticate the user. The IdP stores user profiles and provides authentication services to support SSO sign-ins. When the user is authenticated, the Cisco IdS exchanges information with the Cisco service the user is attempting to access to confirm that the user is authorized for the role they are requesting. When the user is both authenticated and authorized, the IdS issues an access token that allows the user to access the application. When the access is established during a particular session, the user can switch among contact center solution applications without presenting credentials again.

Authentication and Authorization Flow

The complete authentication and authorization flow has been simplified as:

  • When you access an application with protected resources, the application will redirect you to the Cisco Identity Service for authentication. Cisco Identity Service leverages SAML and generates a SAMLRequest and redirects the browser to the Identity Provider.

  • The browser authenticates directly against the Identity Provider. Applications are not involved in the authentication process and have no access to user credentials.

  • The OAuth flow accesses the resource with a token which is then validated.

  • Cisco Identity Service sends an authentication request through the browser to the identity provider.

  • The user enters the login credentials to the identity provider for authentication. After the assertion is successful and the user attributes are read it will redirect to the original application that was accessed. Cisco Identity Service accompanied by an assertion that confirms successful authentication and includes user information and access rights for the web application.

Figure 1. Authentication and Authorization Flow


Single Sign-On (SSO) Considerations

The Single Sign-on feature authenticates and authorizes users for all the contact center solution applications and services. Authentication is the process of validating the identity of a user: "you are who you say you are." Authorization is the process of confirming that an authenticated user is permitted to perform the action they are requesting: "you can do what you are asking to do." When you enable SSO in the contact center solution, users only sign in once to gain access to all of their Cisco browser-based applications and services.

To support SSO for the contact center solution, you must install and configure an Identity Provider (IdP) that is compliant with the Security Assertion Markup Language 2.0 (SAML v2) Oasis standard. For a current list of supported Identity Provider products and versions, see the Unified CCX Compatibility related information located at: https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/products-device-support-tables-list.html.

Authentication and authorization are managed for the contact center solution by the Cisco Identity Service (Cisco IdS). When an SSO-enabled user signs in, the Cisco IdS interacts first with your Identity Provider (IdP) to authenticate the user. The IdP stores user profiles and provides authentication services to support SSO sign-ins. When the user is authenticated, the Cisco IdS exchanges information with the Cisco service the user is attempting to access to confirm that the user is authorized for the role they are requesting. When the user is authenticated, the Cisco IdS issues an access token that allows the user to access the application. Once access is established during a particular session, the user can switch among contact center solution applications without presenting credentials again.


Note

The user credentials are only presented to the IdP. The contact center solution applications and services only exchange tokens; they do not see the users' information.

To integrate your IdP with your contact center solution, you perform the following administrative tasks:

  • Establish a trust relationship between the Cisco IdS and the Identity Provider.

  • Set the SSO mode in your system to enable users for SSO.

  • Register on the Single Sign-On web page to onboard the single sign-on components.

  • Perform Test SSO Setup on the single sign-on web page to test the status of registration of each component. You will be redirected to the Identity Provider for authentication. If the Test SSO Setup is successful then the Enable option is enabled.

SSO Message Flow

An SSO user's access token is issued by Cisco IdS to validate the users accessing the corresponding applications. When the user is found valid each application performs the authorization locally. Cisco IdS supports authorization Code Grant Flow as defined in OAuth 2.0 and in turn uses SAML v2.0 to authenticate users before issuing auth code.

When a user browses to a web page for an SSO-enabled service, the authentication request is redirected to the Cisco Identity Service. Cisco Identity Service generates a SAML authentication request and directs it to the Identity Provider. The IdP presents a sign-in page to the user at the browser to collect the user's credentials. After the IdP authenticates the user, the IdP issues a SAML assertion to the Cisco IdS. The assertion contains trusted statements about the user, for example, username and privileges.

The assertions must have attributes. The Cisco IdS extracts uid and user principal and generates and delivers authorization code to the SSO enabled application. The application on receiving the authorization code will request IDs For Access and Refresh Tokens.

Access Tokens are used by applications to validate user information and Refresh Token are used to request new Access Tokens. These token have a validity period associated with each one of them.


Note

A new Access token and Refresh token pair can be obtained only before the Auth code expires.

Access Tokens can be refreshed only when both the current access token and the refresh token are valid and not expired.

If the refresh tokens expire you can not refresh an access token. Thus you need to be authenticated again and the auth code need to ne requested again.

Together SAML and OAuth make it possible for a user to authenticate while only exposing user credentials to the authentication provider. The username and password are only presented to the IdP. The contact center solution applications and services do not see the user information. Only the SAML assertion and the OAuth token are exchanged.

Single Sign-On High Availability Considerations

Every core component in the contact center solution has the Cisco Identity Service client that supports an high availability mode. Any SSO enabled application can connect to either to the local Cisco Identity Service instance or to the remote.

By default it will connect to the local instance of Cisco Identity Service. The Local Cisco Identity Service is the default and the preferred Cisco Identity Service that runs locally.

Cisco Identity Service client supports failover if the remote Cisco Identity Service is configured when the local Cisco Identity Service fails. When the local Cisco Identity Service is available again the Cisco Identity Service client fails back to the local Cisco Identity Service.

The below table provides the details of Cisco Identity Service client failover and failback in different states of the local and remote Cisco Identity Service:
Table 1. Failover and Failback Scenarios of Cisco Identity Service Client Based on the State of Cisco Identity Service

Local Cisco Identity Service

Remote Cisco Identity Service

Cisco Identity Service Client Connects to

IN_SERVICE

Not Applicable

Local Cisco Identity Service

PARTIAL_SERVICE

IN_SERVICE

Remote Cisco Identity Service

PARTIAL_SERVICE

PARTIAL_SERVICE

Local Cisco Identity Service

OUT_OF_SERVICE

PARTIAL_SERVICE

Remote Cisco Identity Service

OUT_OF_SERVICE

OUT_OF_SERVICE

None

OUT_OF_SERVICE

Not Configured

None

Single Sign-On Design Impacts

This section details few of the design impacts of the Single Sign-On (SSO) feature. The implementation requires you to use only HTTPS protocol to access all the web applications. The HTTP access to web applications is not supported when the SSO is enabled.

Authentication Modes in Unified CCX

You can choose from two different authentication modes when deciding about implementing SSO:

  • SSO - Enable all agents, supervisors, and administrators (administrators of the Cisco Unified CCX Administration or Cisco Unified CCX Serviceability application) in the deployment for SSO.

  • Non-SSO - Use existing Unified CM-based or local authentication.

Applications in SSO Mode

  • Cisco Unified Intelligence Center (CUIC)

  • Cisco Finesse

  • Cisco Finesse-hosted gadgets

  • Cisco Unified CCX Administration

  • Cisco Unified CCX Serviceability.


Note

The Cisco Finesse IP Phone Agent is not supported in SSO enabled mode.

Single Sign-On can independently function on Unified CM and Unified CCX. It is not inter dependant on each other.

Applications not SSO Enabled

The following applications are not Single Sign-On enabled:

  • Cisco Finesse Administration

  • Cisco Identity Service Administration

  • Disaster Recovery System

  • Cisco Unified OS Administration

  • Cisco Unified Serviceability

  • Standalone Cisco Unified Intelligence Center

  • Cisco Unified CCX Editor

  • Real Time Monitoring Tool

  • Cisco SocialMiner

  • Cisco Workforce Optimization

  • Cisco Finesse Desktop Chat

  • Any Third Party Application.

Configure the Cisco Identity Service

The Cisco Identity Service (Cisco IdS) provides authorization between the Identity Provider (IdP) and applications.

When you configure the Cisco IdS, you set up a metadata exchange between the Cisco IdS and the IdP. This exchange establishes a trust relationship that then allows applications to use the Cisco IdS for single sign-on. You establish the trust relationship by downloading a metadata file from the Cisco IdS and uploading it to the IdP. You can then select settings related to security, identify clients of the Cisco IdS service, and set log levels and, if desired, enable Syslog format.

Procedure

Step 1

In Unified CCX Administration, navigate to System > Single Sign-On.

Note 

Use a log in name in the format username@FQDN to log in to the Unified CCX Administration.

Step 2

Click Identity Service Management.

The Cisco Identity Service Management window opens:

https://<Unified CCX server address>:8553/idsadmin
Step 3

Enter your user name, and then click Next.

Step 4

Enter your password, and then click Sign In.

The Cisco Identity Service Management page opens, showing the Nodes, Settings, and Clients icons in the left pane.
Step 5

Click Nodes.

The Nodes page opens to the overall Node level view and identifies which nodes are in service. The page also provides the SAML Certificate Expiry details for each node, indicating when the certificate is due to expire. The node Status options are Not Configured, In Service, Partial Service, and Out of Service. Click a status to see more information. The star to the right of one of the Node names identifies the node that is the primary publisher.
Step 6

Click Settings.

Step 7

Click IdS Trust.

Step 8

To begin the Cisco IdS trust relationship setup between the Cisco IdS and the IdP, click Download Metadata File to download the file from the Cisco IdS Server.

Step 9

Click Next.

Step 10

To upload the trusted metadata file from your IdP, browse to locate the file.

The Upload IdP Metadata page opens and includes the path to the IdP. When the file upload finishes, you receive a notification message. The metadata exchange is now complete, and the trust relationship is in place.
Step 11

Click Next.

The Test SSO Setup page opens.
Step 12

Click Test SSO Setup.

A message appears telling you that the Cisco IdS configuration has succeeded.
Step 13

Click Settings.

Step 14

Click Security.

Step 15

Click Tokens.

Enter the duration for the following settings:

  • Refresh Token Expiry -- The default value is 10 hours. The minimum value is 2 hours. The maximum is 24 hours.

  • Authorization Code Expiry -- The default value is 1 minute, which is also the minimum. The maximum is 10 minutes.

  • Access Token Expiry -- The default value is 60 minutes. The minimum value is 5 minutes. The maximum is 120 minutes.

Step 16

Set the Encrypt Token (optional); the default setting is On.

Step 17

Click Save.

Step 18

Click Keys and Certificates.

The Generate Keys and SAML Certificate page opens and allows you to:

  • Regenerate the Encryption/Signature key by clicking Regenerate. A message appears to say that the Token Registration is successful and advises you to restart the system to complete the configuration.

  • Regenerate the SAML Certificate by clicking Regenerate. A message appears to say that the SAML certificate regeneration is successful.

Step 19

Click Save.

Step 20

Click Clients.

The Clients page identifies the existing Cisco IdS clients, providing the client name, the client ID, and a redirect URL. To search for a particular client, click the Search icon above the list of names and type the client's name.
Step 21

To add a client:

  1. Click New.

  2. Enter the client's name.

  3. Enter the Redirect URL. To add more than one URL, click the plus icon.

  4. Click Add (or click Clear and then click the X to close the page without adding the client).

Step 22

To edit or delete a client, highlight the client row and click the ellipses under Actions. Then:

  • Click Edit to edit the client's name, ID, or redirect URL. On the Edit Client page, make changes and click Save (or click Clear and then click the X to close the page without saving edits).

  • Click Delete to delete the client.

Step 23

Click Settings.

Step 24

From the Settings page, click Troubleshooting to perform some optional troubleshooting.

Step 25

Set the local log level by choosing from Error, Warning, Info (the default), Debug, or Trace.

Step 26

To receive errors in Syslog format, enter the name of the Remote Syslog Server in the Host (Optional) field.

Step 27

Click Save.

You can now:

  • Register components with the Cisco IdS.

  • Enable (or disable) SSO for the entire deployment.

Establish Trust Relationship for Cisco IdS

To enable applications to use Cisco Identity Service (Cisco IdS) for Single Sign-On, perform the metadata exchange between the Cisco IdS and the Identity Provider (IdP).

  • Download the SAML SP Metadata file, sp.xml, on the Cisco IdS publisher primary node.

    1. Open Identity Service Management by doing either of the following:

      • Open the Identity Service Management window: https://<Unified CCX server address>:8553/idsadmin.

      • In Unified CCX Administration, navigate to System > Single Sign-On and click Identity Service Management.

    2. On the Settings > IdS Trust tab, download the SAML SP Metadata file, sp.xml.

  • Download the Identity Provider Metadata file, federationmetadata.xml, from the IdP. For example,

    1. For AD FS, download the Identity Provider Metadata file from the IdP at the location:

      https://<ADFSServer FQDN>/federationmetadata/2007-06/federationmetadata.xml.

    2. On the Identity Service Management page, upload the Identity Provider Metadata file that was downloaded in the previous step.

The SAML SSO uses trust authentication certificates to exchange authentication and authorization details between the IdP (such as AD FS) and the Cisco IdS. This secures the communication between the servers.


Note

  • Cisco IdS supports SAML self-signed certificates for authentication.

  • If the IdP certificates are automatically rolled-over, manually renewed, or updated by the administrator, then re-establish the trust relationship between the IdS and the IdP.

Configure an Identity Provider

To support SSO for the contact center solution, configure an Identity Provider (IdP) that is compliant with the Security Assertion Markup Language 2.0 (SAML v2) Oasis standard. The IdP stores user profiles and provides authentication services to the contact center solution.

This section provides details on the qualified Identity Providers (IdPs) and the reference links to configure the IdPs.

Qualified Identity Providers

If you use any Identity Provider (IdP) outside of the listed IdPs in the table below, Cisco IdS supports the IdP as long as the IdP is SAML 2.0 compliant and meets the following requirements described in the subsequent SAML Request and Response sections:

  • SAML Request Attributes

  • Expectations from SAML Response

Qualified Identity Providers

Version

Microsoft AD FS (Active Directory Federation Services)

2.0, 2.1, 3.0, and 4.0

PingFederate

8.2.2.0

OpenAM

10.0.1

Shibboleth

3.3.0

F5

13.0

To configure the qualified Identity Providers (IdPs), see the following references for:

SAML Request Attributes

  • SAML request supports the following SAML 2.0 bindings: HTTP-POST binding

  • NameIDFormat in SAML request must be urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • SAML request can be signed using SHA-128 or SHA-256 as per the value configured in the system. 


<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
       ID="s25f4fb66688cf429e430034f4cceac00b6124570d" Version="2.0"
       IssueInstant="2018-10-29T10:01:39Z" Destination="https://win-adfs30-151.uccxteam.com/adfs/ls/"
       ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
       AssertionConsumerServiceURL="https://ccxssodemo1.cisco.com:8553/ids/saml/response">
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">ccxssodemo1.cisco.com</saml:Issuer>
    <samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
           Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
           SPNameQualifier="ccxssodemo1.cisco.com" AllowCreate="true"></samlp:NameIDPolicy>
</samlp:AuthnRequest>

Expectations from SAML Response

The following are the expectations from SAML Response:

  • The entire SAML response (message and assertion) is signed or only the message is signed but not the SAML assertion alone is signed.

  • SAML Assertion must not be encrypted.

  • SAML response must be signed using SHA-128 or SHA-256 as per the value configured in the system.

  • NameIDFormat in SAML response must be urn:oasis:names:tc:SAML:2.0:named-format:transient.

  • uid and user_principal attributes should be present in SAML assertion in the AttributeStatement section.

    The "uid" attribute value must be the user Id using which users log in to Cisco contact centre applications that are SSO enabled and the "user_principal" attribute value must be in uid@domain format. 


<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" Destination="https://ids-ssp-node.cisco.com:8553/ids/saml/response"
    ID="_6a309495-d3c2-4a28-b8e3-289f8f5355bd" InResponseTo="s21c84ba20862f573f5daec121c305ba6aac877843"
    IssueInstant="2017-08-10T13:20:26.556Z" Version="2.0">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://ADFSServer.cisco.com/adfs/services/trust
    </Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
            <ds:Reference URI="#_6a309495-d3c2-4a28-b8e3-289f8f5355bd">
            ..........
            </ds:Reference>
        </ds:SignedInfo>
        ..........
        ..........
     </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_df3bdbcf-a225-4e97-b00a-a199bdda3d2c"
        IssueInstant="2017-08-10T13:20:26.556Z" Version="2.0">
        <Issuer>http://ADFSServer.cisco.com/adfs/services/trust</Issuer>
        .............
  
        .............
            <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                NameQualifier="http://ADFSSserver.cisco.com/adfs/services/trust"
                SPNameQualifier="ids-ssp-node.cisco.com">CISCO\Admin121</NameID>
            <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <SubjectConfirmationData
                    InResponseTo="s21c84ba20862f573f5daec121c305ba6aac877843"
                    NotOnOrAfter="2017-08-10T13:25:26.556Z"
                    Recipient="https://ids-ssp-node.cisco.com:8553/ids/saml/response" />
            </SubjectConfirmation>
        </Subject>
        <Conditions NotBefore="2017-08-10T13:20:26.556Z"
            NotOnOrAfter="2017-08-10T14:20:26.556Z">
            <AudienceRestriction>
                <Audience>ids-ssp-node.cisco.com</Audience>
            </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
            <Attribute Name="user_principal">
                <AttributeValue>Admin121@cisco.com</AttributeValue>
            </Attribute>
            <Attribute Name="uid">
                <AttributeValue>Admin121</AttributeValue>
            </Attribute>
        </AttributeStatement>
        <AuthnStatement AuthnInstant="2017-08-10T13:18:12.086Z"
            SessionIndex="_df3bdbcf-a225-4e97-b00a-a199bdda3d2c">
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>