Configuración del proveedor de identidad para que Cisco Identity Service active SSO

Introducción

Este documento describe la configuración del proveedor de identidad (IdP) para Cisco Identity Service (IdS) para habilitar el inicio de sesión único (SSO).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cisco Unified Contact Center Express (UCCX) versión 11.5 o Cisco Unified Contact Center Enterprise versión 11.5 o Packaged Contact Center Enterprise (PCCE) versión 11.5, según corresponda
• Microsoft Active Directory: AD instalado en Windows Server
• Servicio de federación de Active Directory (ADFS) versión 2.0/3.0

Nota: Este documento hace referencia a UCCX en las capturas de pantalla y los ejemplos; sin embargo, la configuración es similar con respecto a los IdS de Cisco (UCCX/UCCE/PCCE) y el IdP.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Modelos de implementación de Cisco IdS

Producto	Implementación
UCCX	Copresidente
PCCE	Coresidente con CUIC (Cisco Unified Intelligence Center) y LD (Live Data)
UCCE	Coresidente con CUIC y LD para implementaciones 2k. Independiente para implementaciones de 4000 y 12 000.

Descripción general de SSO

Cisco proporciona muchos servicios de diferentes formas y, como usuario final, solo desea iniciar sesión una vez para tener acceso a todos los servicios de Cisco. Si desea buscar y administrar contactos de cualquiera de las aplicaciones y dispositivos de Cisco, aproveche todas las fuentes posibles (Directorio corporativo, Outlook, Contactos móviles, Facebook, LinkedIn, Historial) y hágalo representar de una manera estándar y coherente que proporcione la información necesaria para conocer su disponibilidad y la mejor manera de ponerse en contacto con ellos.

SSO con SAML (Security Assertion Markup Language, Lenguaje de marcado de aserción de seguridad) se dirige a este requisito. SAML/SSO proporciona la capacidad para que los usuarios inicien sesión en múltiples dispositivos y servicios a través de una cuenta común e identidad de autorización llamada IdP. La funcionalidad SSO está disponible en UCCX/UCCE/PCCE 11.5 en adelante.

Información general sobre configuración

Configurar

Tipos de Autenticación

Cisco IdS sólo admite la autenticación basada en formularios de IdPs.

Consulte estos artículos de MSDN para aprender a habilitar la autenticación de formularios en ADFS.

• Para ADFS 2.0 consulte este artículo de Microsoft TechNet,
  http://social.technet.microsoft.com/wiki/contents/articles/1600.ad-fs-2-0-how-to-change-the-local-authentication-type.aspx.
• Para ADFS 3.0 consulte este artículo de Microsoft TechNet,
  https://learn.microsoft.com/en-us/archive/blogs/josrod/enabled-forms-based-authentication-in-adfs-3-0

Nota: Cisco IdS 11.6 y versiones posteriores admiten la autenticación Kerberos y basada en formularios. Para que la autenticación Kerberos funcione, debe deshabilitar la autenticación basada en formularios.

Establecer una relación de confianza

Para la onboarding y para permitir que las aplicaciones utilicen los IdS de Cisco para SSO, realice el intercambio de metadatos entre los IdS y el IdP.

• Descargar el archivo de metadatos SP de SAML  sp.xml.
• Desde Settings, desplácese hasta IdS Trust de la página Gestión de IdS.

• Descargue el archivo de metadatos IdP desde el IdP desde la URL:
  https://<ADFSServer>/federationmetadata/2007-06/federationmetadata.xml

• En la página Gestión de IdS, cargue el archivo de metadatos de IdP que se descargó en el paso anterior.

Este es el procedimiento para cargar los metadatos de IdS y agregar reglas de reclamación. Esto se describe para ADFS 2.0 y 3.0.

ADFS 2.0

Paso 1. En el servidor ADFS, desplácese hasta, Start > All Programs > Administrative Tools > ADFS 2.0 Management, como se muestra en la imagen:

Paso 2. Desplácese hasta Add ADFS 2.0 > Trust Relationship > Relying Party Trust, como se muestra en la imagen:

