Guest

Cisco Packaged Contact Center Enterprise Features Guide Release 11.5(1)

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco Packaged Contact Center Enterprise Features Guide Release 11.5(1)

Chapter Title

Single Sign-On

Results

Updated:
February 7, 2017

Chapter: Single Sign-On

Single Sign-On

Single Sign-On

Single sign-on (SSO) is an authentication and authorization process. (Authentication proves you are the user you say that you are, and authorization verifies that you are allowed to do what you are trying to do.) SSO allows users to sign in to one application and then securely access other authorized applications without a prompt 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 user directory and enforce password policies for all users consistently.

SSO is an optional feature whose implementation requires you to enable the HTTPS protocol across the enterprise solution.

You can choose from three different single sign-on modes when making a decision about implementing single sign-on:

  • SSO - Enable all agents and supervisors in the deployment for SSO.

  • Hybrid - Enable agents and supervisors selectively in the deployment for SSO. This mode allows you to phase in the migration of agents from a non-SSO deployment to an SSO deployment and enable SSO for local PGs. The mode is also useful if you have third-party applications that don't support SSO, and some agents and supervisors must be SSO-disabled to log into those applications.

  • Non-SSO - Continue to use existing Active Directory-based and local authentication, without SSO.

SSO uses Security Assertion Markup Language (SAML) to exchange authentication and authorization details between an identity provider (IdP) and an identity service (IdS). The IdP authenticates based on user credentials, and the IdS provides authorization between the IdP and applications. The IdP issues SAML assertions, which are packages of security information transferred from the IdP 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 digitally signed to ensure their authenticity.

The IdS generates an authentication request (also known as a SAML request) and directs it to the IdP. SAML does not specify the method of authentication at the IdP. It may use a username and password or other form of authentication, including multifactor authentication. A directory service such as LDAP or AD that allows a user to sign in with a username and a password is a typical source of authentication tokens at an IdP.

Prerequisites

The Identity Provider must support Security Assertion Markup Language (SAML) 2.0. See the Compatibility Matrix for your contact center solution at http:/​/​docwiki.cisco.com/​wiki/​Compatibility_​Matrixes_​for_​Contact_​Center_​Solutions for details.

Contact Center Enterprise Reference Design Support for Single Sign-On

Packaged CCE supports single sign-on for the 2000 Agent reference design.

Coresidency of Cisco Identity Service by Reference Design

Reference Design

Packaged CCE Solution

2000 agent

Cisco IdS is coresident with Unified Intelligence Center and Live Data on a single VM.

Single Sign-On Support and Limitations

Note the following points related to SSO support:

  • To support SSO, enable the HTTPS protocol across the enterprise solution.

  • SSO supports agents and supervisors only. SSO support is not available for administrators in this release.

  • In the 12,000 Agent Reference Design, a maximum of 4,000 agents use SSO at one time.

  • SSO supports multiple domains with federated trusts.

Note the following limitations related to SSO support:

  • SSO support is not available for third-party Automatic Call Distributors (ACDs), the Unified CCE System PG, the Media Routing (MR) PG, or the Voice Response Unit (VRU) PG.

  • The SSO feature does not support Cisco Finesse IP Phone Agent (FIPPA).

Single Sign-On Log Out

For a complete logout from all applications, sign out of the applications and close the browser window. In a Windows desktop, log out of the Windows account. In a Mac desktop, quit the browser application.


Note

Users enabled for single sign-on are at risk of having their accounts misused by others if the browser is not closed completely. If the browser is left open, a different user can access the application from the browser page without entering credentials.

Single Sign-On Flow

Single sign-on (SSO) configuration by an administrator follows this flow:

  1. Install Release 11.0(1).

  2. Install Release 11.5(1).

  3. Install the Cisco Identity Service (Cisco IdS).

    For Packaged CCE deployments, the Cisco IdS is installed as a service on the Unified Intelligence Center VMs.

  4. Install and configure the Identity Provider (IdP).

  5. Configure System Inventory.

  6. Configure the Cisco IdS.

  7. Register and test SSO-compatible components with the Cisco IdS.

  8. Choose the SSO mode.

  9. Enable multiple users at once for SSO by using the SSO migration tool, or enable users one at time by using the configuration tools.

