Tipi di autenticazione
SI APPLICA A: SDK v4
In Bot Framework esistono due ampie categorie di autenticazione: autenticazione del bot e autenticazione utente. Ognuno ha un token associato per consentire l'accesso alle risorse protette. La figura seguente illustra gli elementi coinvolti sia nell'autenticazione bot che nell'autenticazione utente.
In questa figura:
- Host Platform è la piattaforma di hosting del bot. Può essere Azure o qualsiasi piattaforma host scelta.
- Il servizio bot Connessione or facilita la comunicazione tra un bot e un canale. Converte i messaggi ricevuti dai canali in oggetti attività e li invia all'endpoint di messaggistica del bot. Analogamente, converte gli oggetti attività ricevuti dal bot in messaggi riconosciuti dal canale e li invia al canale.
- Bot Adapter è l'adattatore Bot Framework predefinito. Esso:
- Converte il payload JSON in un oggetto attività.
- Crea un contesto di turno e lo aggiunge all'oggetto attività.
- Esegue il middleware, se presente.
- Inoltra il contesto del turno al bot.
Nota
Quando viene usata una scheda canale personalizzata, l'adapter stesso esegue le attività eseguite dal servizio Bot Connessione or e dall'adapter Bot predefinito. Fornisce inoltre il meccanismo di autenticazione per l'API web hook correlata. Per un esempio, vedere Connessione un bot a Slack usando l'adattatore Slack.
Autenticazione del bot
Un bot viene identificato da MicrosoftAppID e MicrosoftAppPassword, che vengono mantenuti all'interno dei file di impostazioni del bot ( (appsettings.json.NET), .env (JavaScript), config.py (Python)) o in un segreto o in un gestore delle chiavi.
Per altre informazioni, vedere MicrosoftAppID e MicrosoftAppPassword.
Quando si registra un bot nel portale di Azure, Azure crea un'applicazione di registrazione dell'ID Entra di Microsoft. Se si usa l'interfaccia della riga di comando di Bot Framework, è necessario eseguire in modo specifico un passaggio per creare la registrazione di Microsoft Entra ID. Questa registrazione ha un ID applicazione (MicrosoftAppID) e un segreto client (MicrosoftAppPassword). Azure usa questi valori per generare un token con cui il bot può accedere a risorse sicure.
Quando un canale invia una richiesta a un bot, tramite il servizio Bot Connessione or, specifica un token nell'intestazione Authorization della richiesta. Il bot autentica le chiamate dal servizio Bot Connessione or verificando l'autenticità del token.
Quando il bot invia una richiesta a un canale tramite il servizio Bot Connessione or, deve specificare il token nell'intestazione Authorization della richiesta. Tutte le richieste devono includere il token di accesso, verificato dal servizio Bot Connessione or per autorizzare la richiesta.
Le operazioni descritte vengono eseguite automaticamente da Bot Framework SDK.
Per altre informazioni, vedere la documentazione dell'API REST su come autenticare le richieste dal servizio Bot Connessione or al bot e autenticare le richieste dal bot al servizio Bot Connessione or.
Canali
In genere, i canali comunicano con un bot tramite il servizio Bot Connessione or, quindi si applicano in genere i principi di autenticazione precedenti. Alcuni canali e funzionalità hanno considerazioni di autenticazione univoche.
Direct Line
Oltre ai canali supportati standard, un'applicazione client può comunicare con un bot usando il canale Direct Line.
L'applicazione client autentica le richieste a Direct Line (versione 3.0) usando un segreto ottenuto dalla pagina di configurazione del canale Direct Line nella portale di Azure o, meglio, usando un token ottenuto in fase di esecuzione. Il segreto o il token viene specificato nell'intestazione Authorization di ogni richiesta.
Importante
Quando si usa l'autenticazione servizio Bot di Intelligenza artificiale di Azure con chat Web è necessario tenere presenti alcune importanti considerazioni sulla sicurezza. Per altre informazioni, vedere la sezione relativa alle considerazioni sulla sicurezza nell'articolo sull'autenticazione REST.
Per altre informazioni, vedere Mantenere nascosto il segreto, scambiare il segreto per un token e generare l'incorporamento.
Chat Web
Il chat Web ha due implementazioni: il canale e il controllo .
- Quando si registra un bot con Azure, il canale chat Web viene configurato automaticamente per consentire il test del bot. Per altre informazioni, vedere Connessione un bot per chat Web.
- È possibile usare un controllo chat Web con il canale Direct Line per fornire l'accesso a un bot in un'applicazione client. Per altre informazioni sul controllo, vedere Bot Framework chat Web.
Competenze
Una competenza e un consumer di competenze sono due bot distinti, ognuno con il proprio ID app e password.
- Il consumer può inoltrare le attività utente a una competenza e inoltrare le risposte della competenza all'utente.
- Per la competenza, il consumer di competenze funge da canale. Il consumer ha un endpoint host competenza che funge da URL del servizio a cui la competenza invia attività.
- Per altre informazioni sulle competenze, vedere la panoramica delle competenze.
L'autenticazione a livello di servizio è gestita da Bot Connector. Il framework usa i bearer token e gli ID applicazione del bot per verificare l'identità di ogni bot.
Importante
Questo richiede che tutti i bot (il consumer di competenze e le competenze usate) dispongano di credenziali dell'applicazione valide.
Convalida delle attestazioni
Oltre a questo livello di autenticazione di base, è necessario aggiungere un validator di attestazioni alla configurazione di autenticazione della competenza e del consumer di competenze. Le attestazioni vengono valutate dopo l'intestazione di autenticazione. Questo processo consente a ogni bot di limitare da quali altri bot accetterà le attività.
Per la convalida delle attestazioni di esempio, vedere come implementare una competenza e implementare un consumer di competenze.
Bot Framework Emulator
Bot Framework Emulator ha un proprio flusso di autenticazione e i propri token. L'emulatore ha un proprio canale e un server predefinito.
Autenticazione dell'utente
A volte, un bot deve accedere alle risorse online protette per conto dell'utente. A tale scopo, il bot deve essere autorizzato. Ciò è dovuto al fatto che per eseguire determinate operazioni, ad esempio controllare la posta elettronica, controllare lo stato dei voli o effettuare un ordine, il bot deve chiamare un servizio esterno, ad esempio Microsoft Graph, GitHub o il servizio REST di una società. OAuth viene usato per autenticare l'utente e autorizzare il bot.
Nota
Sono necessari due passaggi macro per consentire a un bot di accedere alle risorse di un utente.
- Autenticazione. Processo di verifica dell'identità dell'utente.
- Autorizzazione. Processo di verifica che il bot possa accedere alle risorse dell'utente.
Se il primo passaggio ha esito positivo, viene emesso un token basato sulle credenziali dell'utente. Nel secondo passaggio il bot usa il token per accedere alle risorse dell'utente.
Per altre informazioni, vedere Autenticazione utente.
Provider di identità
Un provider di identità autentica le identità di utenti o client e rilascia token di sicurezza utilizzabili. Offre l'autenticazione utente come servizio. Le applicazioni client, ad esempio le applicazioni Web, delegano l'autenticazione a un provider di identità attendibile.
Un bot può usare un provider di identità attendibile per:
- Abilitare le funzionalità di Single Sign-On (SSO), consentendo l'accesso a più risorse protette.
- Connessione alle risorse di cloud computing per conto di un utente, riducendo la necessità di autenticare nuovamente gli utenti.
Nota
Il token rilasciato durante l'autenticazione bot non è lo stesso token emesso durante l'autenticazione utente. Il primo viene usato per stabilire comunicazioni sicure tra bot, canali e, in ultima analisi, applicazioni client. Il secondo viene usato per autorizzare il bot ad accedere alle risorse protette per conto dell'utente.
Si noti che i canali forniscono la propria autenticazione utente separata per consentire a un utente di accedere al canale.