Im Entwicklungsverlauf eines Teams–Bots zeigt sich folgendes Anforderungsszenario: Der Bot soll im Kontext der angemeldeten Person auf weitere Azure–Ressourcen zugreifen.
Dieser Beitrag behandelt die dafür notwendige Grundlage in Azure: Single SignOn (SSO)-, sowie die korrekte Einrichtung des OnBehalfOf(OBO)Flows. Neben dem Rollenverständnis und konkreten Konfigurationsschritten werden kompakte Codebeispiele aus einer Referenzimplementierung erläutert, einschließlich der Integration von Azure AI Search mit Zugriffskontrolle auf Dokumentebene (RBAC) über den Bot.
Das Teams–SSO stellt dem Bot ein Token bereit, dessen Audience auf die BotAPI (App Registration: ExposeanAPI, z. B. api://botid-<CLIENT_ID>/access_as_user) gerichtet ist. Dieses Token ist nicht für nachgelagerte Dienste wie Azure AI Search verwendbar, da die Audience und Scopes nicht passen.
Azure AI Search verlangt für Abfragen im Benutzerkontext ein delegiertes Zugriffstoken mit Audience https://search.azure.com und Scope .default. Nur mit einem solchen Ressourcentoken kann der Dienst den Identitätskontext der angemeldeten Person auswerten und RowLevel Security zuverlässig erzwingen.
Das vom TeamsClient gelieferte SSOToken, dessen Audience auf die App zeigt, die das OBO-Token anfordert wird serverseitig, sicher und ohne erneute Benutzerinteraktion gegen ein AzureAISearchToken mit korrekter Audience und Scope getauscht. Dieses Token wird anschließend im Header x-ms–query–source-authorization an Azure AI Search übergeben, damit der Dienst die Anfrage der konkreten Person zuordnen und gegen im Index hinterlegte ACLInformationen (z. B. userIds, groupIds) prüfen kann.
Optionen wie reine Query– oder AdminKeys des SearchDienstes sind für dieses Anforderungsszenario ungeeignet. Ein Key authentifiziert nur die Anwendung, nicht die Person, und würde die Durchsetzung von dokumentenbezogenen Berechtigungen im Sinne von LeastPrivilege und Compliance unterlaufen.
Auch reine Anwendungsberechtigungen (Application Permissions) ohne Delegation sind problematisch, da sie den individuellen Kontext der angemeldeten Person nicht abbilden. Das OBOMuster stellt dagegen sicher, dass der Bot als vertraulicher Client agiert, die Identität delegiert und alle Downstream–Aufrufe, wie etwa Microsoft Graph oder Azure AI Search, mit der tatsächlichen Benutzeridentität stattfinden.
Ziel ist ein Teams-Bot, der:
Dabei sind drei Elemente entscheidend: die App-Registrierung (Expose an API + API Permissions), die Bot OAuth Connection im Azure Bot Service und der OBO-Flow in der Applogik.
Hinweis: Die autorisierten Clients verhindern wiederholte Zustimmungsprompts und stellen eine reibungslose SSO-Erfahrung sicher.
API Berechtigunge hinzufügen, auf welche der Bot Zugriff haben soll. Bspw.:
Nach dem ersten Deployment ist ggf. der Admin-Consent zu erteilen, damit OBO-gestützte Graph-Aufrufe funktionieren.
Im Azure Bot Service muss unter Settings -> Configuration -> Add OAuth Connection Settings eine OAuth Connection registriert werden:
Diese Connection liefert das SSO-Token an die App.
Die folgenden Auszüge zeigen, wie ein SSO-Token empfangen und persistiert wird, ein OBO-Token für Zielressourcen bezogen wird und wie nachgelagerte APIs im Benutzerkontext aufgerufen werden. Der Bot wurde mithilfe der Teams AI Library erstellt.
In Teams AI gibt es die Möglichkeit bestimmte Events, wie das Sign-In-Event zu subscriben. Dort lässt sich dann eine eigne Logik implementieren, um das Token bspw. in einem globalen State zu speichern.
Um im Namen der angemeldeten Person auf Ressourcen (z. B. Azure AI Search) zuzugreifen, wird das SSO-Token per OBO-Flow gegen ein Access Token mit passendem Scope der entsprechenden Ressource (bspw.: https://search.azure.com/.default) getauscht:
Mithilfe des erhaltenen OBO-Token lassen sich nun Downstream APIs aufrufen wie eine Vektor-Suche in Azure AI Search. Der Benutzerkontext wird über den Header x-ms-query-source-authorization an Azure AI Search übergeben. Dadurch greift Row-Level-Security anhand der im Index hinterlegten Benutzer-/Gruppen-IDs.
Die korrekte Einrichtung von SSO und OBO ist die Grundlage, um in Teams-Bots sicher und nahtlos im Benutzerkontext auf Azure-Ressourcen zuzugreifen. Nur durch den On-Behalf-Of-Flow lässt sich gewährleisten, dass nachgelagerte Dienste wie Azure AI Search oder Microsoft Graph den Identitätskontext der angemeldeten Person zuverlässig auswerten und Berechtigungen auf Dokument- oder Objektebene enforced werden. Das Ergebnis ist eine saubere, sichere und benutzerzentrierte Architektur – ganz im Sinne von Least Privilege und Compliance.
Wir sind für Sie da.
Bei welchem Projekt oder welcher Herausforderung dürfen wir Sie unterstützen?
Wir sind gerne für Sie da.
HEIKO WESSELS
Wollen Sie immer up2date sein? Dann melden Sie sich jetzt zu unserem Newsletter an
Bleiben Sie auf dem Laufenden. Wir informieren Sie regelmäßig über aktuelle Trends und technologische Neuerungen sowie geplante Webinare und Events. Sie erhalten Einblick in interessante Kundenprojekte und werfen einen Blick hinter die Kulissen. Melden Sie sich jetzt an.
