Configurer le fournisseur d'identité pour Cisco Identity Service afin d'activer l'authentification unique

Introduction

Ce document décrit la configuration du fournisseur d'identité (IdP) pour Cisco Identity Service (IdS) afin d'activer l'authentification unique (SSO).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Cisco Unified Contact Center Express (UCCX) version 11.5 ou Cisco Unified Contact Center Enterprise version 11.5 ou Packaged Contact Center Enterprise (PCCE) version 11.5, le cas échéant
• Microsoft Active Directory - Active Directory installé sur Windows Server
• Service de fédération Active Directory (ADFS) version 2.0/3.0

Remarque : ce document fait référence à UCCX dans les captures d'écran et les exemples, mais la configuration est similaire en ce qui concerne les ID Cisco (UCCX/UCCE/PCCE) et l'IDP.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Modèles de déploiement Cisco IdS

Product (produit)	Déploiement
UCCX	Coprésident
PCCE	Co-résident avec CUIC (Cisco Unified Intelligence Center) et LD (Live Data)
UCCE	Co-résident avec CUIC et LD pour les déploiements 2k. Autonome pour les déploiements 4K et 12K.

Présentation de SSO

Cisco fournit de nombreux services sous différentes formes et en tant qu'utilisateur final, vous ne souhaitez vous connecter qu'une seule fois pour accéder à tous les services Cisco. Si vous souhaitez rechercher et gérer des contacts à partir de l'une des applications et des périphériques Cisco, exploitez toutes les sources possibles (répertoire d'entreprise, Outlook, contacts mobiles, Facebook, LinkedIn, historique) et faites-les restituer de manière standard et cohérente afin de fournir les informations nécessaires pour connaître leur disponibilité et la meilleure façon de les contacter.

SSO avec SAML (Security Assertion Markup Language) cible cette exigence. SAML/SSO permet aux utilisateurs de se connecter à plusieurs périphériques et services via un compte commun et une identité d'autorisation appelée IdP. La fonctionnalité SSO est disponible dans UCCX/UCCE/PCCE 11.5 et versions ultérieures.

Présentation de la configuration

Configurer

Types d'authentification

Cisco IdS prend uniquement en charge l'authentification basée sur le formulaire des IdP.

Reportez-vous à ces articles MSDN afin d'apprendre comment activer l'authentification de formulaire dans ADFS.

• Pour ADFS 2.0, reportez-vous à cet article Microsoft TechNet,
  http://social.technet.microsoft.com/wiki/contents/articles/1600.ad-fs-2-0-how-to-change-the-local-authentication-type.aspx.
• Pour ADFS 3.0, reportez-vous à cet article Microsoft TechNet,
  https://learn.microsoft.com/en-us/archive/blogs/josrod/enabled-forms-based-authentication-in-adfs-3-0

Remarque : Cisco IdS 11.6 et versions ultérieures prennent en charge l'authentification Kerberos et l'authentification basée sur les formulaires. Pour que l'authentification Kerberos fonctionne, vous devez désactiver l'authentification basée sur les formulaires.

Établir une relation de confiance

Pour l'intégration et pour permettre aux applications d'utiliser les ID Cisco pour SSO, effectuez l'échange de métadonnées entre les IDs et les IDp.

• Télécharger le fichier de métadonnées SAML SP  sp.xml.
• Expéditeur Settings, accédez à IdS Trust sur la page Gestion des IDs.

• Téléchargez le fichier de métadonnées du fournisseur d'identités à partir du fournisseur d'identités à partir de l'URL :
  https://<ADFServer>/federationmetadata/2007-06/federationmetadata.xml

• Sur la page Gestion des IDs, téléchargez le fichier de métadonnées IdP téléchargé à l'étape précédente.

Il s'agit de la procédure permettant de télécharger les métadonnées IdS et d'ajouter des règles de revendication. Ceci est décrit pour ADFS 2.0 et 3.0.

ADFS 2.0

Étape 1. Dans le serveur ADFS, accédez à : Start > All Programs > Administrative Tools > ADFS 2.0 Management, comme l'illustre l'image :

Étape 2. Naviguez jusqu'à Add ADFS 2.0 > Trust Relationship > Relying Party Trust, comme l'illustre l'image :