Paso 3. Como se muestra en la imagen, elija la opción Import data about the relying party from a file.

Paso 4. Completar el establecimiento del Fideicomiso de Confianza.

Paso 5. En las propiedades de Confianza del usuario de confianza, elija la Identifier ficha.

Paso 6. Establezca el identificador como el nombre de host completamente calificado del servidor Cisco Identity Server desde el que sp.xml se descarga.

Paso 7. Haga clic con el botón secundario en Confianza del usuario de confianza y, a continuación, haga clic en Edit Claim Rules.

Debe agregar dos reglas de notificación: una es cuando los atributos LDAP (protocolo ligero de acceso a directorios) coinciden, mientras que la segunda es a través de reglas de notificación personalizadas.

uid - Este atributo es necesario para que las aplicaciones puedan identificar al usuario autenticado.
user_principal - Este atributo es necesario por los IdS de Cisco para identificar el rango del usuario autenticado.

Regla de reclamación 1:

Agregar una regla por nombre NameID del tipo (enviar los valores del atributo LDAP como notificaciones):

• Elegir almacén de atributos como Active Directory
• Atributo LDAP de mapa User-Principal-Name a user_principal (minúscula)
• Elija el atributo LDAP que se debe utilizar como userId para que los usuarios de la aplicación puedan iniciar sesión y asignarlo a uid (minúscula)

Ejemplo de configuración cuando SamAccountName se utilizará como ID de usuario:

• Asigne el atributo LDAP SamAccountName a uid.
• Asigne el atributo LDAP User-Principal-Name a user_principal.

Ejemplo de configuración cuando UPN se debe utilizar como ID de usuario:

• Asigne el atributo LDAP User-Principal-Name a uid.
• Asigne el atributo LDAP User-Principal-Name a user_principal.

Ejemplo de configuración cuando PhoneNumber se debe utilizar como ID de usuario:

• Asigne el atributo LDAP phoneNumber a uid .
• Asigne el atributo LDAP User-Principal-Name a user_principal.

Nota: Debe asegurarse de que el atributo LDAP configurado para el ID de usuario en la sincronización LDAP de CUCM coincida con el atributo LDAP configurado para uid en la regla de reclamación de ADFS NameID. Esto es para el correcto funcionamiento del inicio de sesión de CUIC y Finesse.

Nota: este documento hace referencia a las restricciones del nombre de regla de reclamación y muestra nombres como NameID, Fully Qualified Domain Name (FQDN) de UCCX, etc. Aunque los campos y nombres personalizados se pueden aplicar en varias secciones, los nombres de regla de reclamación y los nombres para mostrar se mantienen estándar para mantener la coherencia y para las prácticas recomendadas en la convención de nomenclatura.

Regla de reclamación 2:

• Agregue otra regla de tipo regla de notificación personalizada con el nombre Full Qualified Hostname of Cisco Identity Server (Nombre de host completamente calificado de Cisco Identity Server) y agregue este texto de regla.
  
  

  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://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

  
  
• En el clúster de Cisco Identity Server, todos los nombres de host completamente calificados son los del nodo principal o editor de Cisco Identity Server.
• El <nombre de host totalmente calificado de Cisco Identity Server> distingue entre mayúsculas y minúsculas, por lo que coincide exactamente (mayúsculas y minúsculas incluidas) con el FQDN de Cisco Identity Server.
• El <FQDN del servidor ADFS> distingue entre mayúsculas y minúsculas, por lo que coincide exactamente (mayúsculas y minúsculas incluidas) con el FQDN de ADFS.

Paso 8. Haga clic con el botón secundario en Confianza del usuario de confianza y, a continuación, haga clic en Properties y seleccione la ficha advanced (avanzado), como se muestra en la imagen.

Paso 9. Como se muestra en la imagen, elija el algoritmo hash seguro (SHA) como SHA-256.

Paso 10. Haga clic en OK.

ADFS 3.0

