Freigeben über

Authentifizierungsübersicht für SharePoint Server

  • Artikel

GILT FÜR:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

SharePoint Server erfordert Authentifizierung für folgende Interaktionstypen:

  • Benutzer, die auf lokale SharePoint-Ressourcen zugreifen

  • Apps, die auf lokale SharePoint-Ressourcen zugreifen

  • Lokale Server, die auf lokale SharePoint-Ressourcen zugreifen oder umgekehrt

Erfahren Sie mehr über die SharePoint-Authentifizierung in Microsoft 365.

Hinweis

In der SharePoint Server-Abonnementedition unterstützen wir jetzt die OIDC 1.0-Authentifizierung. Weitere Informationen zum Arbeiten mit diesem neuen Authentifizierungstyp finden Sie unter OpenID Connect 1.0-Authentifizierung.

Benutzerauthentifizierung in SharePoint Server

Die Benutzerauthentifizierung ist die Überprüfung der Identität eines Benutzers gegen einen Authentifizierungsanbieter, bei dem es sich um ein Verzeichnis oder eine Datenbank handelt, das die Anmeldeinformationen des Benutzers enthält und überprüfen kann, ob der Benutzer sie ordnungsgemäß übermittelt hat. Die Benutzerauthentifizierung wird durchgeführt, wenn ein Benutzer versucht, auf eine SharePoint-Ressource zuzugreifen.

SharePoint Server unterstützt die anspruchsbasierte Authentifizierung.

Das Ergebnis einer anspruchsbasierten Authentifizierung ist ein anspruchsbasiertes Sicherheitstoken, das vom SharePoint-Sicherheitstokendienst (STS) generiert wird.

SharePoint Server unterstützt windows-basierte, formularbasierte, SAML-basierte (Security Assertion Markup Language) und Open ID Connect (OIDC)-basierte Anspruchsauthentifizierung. Informationen zur Funktionsweise von Windows-, Forms- und SAML-basierten Authentifizierungsmethoden finden Sie in den folgenden Videos. Informationen zur Funktionsweise der OIDC-Authentifizierung finden Sie im OIDC-Setuphandbuch.

Hinweis

Diese Informationen in den Videos gelten für SharePoint Server 2013, SharePoint Server 2016, SharePoint Server 2019 und SharePoint Server Subscription Edition.

Video zur Windows-Anspruchsauthentifizierung in SharePoint 2013 und 2016

Video zur formularbasierten Anspruchsauthentifizierung in SharePoint 2013 und 2016

Video zur SAML-basierten Anspruchsauthentifizierung in SharePoint 2013 und 2016

Weitere Informationen finden Sie unter Planen der Benutzerauthentifizierungsmethoden in SharePoint Server.

App-Authentifizierung in SharePoint Server

Die App-Authentifizierung ist die Überprüfung der Identität einer Remote-SharePoint-App und die Autorisierung der App und eines dazugehörigen Benutzers einer gesicherten SharePoint-Ressourcenanforderung. Die App-Authentifizierung erfolgt, wenn eine externe Komponente einer SharePoint Store-App oder einer App-Katalog-App, z. B. ein Webserver, der sich im Intranet oder im Internet befindet, versucht, auf eine gesicherte SharePoint-Ressource zuzugreifen.

Nehmen Sie beispielsweise an, ein Benutzer öffnet eine SharePoint-Seite, die den IFRAME einer SharePoint-App enthält, und dieser IFRAME erfordert eine externe Komponente, – z. B. einen Server im Intranet oder Internet – um auf eine gesicherte SharePoint-Ressource zuzugreifen und die Seite zu rendern. Die externe Komponente der SharePoint-App muss authentifiziert und autorisiert werden, damit SharePoint die angeforderten Informationen bereitstellt, und die App die Seite für den Benutzer rendern kann.

Wenn die SharePoint-App keine gesicherte SharePoint-Ressource zum Rendern der Seite für den Benutzer erfordert, ist keine App-Authentifizierung erforderlich. Beispielsweise muss eine SharePoint-App, die Wettervorhersageinformationen bereitstellt und nur auf einen Wetterinformationsserver im Internet zugreifen muss, keine App-Authentifizierung verwenden.

Die App-Authentifizierung ist eine Kombination von zwei Prozessen:

  • Authentifizierung

    Überprüfen, ob die Anwendung ordnungsgemäß bei einem allgemein vertrauenswürdigen Identitätsbroker registriert ist

  • Autorisierung

    Überprüfen, ob die Anwendung und der dazugehörige Benutzer für die Anforderung über die entsprechenden Berechtigungen zum Ausführen des Vorgangs verfügt, z. B. zum Zugreifen auf einen Ordner bzw. eine Liste oder zum Ausführen einer Abfrage

