Autentiseringstyper

GÄLLER FÖR: SDK v4

I Bot Framework finns det två breda autentiseringskategorier: robotautentisering och användarautentisering. Var och en har en associerad token för att tillåta åtkomst till skyddade resurser. Följande bild visar de element som ingår i både robot- och användarautentisering.

I den här bilden:

• Värdplattform är robotens värdplattform. Det kan vara Azure eller vilken värdplattform du vill.
• Bot Connector Service underlättar kommunikationen mellan en robot och en kanal. Den konverterar meddelanden som tas emot från kanaler till aktivitetsobjekt och skickar dem till robotens slutpunkt för meddelanden. På samma sätt konverterar den aktivitetsobjekt som tas emot från roboten till meddelanden som förstås av kanalen och skickar dem till kanalen.
• Bot Adapter är standardkortet för Bot Framework. Det:
  • Konverterar JSON-nyttolasten till ett aktivitetsobjekt.
  • Skapar en turkontext och lägger till aktivitetsobjektet i den.
  • Kör om några mellanprogram.
  • Vidarebefordrar turkontexten till roboten.

Kommentar

När ett anpassat kanalkort används utför själva adaptern de uppgifter som botanslutningstjänsten och standardrobotadaptern gör. Dessutom tillhandahåller den autentiseringsmekanismen för det relaterade webbkrok-API:et. Ett exempel finns i Ansluta en robot till Slack med hjälp av Slack-adaptern.

Robotautentisering

En robot identifieras av dess MicrosoftAppID och MicrosoftAppPassword, som lagras i robotens inställningsfiler (appsettings.json (.NET), .env (JavaScript), config.py (Python)) eller i en hemligheter eller nyckelhanterare. Mer information finns i MicrosoftAppID och MicrosoftAppPassword.

När du registrerar en robot i Azure-portalen skapar Azure ett Registreringsprogram för Microsoft Entra-ID. Om du använder Bot Framework CLI måste du specifikt utföra ett steg för att skapa Microsoft Entra-ID-registreringen. Den här registreringen har ett program-ID (MicrosoftAppID) och en klienthemlighet (MicrosoftAppPassword). Azure använder dessa värden för att generera en token som roboten kan komma åt säkra resurser med.

När en kanal skickar en begäran till en robot, via Bot Connector-tjänsten, anger den en token i auktoriseringshuvudet för begäran. Roboten autentiserar anrop från Bot Connector-tjänsten genom att verifiera tokens äkthet.

När roboten skickar en begäran till en kanal via Bot Connector-tjänsten måste den ange token i auktoriseringshuvudet för begäran. Alla begäranden måste innehålla åtkomsttoken, som verifieras av Bot Connector-tjänsten för att auktorisera begäran.

De åtgärder som beskrivs utförs automatiskt av Bot Framework SDK.

Mer information finns i REST API-dokumentationen om hur du autentiserar begäranden från Bot Connector-tjänsten till din robot och autentiserar begäranden från roboten till Bot Connector-tjänsten.

Kanaler

Vanligtvis kommunicerar kanaler med en robot via Bot Connector-tjänsten, så de tidigare autentiseringsprinciperna gäller vanligtvis. Vissa kanaler och funktioner har unika autentiseringsöverväganden.

Direct Line

Förutom de standardkanaler som stöds kan ett klientprogram kommunicera med en robot med hjälp av Direct Line-kanalen.

Klientprogrammet autentiserar begäranden till Direct Line (version 3.0) antingen med hjälp av en hemlighet som hämtats från konfigurationssidan för Direct Line-kanalen i Azure-portalen eller, bättre, med hjälp av en token som hämtats vid körning. Hemligheten eller token anges i auktoriseringshuvudet för varje begäran.

Viktigt!

När du använder Azure AI Bot Service-autentisering med webbchatt finns det några viktiga säkerhetsöverväganden som du måste tänka på. Mer information finns i avsnittet säkerhetsöverväganden i artikeln REST-autentisering.

Mer information finns i Håll hemligheten dold, byt ut din hemlighet mot en token och generera inbäddningen.

