Types d’authentification
S'APPLIQUE À : SDK v4
Dans Bot Framework, il existe deux grandes catégories d'authentification : l'authentification du bot et l'authentification de l'utilisateur. Chacun a un jeton associé pour autoriser l'accès aux ressources sécurisées. La figure suivante montre les éléments impliqués dans l'authentification du bot et de l'utilisateur.
Dans cette figure :
- Host Platform est la plateforme d'hébergement de bot. Il peut s'agir d'Azure ou de n'importe quelle plateforme d'hébergement que vous avez choisie.
- Bot Connector Service facilite la communication entre un bot et un canal. Il convertit les messages reçus des canaux en objets d'activité et les envoie au point de terminaison de messagerie du bot. De même, il convertit les objets d'activité reçus du bot en messages compréhensibles par le canal et les envoie à ce dernier.
- L'adaptateur bot est l'adaptateur Bot Framework par défaut. Elle effectue les actions suivantes :
- Convertit la charge utile JSON en objet d'activité.
- Crée un contexte de tour et ajoute l'objet d'activité à celui-ci.
- Exécute l'intergiciel, le cas échéant.
- Transmet le contexte du tour au bot.
Remarque
Lorsqu'un adaptateur de canal personnalisé est utilisé, l'adaptateur lui-même effectue les tâches que le Bot Connector Service et l'adaptateur de canal par défaut effectuent. Il fournit également le mécanisme d'authentification pour l'API web hook correspondante. Par exemple, consultez Connexion d'un bot à Slack à l'aide de l'adaptateur Slack.
Authentification du bot
Un bot est identifié par son MicrosoftAppID et MicrosoftAppPassword, qui sont conservés dans les fichiers de paramètres du bot (appsettings.json .NET), .env (JavaScript), config.py (Python)) ou dans un gestionnaire de secrets ou de clés.
Pour plus d'informations, consultez MicrosoftAppID et MicrosoftAppPassword.
Lorsque vous enregistrez un bot dans le portail Azure, Azure crée une application d'inscription Microsoft Entra ID. Si vous utilisez l'interface CLI Bot Framework, vous devez effectuer une étape spécifique pour créer l'inscription Microsoft Entra ID. Cette inscription a un ID d'application (MicrosoftAppID) et une clé secrète client (MicrosoftAppPassword). Azure utilise ces valeurs pour générer un jeton avec lequel le bot peut accéder aux ressources sécurisées.
Lorsqu'un canal envoie une requête à un bot, à travers le service Bot Connector, il spécifie un jeton dans l'en-tête d'autorisation de la demande. Le bot authentifie les appels du service Bot Connector en vérifiant l'authenticité du jeton.
Lorsque le bot envoie une requête à un canal à travers le service Bot Connector, il doit spécifier le jeton dans l'en-tête d'autorisation de la requête. Toutes les requêtes doivent inclure le jeton d'accès, qui est vérifié par le service Bot Connector pour autoriser la requête.
Les opérations décrites sont effectuées automatiquement par le kit de développement logiciel (SDK) Bot Framework.
Pour plus d'informations, consultez la documentation de l'API REST sur l'authentification des requêtes du service Bot Connector auprès de votre bot et l'authentification des requêtes de votre bot auprès du service Bot Connector.
Canaux
En règle générale, les canaux communiquent avec un bot à travers le service Bot Connector, de sorte que les principes d'authentification précédents s'appliquent généralement. Certains canaux et caractéristiques ont des considérations d'authentification uniques.
Direct Line
Outre les canaux pris en charge standard, une application cliente peut communiquer avec un bot à l'aide du canal Direct Line.
L'application cliente authentifie les requêtes auprès de Direct Line (version 3.0) soit en utilisant un secret obtenu à partir de la page de configuration du canal Direct Line dans le portail Azure, soit, de préférence, en utilisant un jeton obtenu au moment de l'exécution. Le secret ou le jeton est spécifié dans l'en-tête d'autorisation de chaque requête.
Important
Lorsque vous utilisez l'authentification Azure AI Bot Service avec Chat Web, vous devez tenir compte de certaines considérations importantes en matière de sécurité. Pour plus d’informations, consultez la section Considérations relatives à la sécurité de l’article sur l’authentification REST.
Pour plus d'informations, consultez Conserver votre secret masqué, l'échanger contre un jeton et générer l'incorporation.
Chat Web
Le Chat Web dispose de deux implémentations : le canal et le contrôle.
- Lorsque vous inscrivez un bot auprès d'Azure, le canal Chat Web est automatiquement configuré pour permettre de tester le bot. Pour plus d'informations, consultez Connecter un bot à Chat Web..
- Vous pouvez utiliser un contrôle Chat Web avec le canal Direct Line pour fournir l'accès à un bot dans une application cliente. Pour plus d'informations sur la commande, consultez Chat Web pour Bot Framework.
Compétences
Une compétence et un consommateur de compétences sont deux bots distincts, chacun avec son propre ID d'application et mot de passe.
- Le consommateur peut transférer des activités utilisateur à une compétence et transférer les réponses de la compétence à l'utilisateur.
- Pour la compétence, le consommateur de compétences agit comme un canal. Le consommateur dispose d'un point de terminaison hôte de compétence qui agit en tant qu'URL de service à laquelle la compétence envoie des activités.
- Pour plus d'informations sur les compétences, consultez la vue d'ensemble des compétences.
L’authentification au niveau du service est gérée par le service Bot Connector. Le framework utilise des jetons de porteur et des ID d’application de bot pour vérifier l’identité de chaque bot.
Important
Pour ce faire, tous les bots (le consommateur de compétences et toutes les compétences qu'il consomme) doivent disposer d'identifiants d'application valides.
Validation des revendications
En plus de ce niveau d'authentification de base, vous devez ajouter un validateur de réclamations à la configuration d'authentification de la compétence et du consommateur de compétence. Les revendications sont évaluées après l’en-tête d’authentification. Ce processus permet à chaque bot de restreindre les autres bots dont il accepte les activités.
Pour obtenir des exemples de validation des réclamations, découvrez comment implémenter une compétence et implémenter un consommateur de compétences.
Émulateur de Bot Framework
Bot Framework Emulator a son propre flux d'authentification et ses propres jetons. L'émulateur a son propre canal et un serveur prédéfini.
Authentification utilisateur
Il arrive qu'un bot doive accéder à des ressources en ligne sécurisées au nom de l'utilisateur. Pour ce faire, le bot doit être autorisé. En effet, pour effectuer certaines opérations comme vérifier ses e-mails, le statut d'un vol ou passer une commande, le bot doit appeler un service externe comme Microsoft Graph, GitHub ou le service REST d'une entreprise. OAuth est utilisé pour authentifier l'utilisateur et autoriser le bot à agir en son nom.
Remarque
Deux macro-étapes sont nécessaires pour qu'un bot accède aux ressources d'un utilisateur.
- Authentification. Processus de vérification de l'identité de l'utilisateur.
- Autorisation. Processus consistant à vérifier que le bot peut accéder aux ressources de l'utilisateur.
Si la première étape est réussie, un jeton basé sur les informations d'identification de l'utilisateur est émis. Dans la deuxième étape, le bot utilise le jeton pour accéder aux ressources de l'utilisateur.
Pour plus d'informations, consultez Authentification de l'utilisateur.
Fournisseurs d’identité
Un fournisseur d’identité authentifie des identités client ou utilisateur et délivre des jetons de sécurité consommables. Il fournit l’authentification utilisateur en tant que service. Les applications clientes telles que les applications web délèguent l’authentification à un fournisseur d’identité approuvé.
Un bot peut utiliser un fournisseur d'identité approuvé pour :
- activer les caractéristiques d'authentification unique (SSO), ce qui lui permet d'accéder à plusieurs ressources sécurisées.
- Se connecter aux ressources de cloud computing au nom d'un utilisateur, ce qui réduit la nécessité pour les utilisateurs de s'authentifier à nouveau.
Remarque
Le jeton émis pendant l'authentification du bot n'est pas le même jeton émis lors de l'authentification de l'utilisateur. La première est utilisée pour établir une communication sécurisée entre un bot, des canaux et, finalement, des applications clientes. La deuxième est utilisée pour autoriser le bot à accéder à une ressource sécurisée pour le compte de l'utilisateur.
Notez que les canaux fournissent leur propre authentification, distincte, pour permettre à un utilisateur de se connecter au canal.
Pour plus d'informations sur la façon dont les bots peuvent utiliser des fournisseurs d'identité pour accéder aux ressources pour le compte d'un utilisateur, consultez les fournisseurs d'identité.