Intégrez l'instrument de tiers avec la finesse sur le mode SSO

Introduction

Ce document décrit ce qui est nécessaire pour l'intégration des instruments d'un tiers avec la finesse tandis que le système est sur le mode simple de l'ouverture de session (SSO). Un exemple est également donné pour NON le mode SSO.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Cisco Finesse
• SSO
• Instruments de tiers de finesse

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Version 11.6 de Cisco Finesse
• SSO
• instrument de tiers
• service de REPOS de tiers.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Ce sont les mesures initiales tandis que les tentatives d'agent d'ouvrir une session et authentifier avec SSO ou NONSSO.

la deuxième étape décrit quels besoins d'être considéré après l'authentification réussie en cas de SSO et de NONSSO.

1. Au moment de la procédure de connexion de bureau, la finesse détecte le mode authentique de système (SSO/NONSSO) et basé sur le mode authentique, Loginpage approprié est affiché. Les utilisateurs voient la page de connexion d'IDP en cas de mode SSO et la page de connexion de finesse en cas de mode NONSSO.

2. Après l'authentification réussie, toutes les demandes sont authentifiées ont basé sur le mode authentique de système. Pour des déploiements SSO, toutes les demandes à la finesse portent le jeton d'accès en tant qu'élément de l'en-tête de demande. Le jeton est validé contre le serveur d'IDP pour l'authentification réussie. Cependant, pour des demandes aux services Web de tiers, l'en-tête authentique doit être placée basée sur le modèle d'authentification mis en application par le service Web de tiers.  En cas de déploiement NONSSO, toutes les demandes portent l'en-tête authentique de base avec le nom d'utilisateur et mot de passe encodé par base64. Toutes les demandes dans ce cas sont validées contre la base de données locale de finesse.

Explication de modèle de base d'interaction pour le mode SSO

Cette image affiche le modèle de base de l'interaction entre un instrument de tiers, la finesse, les ID, et un service de REPOS de tiers, quand le système est en mode SSO.

Image

Voici la description pour chaque étape affichée dans l'image.

1. L'agent/superviseur accède à l'URL d'appareil de bureau de finesse. (Par exemple : https://finesse.com:8445/desktop)
2. La finesse détecte que l'authentication mode est SSO et réoriente le navigateur aux ID.
3. Le navigateur envoie la réorientation autorisent la demande aux ID. En ce moment, les ID les détecte, que l'utilisateur ait un jeton valide d'accès ou pas. Si l'utilisateur n'a pas un jeton valide d'accès, des redirect to d'ID le fournisseur d'identité (IDP).
4. Si la demande est réorientée à l'IDP, l'IDP fournit la page de connexion pour authentifier l'utilisateur.
5. L'assertion SAML de l'IDP est envoyée aux ID, qui réoriente de nouveau à l'appareil de bureau de finesse.
6. Le navigateur fait un OBTENIR de la page d'appareil de bureau de finesse.
7. La finesse obtient le jeton d'accès des ID avec le code authentique SAML.
8. L'appareil de bureau obtient le jeton d'accès à utiliser pour authentifier le REPOS ultérieur API.
9. l'instrument de tiers charge dans l'appareil de bureau et appelle un REPOS API de tiers avec le jeton d'accès (support) dans l'authentique-en-tête.
10. le service de REPOS de tiers valide le jeton avec des ID.
11. la réponse de REPOS de tiers est renvoyée à l'instrument.

Configuration de gadgets.io.makerequest pour le mode SSO et NONSSO

Étape 1. Pour des appels du REPOS API de finesse faits par l'intermédiaire de la fête, les instruments doivent ajouter l'en-tête d'autorisation de « support » dans des en-têtes gadgets.io.makeRequest.

Étape 2. Les instruments doivent faire des appels indigènes gadgets.io.makeRequest pour toutes les demandes de REPOS, l'en-tête d'autorisation doit être placés à l'intérieur des params de demande.

Pour NON des déploiements SSO, c'est l'en-tête authentique.

"Basic " + base64.encode(username : password) 

Pour des déploiements SSO, c'est l'en-tête authentique.

"Bearer "  + access_token

Le jeton d'Access peut être récupéré de l'objet finesse.gadget.Config.

 access_token = finesse.gadget.Config.authToken 

Le nouveau mustl d'en-tête d'autorisation soit ajouté aux params de demande.    

 params[gadgets.io.RequestParameters.HEADERS].Authorization = "Basic " + base64.encode(username : password);
 params[gadgets.io.RequestParameters.HEADERS].Authorization = "Bearer "  + access_token;

Étape 3. Une méthode de service getAuthHeaderString a été des utilitaires intérieurs ajoutés. Utilitaires. Cette méthode de service prend l'objet de config comme argument et renvoie la chaîne d'en-tête d'autorisation. Les instruments peuvent se servir de cette méthode de service pour placer l'en-tête d'autorisation dans des params de demande.  

params[gadgets.io.RequestParameters.HEADERS].Authorization= finesse.utilities.Utilities.getAuthHeaderString(finesse.gadget.config);

Remarque: Pour des demandes API aux services Web de tiers, l'en-tête authentique doit être placée basée sur le modèle d'authentification mis en application par le service Web de tiers. Les développeurs d'instrument ont la liberté pour utiliser l'authentification basée par jeton de base authentique ou de support, ou n'importe quel autre mécanisme d'authentification de leur choix.