Webbchatt

Webbchatten har två implementeringar: kanalen och kontrollen.

• När du registrerar en robot med Azure konfigureras webbchattkanalen automatiskt för att tillåta testning av roboten. Mer information finns i Ansluta en robot till webbchatt.
• Du kan använda en webbchattkontroll med Direct Line-kanalen för att ge åtkomst till en robot i ett klientprogram. Mer information om kontrollen finns i Bot Framework Web Chat.

Kompetens

En färdighet och en kunskapskonsument är två distinkta robotar, var och en med sitt eget app-ID och lösenord.

• Konsumenten kan vidarebefordra användaraktiviteter till en färdighet och vidarebefordra kunskapens svar till användaren.
• För färdigheten fungerar färdighetskonsumenten som en kanal. Konsumenten har en färdighetsvärdslutpunkt som fungerar som den tjänst-URL som färdigheten skickar aktiviteter till.
• Mer information om färdigheter finns i kunskapsöversikten.

Autentisering på tjänstnivå hanteras av Bot Connector-tjänsten. Ramverket använder ägartoken och robotprogram-ID:t för att verifiera identiteten för varje robot.

Viktigt!

Detta kräver att alla robotar (kunskapskonsumenten och alla färdigheter som används) har giltiga autentiseringsuppgifter för programmet.

Anspråksverifiering

Utöver den här grundläggande autentiseringsnivån måste du lägga till en anspråksverifiering till autentiseringskonfigurationen för kunskaps- och kunskapskonsumenten. Anspråken utvärderas efter autentiseringshuvudet. Den här processen gör det möjligt för varje robot att begränsa vilka andra robotar som den kommer att acceptera aktiviteter från.

Exempel på anspråksvalidering finns i hur du implementerar en färdighet och implementerar en kunskapskonsument.

Bot Framework Emulator

Bot Framework-emulatorn har ett eget autentiseringsflöde och egna token. Emulatorn har en egen kanal och en inbyggd server.

Användarautentisering

Ibland måste en robot komma åt skyddade onlineresurser för användarens räkning. För att göra det måste roboten vara auktoriserad. Det beror på att roboten måste anropa en extern tjänst som Microsoft Graph, GitHub eller ett företags REST-tjänst för att kunna utföra vissa åtgärder, till exempel att kontrollera e-post, kontrollera flygstatus eller göra en beställning. OAuth används för att autentisera användaren och auktorisera roboten.

Kommentar

Två makrosteg är inblandade för att en robot ska få åtkomst till en användares resurser.

1. Autentisering. Processen för att verifiera användarens identitet.
2. Auktorisering. Processen för att verifiera att roboten kan komma åt användarens resurser.

Om det första steget lyckas utfärdas en token baserat på användarens autentiseringsuppgifter. I det andra steget använder roboten token för att komma åt användarens resurser.

Mer information finns i Användarautentisering.

Identitetsprovidrar

En identitetsprovider autentiserar användar- eller klientidentiteter och utfärdar förbrukningsbara säkerhetstoken. Den tillhandahåller användarautentisering som en tjänst. Klientprogram, till exempel webbprogram, delegerar autentisering till en betrodd identitetsprovider.

En robot kan använda en betrodd identitetsprovider för att:

• Aktivera funktioner för enkel inloggning (SSO) så att den kan komma åt flera skyddade resurser.
• Anslut till molnbaserad databehandling för en användares räkning, vilket minskar behovet av att användare autentiserar igen.

Kommentar

Token som utfärdades under robotautentiseringen är inte samma token som utfärdades under användarautentiseringen. Den första används för att upprätta säker kommunikation mellan en robot, kanaler och i slutändan klientprogram. Den andra används för att auktorisera roboten för åtkomst till skyddade resurser för användarens räkning.

Observera att kanalerna tillhandahåller sin egen, separata användarautentisering så att en användare kan logga in på kanalen.

Mer information om hur robotar kan använda identitetsprovidrar för att få åtkomst till resurser åt en användare finns i Identitetsprovidrar .