Zum Ausführen einer App-Authentifizierung ruft die Anwendung entweder vom Microsoft Azure-Zugriffssteuerungsdienst (Access Control Service, ACS) ein Zugriffstoken ab oder signiert selbst ein Zugriffstoken mit einem Zertifikat, dem SharePoint Server vertraut. Das Zugriffstoken erstellt eine Anforderung des Zugriffs auf eine bestimmte SharePoint-Ressource und enthält Informationen, die die App und den zugehörigen Benutzer identifizieren, statt einer Überprüfung der Anmeldeinformationen des Benutzers. Das Zugriffstoken ist kein Anmeldetoken.

Es folgt ein Beispiel für den Authentifizierungsprozess für SharePoint Store-Apps:

  1. Ein Benutzer öffnet eine SharePoint-Webseite, die einen IFRAME enthält, der von einer SharePoint Store-App gerendert werden muss, die im Internet gehostet ist und ACS als Vertrauensbroker verwendet. Die SharePoint Store-App muss auf eine SharePoint-Ressource zugreifen, um den IFRAME für den Benutzer zu rendern.

  2. Der SharePoint-Sicherheitstokendienst fordert und erhält ein Kontexttoken vom Windows Azure-Zugriffssteuerungsdienst (ACS).

  3. SharePoint sendet die angeforderte Webseite zusammen mit dem Kontexttoken an den Webbrowser des Benutzers.

  4. Der Webbrowser des Benutzers sendet eine Anforderung des IFRAME-Inhalts und das Kontexttoken an den SharePoint Store-App-Server im Internet.

  5. Der SharePoint Store-App-Server fordert und erhält ein Zugriffstoken vom ACS.

  6. Der SharePoint Store-App-Server sendet die SharePoint-Ressourcenanforderung und das Zugriffstoken an den SharePoint-Server.

  7. Der SharePoint-Server autorisiert den Zugriff und überprüft dabei die Berechtigungen der App, die bei der Installation der App festgelegt wurde, und die Berechtigungen des dazugehörigen Benutzers.

  8. Sind die erforderlichen Berechtigungen vorhanden, sendet SharePoint die angeforderten Daten an den SharePoint Store-App-Server im Internet.

  9. Der SharePoint Store-App-Server im Internet sendet die IFRAME-Ergebnisse an den Webbrowser, der den IFRAME-Bereich der Seite für den Benutzer rendert.

Beachten Sie, dass die SharePoint Store-App auf SharePoint-Serverressourcen zugreifen konnte, ohne die Anmeldeinformationen des Benutzers abzurufen. Der Zugriff wurde durch den ACS authentifiziert, dem der Server mit SharePoint Server vertraut, und durch den App- und Benutzerberechtigungssatz autorisiert.

Es folgt ein Beispiel für den Authentifizierungsprozess für SharePoint-App-Katalog-Apps:

  1. Ein Benutzer öffnet eine SharePoint-Webseite, die einen IFRAME enthält, der von einer App-Katalog-App gerendert werden muss, die im Intranet gehostet ist und ein selbstsigniertes Zertifikat für die Zugriffstoken verwendet. Die App-Katalog-App muss auf eine SharePoint-Ressource zugreifen, um den IFRAME für den Benutzer zu rendern.

  2. SharePoint sendet die angeforderte Seite zusammen mit dem IFRAME an den Webbrowser des Benutzers.

  3. Der Webbrowser des Benutzers sendet eine Anforderung des IFRAME-Inhalts an den App-Katalog-App-Server im Intranet.

  4. Der App-Katalog-App-Server authentifiziert den Benutzer und generiert ein mit dem selbstsignierten Zertifikat signiertes Zugriffstoken.

  5. Der App-Katalog-App-Server sendet die SharePoint-Ressourcenanforderung und das Zugriffstoken an den SharePoint-Server.

  6. Der SharePoint-Server autorisiert den Zugriff und überprüft dabei die Berechtigungen der App, die bei der Installation der App festgelegt wurde, und die Berechtigungen des dazugehörigen Benutzers.

  7. Sind die erforderlichen Berechtigungen vorhanden, sendet der SharePoint-Server die angeforderten Daten an den App-Katalog-App-Server im Intranet.

  8. Der App-Katalog-App-Server sendet die IFRAME-Ergebnisse an den Webbrowser, der den IFRAME-Bereich der Seite für den Benutzer rendert.