Configure an Identity Provider (IdP)

To support SSO for the contact center solution, you must 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.

For a current list of supported Identity Provider products and versions, refer to the Compatibility Matrix for your contact center solution at http:/​/​docwiki.cisco.com/​wiki/​Compatibility_​Matrixes_​for_​Contact_​Center_​Solutions.

This section provides sample configuration information for Microsoft AD FS.

Follow this sequence of tasks to configure the Identity Provider.

Sequence

Task

1

Install and Configure Active Directory Federation Services

2

Set Authentication Type. See Authentication Types.

3

Establish Trust Relationship

4

Enable Signed SAML Assertions

5

Optionally Customize the AD FS Sign-In Page in Windows Server 2012 R2 to Allow User ID

Install and Configure Active Directory Federation Services

Follow Microsoft instructions and recommendations to install Microsoft Active Directory Federation Services (AD FS).

For example, see Active Directory Federation Services Overview at https:/​/​technet.microsoft.com/​en-us/​library/​hh831502(v=ws.11).aspx


Note

The certificate trust between the IdP and the Cisco Identity Service (Cisco IdS) requires SHA-1. (Certificate trust between Cisco IdS and the application browsers uses SHA-256.)

Authentication Types

Cisco Identity Service requires the Identity Provider to provide form-based authentication.

Establish Trust Relationship

Before You Begin

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://<Cisco IdS server address>:8553/idsadmin.

      • In Unified CCE 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.

    1. 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.

