Drei Autorisierungssysteme für SharePoint-Add-Ins

  • Artikel

In SharePoint ist ein SharePoint-Add-In genau wie ein Benutzer ein Identitätsprinzipal und muss authentifiziert und autorisiert werden, um SharePoint-Ressourcen zu verwenden. Eine App kann drei Authorisierungssysteme verwenden. Sie schließen sich nicht gegenseitig aus.

So funktionieren die drei Autorisierungssysteme und dafür können sie verwendet werden

Niedrige Vertrauensebene

Ein vom Anbieter gehostetes SharePoint-Add-In kann sich bei Microsoft Azure Access Control Service (ACS) registrieren, der ein Zugriffstoken für das Add-In ausgibt, das dem Add-In Zugriff auf die Ressourcen in dem SharePoint-Mandanten oder der SharePoint-Farm ermöglicht, auf dem das Add-In installiert ist. Azure ACS ist der vertrauenswürdige Tokenaussteller in einem OAuth 2.0 Framework-"Flow", der SharePoint und die Remotekomponenten des Add-Ins enthält. Add-Ins, die dieses System verwenden, können im Office Store verkauft werden. Das System mit niedriger Vertrauenswürdigstellung ist in erster Linie für Add-Ins vorgesehen, deren Remotekomponenten in der Cloud gehostet werden.

Wichtig

Azure ACS (Access Control), ein Dienst von Azure Active Directory (Azure AD), wird am 7. November 2018 eingestellt. Diese Deaktivierung hat keinen Einfluss auf das SharePoint-Add-In-Modell, das den Hostnamen https://accounts.accesscontrol.windows.net verwendet, der von der Deaktivierung nicht betroffen ist. Weitere Informationen finden Sie unter Auswirkungen der Deaktivierung von Azure Access Control für SharePoint-Add-Ins.

Weitere Informationen zum Erstellen eines SharePoint-Add-Ins, das das System mit niedriger Vertrauensebene verwendet, finden Sie unter Erstellen von SharePoint-Add-Ins, die die Autorisierung mit niedriger Vertrauensebene verwenden.

Hinweis

Der Kunde, der das Add-In installiert, muss über ein Office 365-Konto verfügen. Dies ist erforderlich, um dem Add-In Zugriff auf Azure ACS zu gewähren. Der Kunde muss das Konto jedoch nicht für andere Zwecke verwenden, und das Add-In kann nach einigen einfachen Konfigurationsaufgaben in der Farm in einer lokalen SharePoint-Farm installiert werden.

Hohe Vertrauensebene

Ein vom Anbieter gehostetes Add-In kann mithilfe digitaler Zertifikate eine Vertrauensstellung mit SharePoint herstellen. Das besonders vertrauenswürdige System ist in erster Linie für Add-Ins vorgesehen, deren Remotekomponenten lokal gehostet werden. Die App kann in einer SharePoint-Farm installiert werden, die nicht mit dem Internet verbunden ist. Die App kann nicht auf SharePoint Online installiert oder im Office Store verkauft werden.

Weitere Informationen zum Erstellen eines SharePoint-Add-Ins, das das System mit hoher Vertrauensebene verwendet, finden Sie unter Erstellen von SharePoint-Add-Ins, die die Autorisierung mit hoher Vertrauensebene verwenden.

Domänenübergreifende Bibliothek

Wenn sich die Geschäftslogik des Add-Ins in JavaScript befindet, haben Sie die Möglichkeit, die domänenübergreifende SharePoint-Bibliothek entweder anstelle oder als Ergänzung zu den Systemen mit geringem vertrauenden und besonders vertrauenswürdigen System zu verwenden. Die Bibliothek ist außerdem für Szenarien vorgesehen, in denen die App in der Cloud gehostete Komponenten aufweist, die Unternehmensfirewall des Kunden jedoch die Verwendung des Systems mit niedriger Vertrauensebene erschwert. Der Browser des Benutzers sperrt Skripts von anderen Domänen, die Bibliothek kapselt jedoch ein sicheres System, um diese Einschränkung zu umgehen. Add-Ins, die die Bibliothek verwenden, können im Office Store verkauft und entweder in SharePoint Online oder auf lokalem SharePoint installiert werden.

Weitere Informationen zum Erstellen eines SharePoint-Add-Ins, das die domänenübergreifende Bibliothek verwendet, finden Sie unter:

Hintergrundinformationen zum OAuth 2.0-Framework und dessen SharePoint-Implementierung

Zwei der drei Autorisierungssysteme verwenden das OAuth 2.0-Framework. OAuth 2.0 ist ein offenes Framework für die Autorisierung. OAuth ermöglicht eine sichere Autorisierung von Desktopcomputern, Geräten und Webanwendungen auf eine Standardweise. Mit OAuth kann ein Benutzer eine Anwendung in seinem Namen agieren lassen, ohne seinen Benutzernamen und sein Kennwort weitergeben zu müssen.

Es ermöglicht beispielsweise das Freigeben privater Ressourcen oder Daten (Kontaktliste, Dokumente, Fotos, Videos usw.) durch einen Benutzer auf einer Website mit einer anderen Website, ohne dass der Benutzer hierfür seine Anmeldeinformationen (in der Regel Benutzername und Kennwort) für die andere Website angeben muss.