Paso 1. En el servidor ADFS, desplácese hasta Server Manager > Tools > ADFS Management.

Paso 2. Desplácese hasta ADFS > Trust Relationship > Relying Party Trust.

Paso 3. Elija la opción Import data about the relying party from a file.

Paso 4. Completar el establecimiento del Fideicomiso de Confianza.

Paso 5. En las propiedades de Confianza del usuario de confianza, elija el Identifier ficha.

Paso 6. Establezca el identificador como el nombre de host completamente calificado del servidor Cisco Identity Server desde el que sp.xml se descarga.

Paso 7. Haga clic con el botón secundario en Confianza del usuario de confianza y, a continuación, haga clic en Edit Claim Rules.

Debe agregar dos reglas de notificación: una es cuando los atributos LDAP coinciden, mientras que la segunda es a través de reglas de notificación personalizadas.

uid: este atributo es necesario para que las aplicaciones identifiquen al usuario autenticado.
user_principal - Este atributo es necesario por los IdS de Cisco para identificar el rango del usuario autenticado.

Regla de reclamación 1:

Agregar una regla por nombre NameID del tipo (enviar los valores del atributo LDAP como notificaciones):

• Elegir almacén de atributos como Active Directory
• Atributo LDAP de mapa User-Principal-Name a user_principal (minúscula)
• Elija el atributo LDAP que se debe utilizar como userId para que los usuarios de la aplicación inicien sesión y la asignen a uid(minúscula)

Ejemplo de configuración cuando SamAccountName se utilizará como ID de usuario:

• Asigne el atributo LDAP SamAccountName a uid.
• Asigne el atributo LDAP User-Principal-Name a user_principal.

Ejemplo de configuración cuando se debe utilizar UPN como ID de usuario:

• Asigne el atributo LDAP User-Principal-Name a uid.
• Asigne el atributo LDAP User-Principal-Name a user_principal.

Ejemplo de configuración cuando PhoneNumber se debe utilizar como ID de usuario:

• Asigne el atributo LDAP telephoneNumber a uid.
• Asigne el atributo LDAP User-Principal-Name a user_principal.

Nota: Debe asegurarse de que el atributo LDAP configurado para el ID de usuario en la sincronización LDAP de CUCM coincida con el atributo LDAP configurado para uid en la regla de reclamación de ADFS NameID. Esto es para la función adecuada de inicio de sesión de CUIC y Finesse.

Nota: este documento hace referencia a restricciones en el nombre de regla de reclamación y nombres para mostrar como NameID, FQDN de UCCX, etc. Aunque los campos y nombres personalizados pueden ser aplicables en varias secciones, los nombres de regla de reclamación y los nombres para mostrar se mantienen de forma estándar para mantener la coherencia y para las prácticas recomendadas en la convención de nomenclatura.

Regla de reclamación 2:

• Agregue otra regla de tipo regla de notificación personalizada con el nombre Full Qualified Hostname of Cisco Identity Server (Nombre de host completamente calificado de Cisco Identity Server) y agregue este texto de regla.
                                

  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://<ADFS Server FQDN>/ADFS/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "<fully qualified hostname of IdS/UCCX>");

  
  
• En el clúster de Cisco Identity Server, todos los nombres de host completamente calificados son los del nodo principal o editor de Cisco Identity Server.
• El <nombre de host totalmente calificado de Cisco Identity Server> distingue entre mayúsculas y minúsculas, por lo que coincide exactamente (mayúsculas y minúsculas incluidas) con el FQDN de Cisco Identity Server.
• El <FQDN del servidor ADFS> distingue entre mayúsculas y minúsculas, por lo que coincide exactamente (mayúsculas y minúsculas incluidas) con el FQDN de ADFS.

Paso 8. Haga clic con el botón secundario en Confianza del usuario de confianza y, a continuación, haga clic en Properties y seleccione la advanced ficha.

Paso 9. Como se muestra en la imagen, elija SHA como SHA-256.

Paso 10. Haga clic en OK.

Estos pasos son obligatorios después del paso 10.

