Autorisierung und Authentifizierung für SharePoint-Add-Ins
Wenn sich ein Benutzer bei SharePoint anmeldet, wird das Sicherheitstoken eines Benutzers überprüft. Das Token wird von einem Identitätsanbieter ausgegeben. SharePoint unterstützt verschiedene Typen von Benutzerauthentifizierung. Weitere Informationen finden Sie unter Authentifizierung, Autorisierung und Sicherheit in SharePoint.
SharePoint-Add-Ins sind auch Sicherheitsprinzipale, die authentifiziert und autorisiert werden müssen. Add-Ins können auf verschiedene Arten authentifiziert und autorisiert werden. Weitere Informationen finden Sie unter Drei Autorisierungssysteme für SharePoint-Add-Ins.
Autorisierungsrichtlinien: Nur Benutzer, Nur Add-Ins oder Benutzer und Add-In
Die Autorisierung überprüft, ob ein authentifizierter Antragsteller (ein Add-In oder ein Benutzer oder beide) berechtigt ist, bestimmte Vorgänge durchzuführen oder auf bestimmte Ressourcen zuzugreifen (z. B. eine Liste oder einen SharePoint-Dokumentordner).
SharePoint verwendet drei Arten von Autorisierungsrichtlinien:
Die Nur-Benutzer-Richtlinie erfordert nur, dass der Aufruf von SharePoint eine authentifizierte Benutzeridentität umfasst.
Die Nur-Add-In-Richtlinie erfordert nur, dass der Aufruf von SharePoint eine authentifizierte Add-In-Identität umfasst.
Die Benutzer-und-Add-In-Richtlinie setzt voraus, dass der Aufruf beide Arten von authentifizierten Identitäten umfasst.
Wenn ein Benutzer über die SharePoint-Benutzeroberfläche anstelle eines Add-Ins auf SharePoint-Ressourcen zugreift, verwendet SharePoint die Nur-Benutzer-Richtlinie. Für Aufrufe von einem SharePoint-Add-In aus verwendet SharePoint jedoch entweder die Nur-Add-In-Richtlinie oder die Benutzer-und-Add-In-Richtlinie.
Das SharePoint-Add-In bestimmt anhand des Typs des Zugriffstokens, das es in seine Anforderung an SharePoint einschließt, welche Richtlinie verwendet wird. Wenn eine Benutzer-und-Add-In-Anforderung gestellt wird, erfordert SharePoint, dass sowohl das Add-In als auch der Benutzer Berechtigungen für die Ressource haben, auf die das Add-In zugreift. Im Falle einer Nur-Add-In-Anforderung erfordert SharePoint, dass das Add-In über Berechtigungen für die Ressource verfügt, es ist jedoch egal, ob der Benutzer ebenfalls über Berechtigungen verfügt. (Ein SharePoint-Add-In kann nur dann Nur-Add-In-Anforderungen stellen, wenn es hierfür vorab die Berechtigung erhalten hat, in der Regel bei der Installation.)
Weitere Informationen über Autorisierungsrichtlinien und ihre Funktionsweise finden Sie unter Add-In-Autorisierungsrichtlinientypen in SharePoint.
Add-In-Berechtigungen und Bereiche von Add-In-Berechtigungsanforderungen
Der Entwickler eines SharePoint-Add-Ins muss über die Add-In-Manifestdatei angeben, welche Berechtigungen ein Add-In für SharePoint-Ressourcen außerhalb des Add-In-Webs benötigt. (Das Add-In erhält automatisch die Berechtigung „Vollzugriff“ für das gesamte Add-In-Web). Wenn das Add-In so konzipiert ist, dass es aus SharePoint gestartet wird, wird der Benutzer, der das Add-In installiert, von der Add-In-Installationsinfrastruktur aufgefordert, die erforderlichen Berechtigungen zu gewähren oder zu verweigern. Nachdem die Berechtigungen erteilt wurden, können Benutzer der Website das Add-In verwenden, ohne ihm erneut Berechtigungen erteilen zu müssen.
Wenn das Add-In jedoch so konzipiert ist, dass es außerhalb von SharePoint gestartet wird, d. h. nicht in SharePoint installiert ist, wird der Benutzer, der das Add-In ausführt, aufgefordert, die erforderlichen Berechtigungen bei jedem Ausführen des Add-Ins zu erteilen. Add-Ins auf mobilen Geräten und Office-Add-Ins sind Beispiele für Add-Ins, die auf SharePoint zugreifen können, jedoch nicht darauf installiert sind.
Nur der Besitzer einer Website kann ein SharePoint-Add-In auf einer SharePoint-Website installieren (es sei denn, es wurde eine benutzerdefinierte Funktion erstellt, die über Add-In-Installationsrechte verfügt). Ein Benutzer kann einem Add-In nur Berechtigungen erteilen, über die der Benutzer selbst verfügt. Ein Benutzer kann daher kein Add-In installieren, das Berechtigungen benötigt, über die der Benutzer nicht verfügt.
In ähnlicher Weise kann ein Benutzer kein extern gestartetes Add-In ausführen, das Berechtigungen benötigt, über die der Benutzer nicht verfügt. Wenn jedoch ein SharePoint-Add-In in SharePoint installiert ist, kann dieses um die Berechtigung zum Tätigen von Nur-Add-In-Aufrufen bitten. Ein Add-In, das über diese Berechtigung verfügt, kann über Wege auf SharePoint zugreifen, für die der Benutzer, der das Add-In ausführt, keine Berechtigung hat.
Berechtigungen für Add-Ins können auch von SharePoint Online-Mandantenadministratoren oder SharePoint-Farmadministratoren widerrufen oder gewährt werden.
In der Add-In-Manifestdatei gibt ein SharePoint-Add-In die Berechtigungen an, die es für eine einwandfreie Funktion benötigt. Die Berechtigungsanforderungen geben sowohl die Rechte an, die ein Add-In benötigt, als auch den Bereich, für den diese Berechtigungen benötigt werden. Bereiche geben an, an welcher Stelle in der SharePoint-Hierarchie eine Berechtigungsanforderung gültig ist.
SharePoint unterstützt vier unterschiedliche Bereiche: Mandanten, Websitesammlung, Website und Liste. Es gibt auch spezielle Bereiche zur Durchführung von Suchabfragen, für den Zugriff auf Taxonomiedaten, Features für soziale Netzwerke, Microsoft Business Connectivity Services (BCS) Features und Funktionen von Project Server 2013.
Weitere Informationen finden Sie unter Add-In-Berechtigungen in SharePoint.
Wann wird OAuth verwendet?
Vielleicht haben Sie bereits gehört, dass OAuth 2.0 eine wichtige Rolle bei der Authentifizierung und Autorisierung von SharePoint-Add-Ins spielt. Das stimmt natürlich, es ist aber nicht unbedingt ein Teil der Autorisierungsgeschichte für jedes SharePoint-Add-In.
Wenn Sie planen, ein Add-In für SharePoint zu erstellen, das in einer Remotewebanwendung ausgeführt wird und mithilfe von serverseitigem Code an SharePoint zurück kommuniziert, müssen Sie OAuth verwenden.
Wenn die Remotewebanwendung extern ist, würden Sie das Autorisierungssystem mit niedriger Vertrauensebene verwenden, bei dem Azure ACS der Herausgeber des Zugriffstokens ist.
Wenn es lokal ist, würden Sie in der Regel das System mit hoher Vertrauenswürdigkeit verwenden, bei dem das Add-In selbst und ein digitales Zertifikat die Herausgeber des Zugriffstokens sind.
Sie würden nicht OAuth verwenden, um einen Aufruf von JavaScript auf einer Seite im Add-In-Web selbst oder von einer Remotewebseite mithilfe der domänenübergreifenden Bibliothek zu tätigen. Weitere Informationen zur domänenübergreifenden Bibliothek finden Sie unter Erstellen von SharePoint-Add-Ins, die die domänenübergreifende Bibliothek verwenden