Mit OAuth können Benutzer Zugriffstoken für Daten bereitstellen, die von einem bestimmten Dienstanbieter (z. B. SharePoint) gehostet werden. Jedes Token gewährt Zugriff auf einen bestimmten Ressourcenanbieter (z. B. eine SharePoint-Website), für bestimmte Ressourcen (z. B. Dokumente in einer SharePoint-Dokumentbibliothek) und für eine definierte Dauer (z. B. 12 Stunden). Dadurch kann ein Benutzer einer Web- oder Desktopanwendung eines Drittanbieters Zugriff auf Informationen gewähren, die bei einer anderen Ressource oder einem anderen Dienstanbieter (z. B. SharePoint) gespeichert sind, ohne seinen Benutzernamen und sein Kennwort zu teilen und ohne alle Daten, die er besitzt, mit dem Anbieter zu teilen.

SharePoint verwendet die OAuth 2.0-Framework-Tokenübergabe-„Abläufe“ für die folgenden Zwecke:

  • Autorisieren von Anforderungen eines SharePoint-Add-Ins für den Zugriff auf SharePoint-Ressourcen

  • Authentifizieren von Add-Ins im Office Store, einem Add-In-Katalog oder einem Entwicklermandanten

Weitere Informationen und Hintergrundinformationen zu OAuth und zur OAuth-Terminologie finden Sie unter OAuth.net und Webautorisierungsprotokoll (oauth).

Zusammengefasst gibt es einen Ressourcenserver, der eine geschützte Ressource hostet, einen Besitzer der Ressource, eine Clientanwendung, die Zugriff auf die Ressource fordert, und einen Autorisierungsserver, der Zugriffstoken für die Ressource ausgibt, wenn er vom Ressourcenbesitzer dazu aufgefordert wird.

In der offiziellen OAuth-Dokumentation wird tendenziell von einem Szenario ausgegangen, in dem es einen einzelnen Ressourcenbesitzer gibt, der bei jeder Ausführung der Clientanwendung Zugriff auf die Ressource über die Clientanwendung gewährt. Außerdem wird davon ausgegangen, dass die Person, die die Clientanwendung verwendet, der Ressourcenbesitzer ist.

Die SharePoint-Implementierung berücksichtigt die Tatsache, dass eine SharePoint-Ressource, z. B. eine Liste, von mehreren Benutzern gemeinsam genutzt wird. Außerdem wird dem SharePoint-Add-In in der SharePoint-Implementierung zugriff gewährt, wenn es installiert wird, nicht bei jeder Ausführung, und es kann von anderen Benutzern als der Person ausgeführt werden, die es installiert und ihr Zugriff gewährt hat. (Bei Add-Ins, die nicht auf SharePoint installiert sind, aber auf SharePoint-Ressourcen zugreifen (sie sind also nur "SharePoint-Add-Ins" im erweiterten Sinne), muss der Benutzer, der das Add-In ausführt, bei jeder Ausführung des Add-Ins Berechtigungen erteilen.)

Deshalb werden in der SharePoint-Implementierung die OAuth-Rollen von den folgenden Komponenten übernommen:

  • Die Remotekomponente eines SharePoint-Add-Ins übernimmt die Rolle der Clientanwendung.

  • SharePoint-Benutzer übernehmen die Rolle des Ressourceneigentümers.

  • SharePoint übernimmt die Rolle des Ressourcenservers.

  • Azure ACS spielt die Rolle des Autorisierungsservers, wenn das Autorisierungssystem mit niedriger Vertrauenswürdigkeit verwendet wird. Wenn das besonders vertrauenswürdige System verwendet wird, wird das Add-In selbst (zusammen mit einem digitalen Zertifikat) zum Autorisierungsserver.

Zugriffstoken sind keine Anmeldetoken

Wie weiter oben beschrieben, muss ein Add-In für den Zugriff auf Ressourcen ein Zugriffstoken von einem OAuth-Autorisierungsserver anfordern, der zuvor vom Ressourcenbesitzer als vertrauenswürdiger Sicherheitstokenaussteller (STS) festgelegt wurde. Im Gegensatz dazu sind die WS-Federation-STS und die passiven Anmelde-Security Assertion Markup Language (SAML)-STS vorrangig dazu gedacht, Anmeldetoken auszugeben.

In SharePoint wird ein OAuth STS nicht zum Ausstellen von Anmeldetoken verwendet. Das heißt, sie werden nicht als Identitätsanbieter verwendet. Daher wird kein OAuth STS auf der Benutzeranmeldeseite, im Abschnitt Authentifizierungsanbieter in der Zentraladministration oder in der Personenauswahl in SharePoint aufgeführt.

SharePoint-Administratoren können Windows PowerShell-Befehle verwenden, um einen OAuth-STS zu aktivieren oder zu deaktivieren, ähnlich wie das Aktivieren oder Deaktivieren von vertrauenswürdigen Anmeldeanbietern in SharePoint.

Siehe auch