Habilitar aserciones SAML firmadas para la confianza del usuario de confianza (Id. de Cisco)

Paso 1. Haga clic en Start e ingrese PowerShell para abrir windows powershell.

Paso 2. Agregar CmdLet de ADFS a PowerShell con el comando Add-PSSnapin Microsoft.Adfs.Powershell.

Paso 3. Ejecute el comando, Set-ADFSRelyingPartyTrust -TargetName -SamlResponseSignature "MessageAndAssertion" .

          

Nota: el paso 2 no es necesario si utiliza ADFS 3.0, ya que CmdLet ya está instalado como parte de la adición de los roles y características.

Nota: El  distingue entre mayúsculas y minúsculas, por lo que coincide (mayúsculas incluidas) con lo establecido en la ficha Identificador de las propiedades Confianza del usuario de confianza.

Nota: a partir de la versión 12.0 de UCCX, los ID de Cisco admiten SHA-256. El fideicomiso de usuario de confianza utiliza SHA-256 para firmar la solicitud SAML y espera la misma respuesta de ADFS.

Para una configuración de varios dominios para ADFS federados

En el caso de la federación en ADFS, donde un ADFS en un dominio determinado proporciona autenticación SAML federada para los usuarios de otros dominios configurados, se necesitan configuraciones adicionales.

Para esta sección, el término ADFS primario se refiere a los ADFS que se deben utilizar en IdS. El término ADFS federado indica aquellos ADFS, cuyos usuarios pueden iniciar sesión a través de IdS y, por lo tanto, son los ADFS primarios.

Configuración de ADFS federado

En cada uno de los ADFS federados, se debe crear el fideicomiso de usuario de confianza para el ADFS principal y las reglas de reclamación configuradas como se mencionó en la sección anterior.

Configuración de ADFS principal

Para el ADFS principal, además de la confianza de usuario de confianza para IdS, se necesita esta configuración adicional.

Agregar Claim Provider Trust con el ADFS en el que debe configurarse la federación.

En la Claim Provider Trust, asegúrese de que el Pass through or Filter an Incoming Claim las reglas se configuran con el paso a través de todos los valores de notificación como la opción:

• ID del nombre
• Seleccione ID de nombre en la Incoming Claim Type buzón
• Elegir Transient como opción para el formato de ID de nombre entrante
• uid: es una notificación personalizada. Introduzca el valor uid en el campo Incoming Claim Type buzón
• user_principal: se trata de una notificación personalizada. Escriba el valor user_principal en el campo Incoming Claim Type buzón

En Confianza de usuario de confianza para IdS, agregue Pass though or Filter an Incoming Claim reglas con paso a través de todos los valores de notificación como opción.

• NombreIDFromSubdominio
• Seleccione ID de nombre en Incoming Claim Type buzón
• Elegir Transient como opción para el formato de ID de nombre entrante
• uid: es una notificación personalizada. Escriba el valor uid en el Incoming Claim Type buzón
• user_principal: se trata de una notificación personalizada. Escriba el valor user_principal en el campo Incoming Claim Type buzón

Renovación automática de certificados de ADFS

La sustitución automática de certificados es compatible con UCCX 11.6.1 y versiones posteriores. (La actualización de la biblioteca Fedlet a la versión 14.0 en UCCX 11.6 resolvió este problema.)

Autenticación Kerberos (autenticación de Windows integrada)

La autenticación de Windows integrada (IWA) proporciona un mecanismo para la autenticación de los usuarios, pero no permite transmitir las credenciales a través de la red. Cuando se habilita la autenticación de Windows integrada, funciona sobre la base de tickets para permitir que los nodos se comuniquen a través de una red no segura para probar su identidad entre sí de una manera segura. Permite a los usuarios iniciar sesión en un dominio después de iniciar sesión en sus equipos con Windows.

Nota: la autenticación Kerberos sólo se admite a partir de la versión 11.6 y posteriores.

