Verificatietypen

VAN TOEPASSING OP: SDK v4

In Bot Framework bestaan twee algemene verificatiecategorieën: botverificatie en gebruikersverificatie. Elk heeft een gekoppeld token om toegang tot beveiligde resources toe te staan. In de volgende afbeelding ziet u de elementen die betrokken zijn bij zowel bot- als gebruikersverificatie.

In deze afbeelding:

• HostPlatform is het hostplatform van de bot. Dit kan Azure of elk hostplatform zijn dat u hebt gekozen.
• Bot Connector Service vereenvoudigt de communicatie tussen een bot en een kanaal. Berichten die van kanalen zijn ontvangen, worden geconverteerd naar activiteitsobjecten en verzonden naar het berichteindpunt van de bot. Op dezelfde manier worden activiteitsobjecten die van de bot zijn ontvangen, geconverteerd naar berichten die door het kanaal worden begrepen en naar het kanaal verzonden.
• Bot Adapter is de standaard Bot Framework-adapter. Het:
  • Converteert de JSON-nettolading naar een activiteitsobject.
  • Hiermee maakt u een beurtcontext en voegt u het activiteitsobject eraan toe.
  • Voert middleware uit, indien van toepassing.
  • Hiermee wordt de beurtcontext doorgestuurd naar de bot.

Notitie

Wanneer een aangepaste kanaaladapter wordt gebruikt, voert de adapter zelf de taken uit die de Bot Connector-service en de standaardbotadapter doen. Het biedt ook het verificatiemechanisme voor de gerelateerde webhook-API. Zie Een bot verbinden met Slack met behulp van de Slack-adapter voor een voorbeeld.

Botverificatie

Een bot wordt geïdentificeerd door de MicrosoftAppID en MicrosoftAppPassword, die worden bewaard in de instellingenbestanden van de bot (appsettings.json .NET), (JavaScript), .env config.py (Python)) of in een geheimen- of sleutelbeheerder. Zie MicrosoftAppID en MicrosoftAppPassword voor meer informatie.

Wanneer u een bot registreert in Azure Portal, maakt Azure een Microsoft Entra ID-registratietoepassing. Als u de Bot Framework CLI gebruikt, moet u specifiek een stap uitvoeren om de Registratie van de Microsoft Entra-id te maken. Deze registratie heeft een toepassings-id (MicrosoftAppID) en clientgeheim (MicrosoftAppPassword). Azure gebruikt deze waarden om een token te genereren waarmee de bot toegang heeft tot beveiligde resources.

Wanneer een kanaal een aanvraag naar een bot verzendt, geeft het via de Bot Connector-service een token op in de autorisatieheader van de aanvraag. De bot verifieert aanroepen van de Bot Connector-service door de echtheid van het token te verifiëren.

Wanneer de bot een aanvraag naar een kanaal verzendt via de Bot Connector-service, moet deze het token opgeven in de autorisatieheader van de aanvraag. Alle aanvragen moeten het toegangstoken bevatten, dat wordt geverifieerd door de Bot Connector-service om de aanvraag te autoriseren.

De beschreven bewerkingen worden automatisch uitgevoerd door de Bot Framework SDK.

Zie de REST API-documentatie voor het verifiëren van aanvragen van de Bot Connector-service voor uw bot en het verifiëren van aanvragen van uw bot naar de Bot Connector-service voor meer informatie.

Kanalen

Normaal gesproken communiceren kanalen met een bot via de Bot Connector-service, zodat de vorige verificatieprincipes doorgaans van toepassing zijn. Sommige kanalen en functies hebben unieke verificatieoverwegingen.

Direct Line

Naast de standaard ondersteunde kanalen kan een clienttoepassing communiceren met een bot met behulp van het Direct Line-kanaal.

De clienttoepassing verifieert aanvragen voor Direct Line (versie 3.0) met behulp van een geheim dat is verkregen via de configuratiepagina van het Direct Line-kanaal in Azure Portal, of beter, met behulp van een token dat tijdens runtime is verkregen. Het geheim of token wordt opgegeven in de autorisatieheader van elke aanvraag.

Belangrijk

Wanneer u Azure AI Bot Service-verificatie gebruikt met Webchat zijn er enkele belangrijke beveiligingsoverwegingen waarmee u rekening moet houden. Zie de sectie beveiligingsoverwegingen in het artikel over REST-verificatie voor meer informatie.

Zie Uw geheim verborgen houden, uw geheim uitwisselen voor een token en het insluiten genereren voor meer informatie.

Webgesprek