Procedure
    Step 1   In AD FS, be sure that the default Authentication Type is set to Forms. (Cisco Identity Service requires the Identity Provider to provide form-based authentication.) See the Microsoft AD FS documentation for details.
    Step 2   In AD FS server click, Start -> All Programs -> Administrative Tools -> AD FS Management.
    Step 3   Right-click AD FS -> Trust Relationships -> Relying Party Trust.
    Step 4   From the menu, choose Add Relying Party Trust to launch the Add Relying Party Trust Wizard.
    Step 5   In the Select Data Source step, choose the option Import data about the relying party from a file.
    Step 6   Browse to the sp.xml file that you downloaded from Cisco Identity Server and complete the import to establish the relying party trust.
    Step 7   Select the step Specify Display Name, and add a significant name you can use to identify the Relying Party Trust.
    Step 8   In AD FS in Windows Server 2012 R, in the Step Configure Multi-factor Authentication Now, select the option I do not want to configure multi-factor authentication settings for the relying party at this time.

    This step does not appear in AD FS 2.0 or 2.1. Continue with the next step.

    Step 9   In the Step Choose Issuance Authorization Rules, select the option Permit all users to access this relying party and click Next.
    Step 10   Click Next again to finish adding the relying party.
    Step 11   Right-click on the Relying Party Trust and click Properties. Select the Identifiers tab.
    Step 12   On the Identifiers tab, Set Display name to the name you specified when creating the Relying Party Trust, and set the Relying party identifier to the fully qualified hostname of the Cisco Identity Server from which sp.xml was downloaded.
    Step 13   Still in Properties, select the Advanced tab.
    Step 14   Select secure hash algorithm as SHA-1 and then click OK.
    Note    In the following steps, you configure two claim rules to specify the claims that are sent from AD FS to Cisco Identity Service as part of a successful SAML assertion:

    • A claim rule with the following custom claims, as AttributeStatements, in the assertion:

      • uid - Identifies the authenticated user in the claim sent to the applications.

      • user_principal - Identifies the authentication realm of the user in the assertion sent to Cisco Identity Service.

    • A second claim rule that is a NameID custom claim rule specifying the fully qualified domain name of the AD FS server and the Cisco IdS server.

    Follow the steps to configure these rules.

    Step 15   In Relying Party Trusts, right-click on the Relying Party Trust you created, and click Edit Claim Rules.
    Step 16   Follow these steps to add a rule with Send LDAP Attributes as Claims as the Claim rule template.
    1. In the Issuance Transform Rules tab, click Add Rule.
    2. In the Step Choose Rule Type, select the claim rule template Send LDAP Attributes as Claims and click Next.
    3. In the Configure Claim Rule step, in the Claim rule name field, enter NameID.
    4. Set the Attribute store drop-down to Active Directory.
    5. Set the table Mapping of LDAP attributes to outgoing claim types to the appropriate LDAP Attributes and the corresponding Outgoing Claim Type for the type of user identifier you are using:

      • When the identifier is stored as a SAM-Account-Name attribute:

        1. Select an LDAP Attributeof SAM-Account-Name, and set the corresponding Outgoing Claim Type to uid (lowercase).

        2. Select a second LDAP Attribute of User-Principal-Name and set the corresponding Outgoing Claim Type to user_principal (lowercase).

      • When the identifier is a UPN:

        1. Select an LDAP Attributeof User-Principal-Name, and set the corresponding Outgoing Claim Type to uid (lowercase).

        2. Select a second LDAP Attribute of User-Principal-Name and set the corresponding Outgoing Claim Type to user_principal (lowercase).

    Step 17   Follow these steps to add a second rule with the template custom claim rule.
    1. Select Add Rule on the Edit Claim Rules window.
    2. Select Send Claims Using Custom Rule.
    3. Set the name of rule to the fully qualified domain name (FQDN) of the Cisco Identity Server publisher (primary) node.
    4. Add the following rule text: 
      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] =>
 issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
 Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,
 Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =
 "urn:oasis:names:tc:SAML:2.0:nameid-format:transient",
 Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] =
 "http://<AD FS Server FQDN>/adfs/services/trust",
 Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] =
 "<fully qualified domain name of Cisco IdS>");
    5. Edit the script as follows:

      • Replace <AD FS Server FQDN> to match exactly (including case) the AD FS server FQDN (fully qualified domain name.)

      • Replace <fully qualified domain name of Cisco IdS> to match exactly (including case) the Cisco Identity Server FQDN.

    Step 18   Click OK.

    Enable Signed SAML Assertions

    Enable Signed SAML Assertions for the Relying Party Trust (Cisco Identity Service).

    Procedure
      Step 1   Click Start and type powershell in the Search field to display the Windows Powershell icon.
      Step 2   Right-click on the Windows Powershell program icon and select Run as administrator
      Note   

      All PowerShell commands in this procedure must be run in Administrator mode.

      Step 3   Run the command, Set-ADFSRelyingPartyTrust -TargetName <Relying Party Trust Display Name> -SamlResponseSignature "MessageAndAssertion".
      Note   

      Set <Relying Party Trust Display Name> to exactly match (including case) the Identifier tab of the Relying Party Trust properties.

      Optionally Customize the AD FS Sign-In Page in Windows Server 2012 R2 to Allow User ID

      By default, the sign-in page presented to SSO users by AD FS in Windows Server 2012 R2 requires a username that is a UPN. Usually this is an email format, for example, user@cisco.com. If your contact center solution is in a single domain, you can modify the sign-in page to allow your users to provide a simple User ID that does not include a domain name as part of the user name.

      There are several methods you can use to customize the AD FS sign-in page. Look in the Microsoft AD FS in Windows Server 2012 R2 documentation for details and procedures to configure alternate login IDs and customize the AD FS sign-in pages.

      The following procedure is an example of one solution.

      Procedure
        Step 1   In the AD FS Relying Party Trust, change the NameID claim rule to map the chosen LDAP attribute to uid.
        Step 2   Click the Windows Start control and type powershell in the Search field to display the Windows Powershell icon.
        Step 3   Right-click on the Windows Powershell program icon and select Run as administrator

        All PowerShell commands in this procedure must be run in Administrator mode.

        Step 4   To allow sign-ins to AD FS using the sAMAccountName, run the following Powershell command:

        Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID sAMAccountName -LookupForests myDomain.com

        In the LookupForests parameter, replace myDomain.com with the forest DNS that your users belong to.

        Step 5   Run the following commands to export a theme:

        mkdir C:\themeExport-AdfsWebTheme –Name default –DirectoryPath c:\theme

        Step 6   Edit onload.js in C:\theme\script and add the following code at the bottom of the file. This code changes the theme so that the AD FS sign-in page does not require a domain name or an ampersand, "@", in the username. 
        // Update the placeholder text to not include the domain