Hinweis

App-Katalog-Apps können entweder ACS-Zertifikate oder ein selbstsigniertes Zertifikat als Zugriffstoken verwenden.

Weitere Informationen finden Sie unter Planen der App-Authentifizierung in SharePoint Server.

Server-zu-Server-Authentifizierung in SharePoint Server

Server-zu-Server-Authentifizierung ist die Überprüfung der Anforderung eines Servers für Ressourcen, die auf einer Vertrauensstellung basiert, die zwischen dem STS des Servers, auf dem SharePoint Server ausgeführt wird, und dem STS eines anderen Servers eingerichtet wird, der das OAuth-Server-zu-Server-Protokoll unterstützt, z. B. lokal unter SharePoint Server, Exchange Server 2016, Skype for Business 2016 oder Azure Workflow Service. und SharePoint Server, die in Microsoft 365 ausgeführt werden. Basierend auf dieser Vertrauensstellung kann ein anfordernder Server im Auftrag eines angegebenen Benutzers und gemäß den Server- und Benutzerberechtigungen auf gesicherte Ressourcen auf dem SharePoint-Server zugreifen.

Beispielsweise kann ein Server, auf dem Exchange Server 2016 ausgeführt wird, Ressourcen eines Servers mit SharePoint Server für ein bestimmtes Benutzerkonto anfordern. Diese Bereitstellung steht im Gegensatz zur App-Authentifizierung, bei der die App keinen Zugriff auf Anmeldeinformationen des Benutzerkontos hat. Je nach Dienst und Anforderung kann der Benutzer derzeit bei dem Server angemeldet sein, auf dem die Ressourcenanforderung ausgeführt wird oder nicht.

Wenn ein Server mit SharePoint Server versucht, auf eine Ressource auf einem Server zuzugreifen, oder ein Server versucht auf eine Ressource auf einem Server mit SharePoint Server zuzugreifen, muss die eingehende Zugriffanforderung authentifiziert werden, damit der Server die eingehende Zugriffsanforderung und nachfolgende Daten akzeptiert. Die Server-zu-Server-Authentifizierung überprüft, ob der Server, auf dem SharePoint Server ausgeführt wird, und der Benutzer, den sie darstellt, vertrauenswürdig sind.

Das Token, das für eine Server-zu-Server-Authentifizierung verwendet wird, ist ein Server-zu-Server-Token, kein Anmeldetoken. Das Server-zu-Server-Token enthält Informationen über den Server, der Zugriff anfordert, und das Benutzerkonto, in dessen Auftrag der Server agiert.

Es folgt ein Beispiel für den einfachen Prozess für lokale Server:

  1. Ein Benutzer öffnet eine SharePoint-Webseite, die Informationen von einem anderen Server benötigt (z. B. zum Anzeigen der Liste mit Aufgaben aus SharePoint Server und Exchange Server 2016).

  2. SharePoint Server generiert ein Server-zu-Server-Token.

  3. SharePoint Server sendet das Server-zu-Server-Token an den anderen Server.

  4. Der andere Server überprüft das SharePoint-Server-zu-Server-Token.

  5. Der andere Server sendet eine Meldung an SharePoint Server, um anzugeben, dass das gesendete Server-zu-Server-Token gültig war.

  6. Der Dienst auf dem Server mit SharePoint Server greift auf die Daten auf dem Server zu.

  7. Der Dienst auf dem Server mit SharePoint Server rendert die Seite für den Benutzer.

Es folgt ein Beispiel für den Prozess, wenn beide Server in Microsoft 365 ausgeführt werden:

  1. Ein Benutzer öffnet eine SharePoint-Webseite, die Informationen von einem anderen Server benötigt (z. B. zum Anzeigen der Liste mit Aufgaben aus SharePoint und Exchange Online).

  2. SharePoint fordert und erhält ein Server-zu-Server-Token vom ACS.

  3. SharePoint sendet das Server-zu-Server-Token an den Microsoft 365-Server.

  4. Der Microsoft 365-Server überprüft die Benutzeridentität im Server-zu-Server-Token anhand des ACS.

  5. Der Microsoft 365-Server sendet eine Meldung an SharePoint, um anzugeben, dass das gesendete Server-zu-Server-Token gültig war.

  6. Der Dienst in SharePoint greift auf die Daten auf dem Microsoft 365-Server zu.

  7. Der Dienst in SharePoint rendert die Seite für den Benutzer.

Weitere Informationen finden Sie unter Planen der Server-zu-Server-Authentifizierung in SharePoint Server.