De Webchat heeft twee implementaties: het kanaal en de controle.

• Wanneer u een bot registreert bij Azure, wordt het Webchat-kanaal automatisch geconfigureerd om het testen van de bot toe te staan. Zie Een bot verbinden met Webchat voor meer informatie.
• U kunt een Webchat-besturingselement gebruiken met het kanaal Direct Line om toegang te bieden tot een bot in een clienttoepassing. Zie Bot Framework Webchat voor meer informatie over het besturingselement.

Vaardigheden

Een vaardigheid en een vaardigheidsconsumer zijn twee afzonderlijke bots, elk met hun eigen app-id en wachtwoord.

• De consument kan gebruikersactiviteiten doorsturen naar een vaardigheid en de reacties van de vaardigheid doorsturen naar de gebruiker.
• Aan de vaardigheid fungeert de vaardigheidsconsumer als een kanaal. De consument heeft een hosteindpunt voor vaardigheden dat fungeert als de service-URL waarnaar de vaardigheid activiteiten verzendt.
• Zie het overzicht van vaardigheden voor meer informatie over vaardigheden.

Verificatie op serviceniveau wordt beheerd door de Bot Connector-service. Het framework maakt gebruik van bearer-tokens en bottoepassings-id's om de identiteit van elke bot te verifiëren.

Belangrijk

Hiervoor moeten alle bots (de vaardigheidsconsumer en alle vaardigheden die worden gebruikt) geldige toepassingsreferenties hebben.

Validatie van claims

Naast dit basisniveau van verificatie moet u een claimvalidator toevoegen aan de verificatieconfiguratie van de vaardigheid en de gebruiker van de vaardigheid. De claims worden geëvalueerd na de verificatieheader. Met dit proces kan elke bot beperken van welke andere bots het activiteiten accepteert.

Zie voor voorbeeldclaimvalidatie hoe u een vaardigheid implementeert en een gebruiker van een vaardigheid implementeert.

Bot Framework Emulator

De Bot Framework Emulator heeft een eigen verificatiestroom en eigen tokens. De emulator heeft een eigen kanaal en een ingebouwde server.

Gebruikersverificatie

Soms moet een bot namens de gebruiker toegang krijgen tot beveiligde onlinebronnen. Hiervoor moet de bot zijn geautoriseerd. Dit komt doordat bepaalde bewerkingen, zoals het controleren van e-mail, het controleren van de vluchtstatus of het plaatsen van een bestelling, de bot een externe service zoals Microsoft Graph, GitHub of de REST-service van een bedrijf moet aanroepen. OAuth wordt gebruikt om de gebruiker te verifiëren en de bot te autoriseren.

Notitie

Er zijn twee macrostappen betrokken voor een bot om toegang te krijgen tot de resources van een gebruiker.

1. Verificatie. Het proces voor het verifiëren van de identiteit van de gebruiker.
2. Autorisatie. Het proces om te controleren of de bot toegang heeft tot de resources van de gebruiker.

Als de eerste stap is geslaagd, wordt er een token uitgegeven op basis van de referenties van de gebruiker. In de tweede stap gebruikt de bot het token om toegang te krijgen tot de resources van de gebruiker.

Zie Gebruikersverificatie voor meer informatie.

Id-providers

Een id-provider verifieert gebruikers- of clientidentiteiten en geeft verbruikbare beveiligingstokens uit. Het biedt gebruikersverificatie als een service. Clienttoepassingen, zoals webtoepassingen, delegeren verificatie aan een vertrouwde id-provider.

Een bot kan een vertrouwde id-provider gebruiken om:

• Schakel functies voor eenmalige aanmelding (SSO) in, zodat deze toegang heeft tot meerdere beveiligde resources.
• Maak verbinding met cloudcomputingresources namens een gebruiker, waardoor gebruikers minder nodig zijn om zich opnieuw te verifiëren.

Notitie

Het token dat is uitgegeven tijdens botverificatie , is niet hetzelfde token dat is uitgegeven tijdens gebruikersverificatie. De eerste wordt gebruikt om beveiligde communicatie tot stand te brengen tussen een bot, kanalen en uiteindelijk clienttoepassingen. De tweede wordt gebruikt om de bot toegang te geven tot beveiligde resources namens de gebruiker.

U ziet dat kanalen hun eigen, afzonderlijke gebruikersverificatie bieden om een gebruiker zich aan te melden bij het kanaal.

Zie Id-providers voor meer informatie over hoe bots id-providers kunnen gebruiken voor toegang tot resources namens een gebruiker.