Étape 3. Comme l'illustre l'image, choisissez l'option Import data about the relying party from a file.

Étape 4. Terminer l'établissement de l'approbation de la partie de confiance.

Étape 5. Dans les propriétés de l'approbation de la partie de confiance, sélectionnez Identifier s'affiche.

Étape 6. Définissez l'identificateur comme le nom d'hôte complet du serveur d'identité Cisco à partir duquel sp.xml est téléchargé.

Étape 7. Cliquez avec le bouton droit sur l'approbation de la partie de confiance, puis cliquez sur Edit Claim Rules.

Vous devez ajouter deux règles de revendication, l'une est lorsque les attributs LDAP (Lightweight Directory Access Protocol) sont mis en correspondance, tandis que la seconde est par le biais de règles de revendication personnalisées.

uid : cet attribut est nécessaire pour les applications afin d'identifier l'utilisateur authentifié.
user_principal : cet attribut est nécessaire pour les ID Cisco afin d'identifier le domaine de l'utilisateur authentifié.

Règle de revendication 1 :

Ajouter une règle par nom NameID du type (envoyer les valeurs de l'attribut LDAP sous forme de revendications) :

• Choisir le magasin d'attributs comme Active Directory
• Attribut Mapper LDAP User-Principal-Name par  user_principal (minuscules)
• Sélectionnez l'attribut LDAP qui doit être utilisé comme userId pour les utilisateurs de l'application afin de se connecter et de le mapper à uid (minuscules)

Exemple de configuration lorsque SamAccountName doit être utilisé comme ID d'utilisateur :

• Mapper l'attribut LDAP SamAccountName par  uid.
• Mapper l'attribut LDAP User-Principal-Name par  user_principal.

Exemple de configuration lorsque UPN doit être utilisé comme ID d'utilisateur :

• Mapper l'attribut LDAP User-Principal-Name par  uid.
• Mapper l'attribut LDAP User-Principal-Name par  user_principal.

Exemple de configuration lorsque PhoneNumber doit être utilisé comme ID d'utilisateur :

• Mapper l'attribut LDAP phoneNumber sur uid .
• Mapper l'attribut LDAP User-Principal-Name par  user_principal.

Remarque : vous devez vous assurer que l'attribut LDAP configuré pour l'ID utilisateur sur la synchronisation LDAP CUCM correspond à celui configuré comme attribut LDAP pour uid selon la règle de revendication ADFS NameID. Ceci est pour le bon fonctionnement du CUIC et de la connexion Finesse.

Remarque : ce document fait référence aux contraintes sur le nom de la règle de revendication et affiche des noms tels que NameID, Fully Qualified Domain Name (FQDN) d'UCCX, etc. Bien que les champs et les noms personnalisés puissent être applicables à diverses sections, les noms de règle de revendication et les noms d'affichage sont maintenus standard dans l'ensemble de la convention afin de maintenir la cohérence et de respecter les meilleures pratiques en matière de convention de dénomination.

Règle de revendication 2 :

• Ajoutez une autre règle de type « règle de revendication personnalisée » portant le nom « Nom d'hôte qualifié complet » de Cisco Identity Server et ajoutez ce texte de règle.
  
  

  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>");

  
  
• Dans le cluster Cisco Identity Server, tous les noms d'hôte pleinement qualifiés sont ceux du noeud principal ou du noeud éditeur Cisco Identity Server.
• Le <nom d'hôte complet de Cisco Identity Server> est sensible à la casse, il correspond donc exactement (casse incluse) au nom de domaine complet de Cisco Identity Server.
• Le <nom de domaine complet du serveur ADFS> est sensible à la casse, il correspond donc exactement (majuscules et minuscules incluses) au nom de domaine complet ADFS.

Étape 8. Cliquez avec le bouton droit sur l'approbation de la partie de confiance, puis cliquez sur Properties et sélectionnez l'onglet avancé, comme illustré dans l'image.

Étape 9. Comme l'illustre l'image, sélectionnez SHA-256 (Secure Hash Algorithm).

Étape 10. Cliquer OK.

ADFS 3.0

Étape 1. Dans le serveur ADFS, accédez à Server Manager > Tools > ADFS Management.

Étape 2. Naviguez jusqu'à ADFS > Trust Relationship > Relying Party Trust.

Étape 3. Sélectionnez l'option Import data about the relying party from a file.

Étape 4. Terminer l'établissement de l'approbation de la partie de confiance.

Étape 5. Dans les propriétés de l'approbation de la partie de confiance, sélectionnez Identifier s'affiche.

Étape 6. Définissez l'identificateur comme le nom d'hôte complet du serveur d'identité Cisco à partir duquel sp.xml est téléchargé.

Étape 7. Cliquez avec le bouton droit sur Confiance de la partie de confiance, puis cliquez sur Edit Claim Rules.

Vous devez ajouter deux règles de revendication, l'une est lorsque les attributs LDAP sont mis en correspondance, tandis que la seconde est par le biais de règles de revendication personnalisées.

uid : cet attribut est nécessaire pour que les applications puissent identifier l'utilisateur authentifié.
user_principal : cet attribut est nécessaire pour les ID Cisco afin d'identifier le domaine de l'utilisateur authentifié.

Règle de revendication 1 :

Ajouter une règle par nom NameID de type (envoyer les valeurs de l'attribut LDAP en tant que revendications) :

• Choisir le magasin d'attributs comme Active Directory
• Attribut Mapper LDAP User-Principal-Name par  user_principal (minuscules)
• Sélectionnez l'attribut LDAP qui doit être utilisé comme userId pour que les utilisateurs de l'application se connectent et le mappent à uid(minuscules)

Exemple de configuration lorsque SamAccountName doit être utilisé comme ID d'utilisateur :

• Mapper l'attribut LDAP SamAccountName par  uid.
• Mapper l'attribut LDAP User-Principal-Name par  user_principal.

Exemple de configuration lorsque l'UPN doit être utilisé comme ID d'utilisateur :

• Mapper l'attribut LDAP User-Principal-Name par  uid.
• Mapper l'attribut LDAP User-Principal-Name par  user_principal.

Exemple de configuration lorsque PhoneNumber doit être utilisé comme ID d'utilisateur :

• Mapper l'attribut LDAP telephoneNumber par  uid.
• Mapper l'attribut LDAP User-Principal-Name par  user_principal.

Remarque : vous devez vous assurer que l'attribut LDAP configuré pour l'ID utilisateur sur la synchronisation LDAP CUCM correspond à celui configuré comme attribut LDAP pour uid dans la règle de revendication ADFS NameID. Ceci est pour le bon fonctionnement de CUIC et Finesse login.

Remarque : ce document fait référence à des contraintes sur le nom de la règle de revendication et les noms d'affichage tels que NameID, FQDN d'UCCX, etc. Bien que les champs et les noms personnalisés puissent être applicables à diverses sections, les noms de règle de revendication et les noms d'affichage sont maintenus standard dans l'ensemble afin de maintenir la cohérence et de respecter les meilleures pratiques dans la convention d'attribution de noms.

Règle de revendication 2 :

• Ajoutez une autre règle de type « règle de revendication personnalisée » portant le nom « Nom d'hôte qualifié complet » de Cisco Identity Server et ajoutez ce texte de règle.
                                

  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>");

  
  
• Dans le cluster Cisco Identity Server, tous les noms d'hôte pleinement qualifiés sont ceux du noeud principal ou du noeud éditeur Cisco Identity Server.
• Le <nom d'hôte complet de Cisco Identity Server> est sensible à la casse, il correspond donc exactement (casse incluse) au nom de domaine complet de Cisco Identity Server.
• Le <nom de domaine complet du serveur ADFS> est sensible à la casse, il correspond donc exactement (majuscules et minuscules incluses) au nom de domaine complet ADFS.

Étape 8. Cliquez avec le bouton droit sur Confiance de la partie de confiance, puis cliquez sur Properties et sélectionnez l'option advanced s'affiche.

Étape 9. Comme l'illustre l'image, choisissez SHA comme SHA-256.

Étape 10. Cliquer OK.

Ces étapes sont obligatoires après l'étape 10.

Activer les assertions SAML signées pour l'approbation de la partie de confiance (ID Cisco)

Étape 1. Cliquer Start et entrez dans PowerShell afin d'ouvrir windows powershell.

Étape 2. Ajoutez CmdLet ADFS à PowerShell avec la commande Add-PSSnapin Microsoft.Adfs.Powershell.

Étape 3. Exécutez la commande, Set-ADFSRelyingPartyTrust -TargetName -SamlResponseSignature "MessageAndAssertion" .

          

Remarque : l'étape 2 n'est pas nécessaire si vous utilisez ADFS 3.0 car le CmdLet est déjà installé dans le cadre de l'ajout des rôles et des fonctionnalités.

Remarque : le  est sensible à la casse, de sorte qu'il correspond (majuscules et minuscules incluses) à ce qui est défini dans l'onglet Identificateur des propriétés Confiance de la partie de confiance.

Remarque : à partir de la version 12.0 d'UCCX, les ID Cisco prennent en charge SHA-256. L'approbation de la partie de confiance utilise SHA-256 pour signer la requête SAML et attend la même réponse de la part d'ADFS.

Pour une configuration multidomaine pour ADFS fédérés

Dans le cas de la fédération dans ADFS, où un ADFS dans un domaine particulier fournit une authentification SAML fédérée pour les utilisateurs dans d'autres domaines configurés, ces configurations supplémentaires sont nécessaires.

Pour cette section, le terme ADFS principal fait référence aux ADFS qui doivent être utilisés dans les ID. Le terme ADFS fédérés indique les ADFS dont les utilisateurs peuvent se connecter via des ID et qui sont donc les ADFS principaux.

Configuration ADFS fédérée

Dans chaque ADFS fédéré, l'approbation de la partie de confiance doit être créée pour l'ADFS principal et les règles de revendication configurées comme indiqué dans la section précédente.

Configuration ADFS principale

Pour le système ADFS principal, outre l'approbation de la partie de confiance pour les ID, cette configuration supplémentaire est nécessaire.

Ajouter Claim Provider Trust avec les ADFS pour lesquels la fédération doit être configurée.

Dans la demande d'indemnisation, assurez-vous que la Pass through or Filter an Incoming Claim les règles sont configurées avec l'option Passthrough de toutes les valeurs de revendication :

• ID du nom
• Sélectionnez Name ID dans la liste Incoming Claim Type tambour
• Choisir Transient comme option pour le format NameID entrant
• uid : il s'agit d'une revendication personnalisée. Entrez la valeur uid dans le champ Incoming Claim Type tambour
• user_principal : il s'agit d'une revendication personnalisée. Entrez la valeur user_principal dans le champ Incoming Claim Type tambour

Dans l'approbation de la partie de confiance pour les ID, ajoutez Pass though or Filter an Incoming Claim règles avec l'option Passthrough de toutes les valeurs de revendication.

• NomSousDomaineIDFrom
• Choisir un ID de nom Incoming Claim Type tambour
• Choisir Transient comme option pour le format NameID entrant
• uid : il s'agit d'une revendication personnalisée. Tapez l'uid de la valeur dans le champ Incoming Claim Type tambour
• user_principal : il s'agit d'une revendication personnalisée. Entrez la valeur user_principal dans le champ Incoming Claim Type tambour

Renversement automatique de certificat ADFS

La substitution automatique de certificat est prise en charge pour UCCX 11.6.1 et versions ultérieures. (La mise à niveau de la bibliothèque Fedlet vers la version 14.0 dans UCCX 11.6 a résolu ce problème.)

Authentification Kerberos (Authentification Windows intégrée)

L'authentification Windows intégrée (IWA) fournit un mécanisme d'authentification des utilisateurs, mais n'autorise pas la transmission des informations d'identification sur le réseau. Lorsque vous activez l'authentification Windows intégrée, elle fonctionne sur la base de tickets afin de permettre aux noeuds de communiquer sur un réseau non sécurisé afin de prouver leur identité les uns aux autres de manière sécurisée. Elle permet aux utilisateurs de se connecter à un domaine après s'être connectés à leurs ordinateurs Windows.

Remarque : l'authentification Kerberos est prise en charge uniquement à partir de la version 11.6 et ultérieure.

Les utilisateurs du domaine qui sont déjà connectés au contrôleur de domaine (DC) sont connectés de manière transparente aux clients SSO sans avoir à saisir à nouveau les informations d'identification. Pour les utilisateurs n'appartenant pas au domaine, IWA revient à NTLM (New Technology Local Area Network Manager) et la boîte de dialogue de connexion s'affiche. La qualification pour les IDs avec l'authentification IWA est effectuée avec Kerberos contre ADFS 3.0.

Étape 1. Ouvrez l'invite de commandes Windows et exécutez-la en tant qu'utilisateur Admin afin d'inscrire le service HTTP auprès de setspn commande  setspn -s http/ \ .

Étape 2. Désactivez l'authentification de formulaire et activez l'authentification Windows pour les sites intranet. Naviguez jusqu'à ADFS Management > Authentication Policies > Primary Authentication > Global Settings > Edit. Sous Intranet, assurez-vous que seule l'authentification Windows est cochée (décochez l'option Authentification par formulaire).

Configuration pour la prise en charge de Microsoft Internet Explorer pour IWA

Étape 1. Vérifiez les points suivants  Internet Explorer > Advanced > Enable Integrated Windows Authentication est cochée.

Étape 2. L'URL ADFS doit être ajoutée à Security > Intranet zones > Sites  (winadcom215.uccx116.com est l'URL ADFS).

Étape 3. Vérifiez les points suivants Internet Explorer > Security > Local Intranet > Security Settings > User Authentication - Logon  est configuré afin d'utiliser les informations d'identification de connexion pour les sites intranet.

Configuration requise pour la prise en charge de Mozilla Firefox pour IWA

Étape 1. Passez en mode de configuration pour Firefox. Ouvrez Firefox et entrez about:config  dans l'URL. Acceptez l'énoncé des risques.

Étape 2. Rechercher des ntlm  et activez l' network.automatic-ntlm-auth.allow-non-fqdn  et définissez-la sur true.

Étape 3. Définissez la network.automatic-ntlm-auth.trusted-uris  au domaine ou explicitement à l'URL ADFS.

Configuration requise pour la prise en charge de Google Chrome pour IWA

Google Chrome dans Windows utilise les paramètres d'Internet Explorer, donc configurez dans Internet Explorer Tools > Internet Options ou à partir du Panneau de configuration sous Internet Options dans la sous-catégorie Network and Internet.

Configuration supplémentaire pour SSO

Ce document décrit la configuration de l'aspect IdP pour SSO afin de l'intégrer avec les ID Cisco. Pour plus d'informations, reportez-vous aux guides de configuration de chaque produit :

• UCCX 
• UCCE
• PCCE

Vérifier

Cette procédure permet de déterminer si l'approbation de la partie de confiance est établie correctement entre les ID Cisco et le IDP.

• À partir du navigateur, entrez l’URL https://<ADFS_FQDN>/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=<IDS_FQDN>
• ADFS fournit le formulaire de connexion. Cette option est disponible lorsque la configuration mentionnée est correcte.
• Une fois l'authentification réussie, le navigateur doit rediriger vers https://<IDS_FQDN>:8553/ids/saml/response, et une page de liste de contrôle s'affiche.

Remarque : la page Liste de contrôle qui s'affiche dans le cadre du processus de vérification n'est pas une erreur, mais une confirmation que l'approbation est correctement établie.

Dépannage

Pour le dépannage, reportez-vous à 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 contournement/récupération SSO UCCX

• Administration de Cisco Unified CCX
• Facilité de maintenance de Cisco Unified CCX

Désactiver SSO

• GUI : Accédez à CCX Administration > Single Sign-On (SSO) > Disable.
• CLI : set authmode non_sso (cette commande doit désactiver SSO pour Pub et Sub - peut être exécutée à partir de l'un des noeuds UCCX en cas de cluster haute disponibilité).

Captures d'écran

Administration CCX - Non_SSO

Administration CCX - SSO activé

Connexion Finesse - Non-SSO

Connexion Finesse - SSO activé

CUIC - Non_SSO

CUIC - SSO activé