Los usuarios de dominio que ya han iniciado sesión en el controlador de dominio (DC) inician sesión sin problemas en los clientes de SSO sin necesidad de volver a introducir las credenciales. Para los usuarios que no son de dominio, IWA recurre a New Technology Local Area Network Manager (NTLM) y aparece el cuadro de diálogo de inicio de sesión. La calificación para IdS con autenticación IWA se realiza con Kerberos contra ADFS 3.0.

Paso 1. Abra el símbolo del sistema de Windows y ejecútelo como un usuario administrador para registrar el servicio HTTP con el setspn comando setspn -s http/ \ .

Paso 2. Deshabilite la autenticación de formularios y habilite la autenticación de Windows para sitios de intranet. Desplácese hasta ADFS Management > Authentication Policies > Primary Authentication > Global Settings > Edit. En Intranet, asegúrese de que sólo está activada la autenticación de Windows (desactive la autenticación de formularios).

Configuración de Microsoft Internet Explorer para compatibilidad con IWA

Paso 1. Asegúrese de lo siguiente Internet Explorer > Advanced > Enable Integrated Windows Authentication está activado.

Paso 2. La URL de ADFS se debe agregar a Security > Intranet zones > Sites  (winadcom215.uccx116.com es la URL de ADFS).

Paso 3. Asegúrese de lo siguienteInternet Explorer > Security > Local Intranet > Security Settings > User Authentication - Logon  está configurado para utilizar las credenciales de inicio de sesión para sitios de intranet.

Configuración necesaria para Mozilla Firefox para compatibilidad con IWA

Paso 1. Ingresa al modo de configuración para Firefox. Abra Firefox e introduzca about:config  en la URL. Acepte la declaración de riesgos.

Paso 2. Buscar por ntlm  y habilitar el network.automatic-ntlm-auth.allow-non-fqdn  y establézcalo en true.

Paso 3. Establezca el network.automatic-ntlm-auth.trusted-uris  al dominio o explícitamente a la URL de ADFS.

Configuración requerida para Google Chrome para soporte de IWA

Google Chrome en Windows utiliza la configuración de Internet Explorer, por lo que se debe configurar en Internet Explorer Tools > Internet Options o desde el Panel de control en Internet Options dentro de la subcategoría Network and Internet.

Configuración adicional para SSO

Este documento describe la configuración del aspecto IdP para SSO para integrarse con los IdS de Cisco. Para obtener más información, consulte las guías de configuración de productos individuales:

• UCCX
• UCCE
• PCCE

Verificación

Este procedimiento se utiliza para determinar si la Confianza del Usuario de Confianza se establece correctamente entre los IdS de Cisco y los IDP.

• En el explorador, introduzca la URL https://<ADFS_FQDN>/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=<IDS_FQDN>
• ADFS proporciona el formulario de inicio de sesión. Esta opción está disponible cuando la configuración mencionada es correcta.
• Si la autenticación es correcta, el navegador debe redirigir a https://<IDS_FQDN>:8553/ids/saml/response, y aparecerá una página de lista de comprobación.

Nota: La página Lista de comprobación que aparece como parte del proceso de verificación no es un error, sino una confirmación de que la confianza se ha establecido correctamente.

Troubleshoot

Para la resolución de problemas, consulte https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/200662-ADFS-IdS-Troubleshooting-and-Common-Prob.html.

URL de recuperación/omisión de SSO de UCCX

• Administración de Cisco Unified CCX
• Mantenimiento de Cisco Unified CCX

Desactivar SSO

• GUI: acceda a CCX Administration > Single Sign-On (SSO) > Disable.
• CLI: set authmode non_sso (este comando debe inhabilitar SSO para Pub y Sub - puede ejecutarse desde cualquiera de los nodos UCCX en caso de un clúster de alta disponibilidad (HA)).

Capturas de pantalla

Administración de CCX: Non_SSO

Administración de CCX: SSO habilitado

Inicio de sesión en Finesse - No SSO

Inicio de sesión Finesse: SSO habilitado

CUIC: Non_SSO

CUIC: SSO habilitado