var userNameInput = document.getElementById("userNameInput");
if (userNameInput) {
 userNameInput.setAttribute("placeholder", "Username");
}
        // Override submitLoginRequest to not have the "@" check
Login.submitLoginRequest = function () {
 var u = new InputUtil();
 var e = new LoginErrors();
 var userName = document.getElementById(Login.userNameInput);
 var password = document.getElementById(Login.passwordInput);
 if (!userName.value) {
  u.setError(userName, e.userNameFormatError);
  return false;
 }
 if (!password.value) {
  u.setError(password, e.passwordEmpty);
  return false;
 }
 document.forms['loginForm'].submit();
 return false;
};
        Step 7   In Windows PowerShell, run the following commands to update the theme and make it active:

        Set-AdfsWebTheme -TargetName custom -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="c:\theme\script\onload.js"}

        Set-AdfsWebConfig -ActiveThemeName custom

        Set Up the System Inventory for Single Sign-On

        Packaged CCE automatically associates the Unified CCE AW-HDS-DDS, Unified Intelligence Center, and Finesse with a default Cisco Identity Service (Cisco IdS). However, if you have an External HDS in your deployment, you must manually associate it with a default Cisco IdS.

        Procedure
          Step 1   In Unified CCE Administration, navigate to System > Deployment.
          Step 2   Click the pencil icon for the External HDS. The Edit Machine popup window opens.
          Step 3   Click the Search icon next to Default Identity Service. The Select Identity Service popup window opens.
          Step 4   Enter the machine name for the Cisco IdS in the Search field or choose the Cisco IdS from the list.
          Step 5   Click Save.

          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.


          Note

          If you are working with a Cisco IdS cluster, perform these steps on the Cisco IdS primary publisher node.

          Be sure that the Principal AW is configured and functional before using the System > Single Sign-On tool in Unified CCE Administration.

          Procedure
            Step 1   In Unified CCE Administration, navigate to System > Single Sign-On.
            Note   

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

            Step 2   Click Identity Service Management.

            The Cisco Identity Service Management window opens:

            https://<Cisco IdS 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 Add Client.
            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.

            Register Components and Set Single Sign-On Mode

            If you add any SSO-compatible machines to the System Inventory after you register components with the Cisco IdS, those machines are registered automatically.

            Before You Begin

            • Configure the Cisco Identity Service (Cisco IdS)

            • Disable popup blockers. This is necessary to see all test results correctly.

            • If you are using Internet Explorer, verify that it is not in Compatibility Mode and that you are using the AW's fully qualified domain name to access CCE Administration (for example, https://<FQDN>.com/cceadmin).

            Procedure
              Step 1   In Unified CCE Administration, navigate to System > Single Sign-On.
              Step 2   Click the Register button to register all SSO-compatible components with the Cisco IdS.

              The component status table displays the registration status of each component.

              If a component fails to register, correct the error and click Retry.

              Step 3   Click the Test button. When the new browser tab opens, you may be prompted to accept a certificate. In order for the page to load, accept any certificates. Then, when presented with a log in dialog, log in as a user with SSO credentials.

              The test process verifies that each component has been configured correctly to reach the Identity Provider, and that the Cisco IdS successfully generates access tokens. Each component that you are setting up for SSO is tested.

              The component status table displays the status of testing each component.

              If a test is unsuccessful, correct the error, and then click Test again.

              Test results are not saved. If you refresh the page, run the test again before enabling SSO.

              Step 4   Select the SSO mode for the system from the Set Mode drop-down menu:

              • Non-SSO: This mode disables SSO for all agents and supervisors. Users log in using existing Active Directory-based local authentication.

              • Hybrid: This mode allows you to enable agents and supervisors selectively for SSO.

              • SSO: This mode enables SSO for all agents and supervisors.

              The component status table displays the status of setting the SSO mode on each component.

              If the SSO mode fails to be set on a component, correct the error, and then select the mode again.

              Migration Considerations Before Enabling Single Sign-On

              Administrator User and Single Sign-On in Unified Intelligence Center

              During installation, Cisco Unified Intelligence Center creates an administrator user. This user is not enabled for SSO, as the user is known only to Unified Intelligence Center.

              When you enable SSO, this administrator user is no longer able to log in to the Unified Intelligence Center and perform administrative tasks. These tasks include configuring datasources and setting permissions for other users, for example. To avoid this situation, perform the following steps before enabling SSO.

              1. Create a new SSO user who has the same roles and permissions as those of the administrator user.

              2. Log in to the CLI.

              3. Run the following command:

                utils cuic user make-admin username

              in which the user name is the complete name of the new user, including the authenticator prefix as shown on the Unified Intelligence Center User List page.

              The command, when executed, provides all the roles to the new user and copies all permissions from the administrator user to this new user.


              Note

              • The administrator's group memberships are not copied to the new user by this CLI command and must be manually updated. The new user, now a Security Administrator, can set up the group memberships.

              • For any entity (for example, reports or report definitions), if this new user’s permissions provide higher privileges than the administrator, the privileges are left intact. The privileges are not overwritten by the execution of this CLI command.

              Browser Settings and Single Sign-On

              If you have enabled single sign-on and are using Chrome or Firefox, verify that the browser options are set as shown in the following table. These settings specify that you do not want a new session of the browser to reopen tabs from a previous session. No changes are required for Internet Explorer.

              Browser

              Browser options to verify when using SSO

              Chrome

              1. Open a Chrome browser session.

              2. Click the Customize and control Google Chrome icon.

              3. Click Settings.

              4. In the On startup section of the Settings page, verify that the Open the New Tab page option is selected.

              Firefox

              1. Open a Firefox browser session.

              2. Click the Open menu icon.

              3. Click Options.

              4. In the Startup section of the General page, verify that either the home page or a blank page is chosen in the When Firefox starts drop-down list.

              Migrate Agents and Supervisors to Single Sign-On Accounts

              Important:

              Be aware that this release does not provide support for disabling SSO once it is enabled.

              Customers electing global hybrid mode to incrementally add SSO-enabled users may subsequently move to global enablement, or global enablement may be configured directly. However, the transition of hybrid mode to global off, of per-agent disablement while in hybrid mode, or of switching global on to global off is not supported at this time.

              Customers who attempt to disable SSO after enabling it may experience user account inconsistencies, such as cleared (pre-SSO) passwords, invalid passwords, and Cisco Unified Intelligence Center reporting issues for supervisor accounts introduced after SSO was enabled. For this reason, be sure to back up Logger databases using the Microsoft SQL Server Backup and Restore utility.

              Contact the Cisco TAC for questions or assistance.

              If you are enabling SSO in an existing deployment, you can set the SSO state to hybrid to support a mix of SSO and non-SSO users. In hybrid mode, you can enable agents and supervisors selectively for SSO making it possible for you to transition your system to SSO in phases.

              Use the procedures in this section to migrate groups of agents and supervisors to SSO accounts using the SSO Migration content file in the Unified CCE Administration Bulk Jobs tool. You use the Administration Bulk Jobs tool to download a content file containing records for agents and supervisors who have not migrated to SSO accounts. You modify the content file locally to specify SSO usernames for the existing agents and supervisors. Using the Administration Bulk Jobs tool again, you upload the content file to update the agents and supervisors usernames; the users are also automatically enabled for SSO.

              If you do not want to migrate a user, delete the row for that user.

              Important:

              While the Finesse agent is logged in, changing the login name prevents the agent from answering or placing calls. In this situation, the agent can still change between ready and not_ready state. This affects all active agents, independent of whether SSO is enabled or disabled. Should you need to modify a login name, do so only after the corresponding agent is logged out. Note too that SSO migration (moving a non-SSO agent to be SSO-enabled, by either hybrid mode or global SSO mode) should not be done when the agent is logged in.

              Procedure
                Step 1   In Unified CCE Administration, navigate to Manage > Bulk Jobs.
                Step 2   Download the SSO Migration bulk job content file.
                1. Click Templates.

                  The Download Templates popup window opens.

                2. Click the Download icon for the SSO Migration template.
                3. Click OK to close the Download Templates popup window.
                Step 3   Enter the SSO usernames in the SSO Migration content file.
                1. Open the template in Microsoft Excel. Update the newUserName field for the agents and supervisors whom you want to migrate to SSO accounts.

                  The content file for the SSO migration bulk job contains these fields:

                  Field

                  Required?

                  Description

                  userName

                  Yes

                  The user's non-SSO username.

                  firstName

                  No

                  The user's first name.

                  lastName

                  No

                  The user's last name.

                  newUserName

                  No

                  The user's new SSO username. Enter up to 255 ASCII characters.

                  If you want to enable a user for SSO, but keep the current username, leave newUserName blank, or copy the value of userName into newUserName.

                2. Save the populated file locally.
                Step 4   Create a bulk job to update the usernames in the database.
                1. Click New to open the New Bulk Job window.
                2. Enter an optional Description for the job.
                3. In the Content File field, browse to the SSO Migration content file you completed.

                  The content file is validated before the bulk job is created.

                4. Click Save.

                  The new bulk job appears in the list of bulk jobs. Optionally, click the bulk job to review the details and status for the bulk job. You can also download the log file for a bulk job.

                  When the bulk job completes, the agents and supervisors are enabled for SSO and their usernames are updated. You can open an individual user's record in the Agent tool in Unified CCE Administration to see the changes.

                What to Do Next

                After all of the agents and supervisors in your deployment are migrated to SSO accounts, you can enable SSO globally in your deployment.

                Single Sign-On and the Agent Tool

                When the global SSO-enabled setting is Hybrid, you can use the Unified CCE Administration Agent Tool to enable agents individually for single sign-on.

                In the tool, check the Single Sign-On check box to require a selected agent to sign in with SSO authentication. For supervisors and for agents with single sign-on (SSO) enabled, the username is the user's Active Directory or SSO account username.


                Note

                The check box is disabled when the global SSO mode is set to SSO or non-SSO.

                To update agent records in bulk, use the Bulk Jobs Agent content file.

                Related Documentation

                Refer to the following documents and other resources for more details about single sign-on.

                See this information

                Located here

                For these details

                Solution Design Guide for Cisco Packaged Contact Center Enterprise

                		 http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​packaged-contact-center-enterprise/​tsd-products-support-series-home.html

                Design considerations and guidelines for deploying the Cisco Packaged CCE system.

                Virtualization for Cisco Packaged CCE DocWiki

                		 http:/​/​docwiki-dev.cisco.com/​wiki/​Virtualization_​for_​Cisco_​Packaged_​CCE

                Information about deploying Packaged CCE (including single sign-on) on VMware.

                Release Notes for Cisco Packaged Contact Center Enterprise Solution

                		 http:/​/​www.cisco.com/​c/​en/​us/​support/​customer-collaboration/​packaged-contact-center-enterprise/​products-release-notes-list.html

                New features and changes for this release of the Packaged CCE solution.

                Cisco Packaged CCE Software Compatibility Matrix DocWiki

                		 http:/​/​docwiki-dev.cisco.com/​wiki/​Compatibility_​Matrix_​for_​Packaged_​CCE

                Packaged CCE Release 11.5(1) requirements.

                Unified CCE Administration Single Sign-On Tool

                Online help

                Changes to support single sign-on.

                System Inventory Tool

                This guide.

                Information related to adding SSO-compatible components to the inventory.

                Was this Document Helpful?

                FeedbackFeedback

                Contact Cisco

                Related Support Community Discussions