Freigeben über

Authentifizierungsübersicht für SharePoint Server

  • Artikel

 

**Gilt für:**SharePoint Server 2013, SharePoint Server 2016

**Letztes Änderungsdatum des Themas:**2017-06-21

Zusammenfassung: Informationen zur Funktionsweise der Benutzer-, App- und Server-zu-Server-Authentifizierung in SharePoint Server 2013 und SharePoint Server 2016.

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

Inhalt dieses Artikels:

  • Benutzerauthentifizierung in SharePoint Server

  • App-Authentifizierung in SharePoint Server

  • Server-zu-Server-Authentifizierung in SharePoint Server

Benutzerauthentifizierung in SharePoint Server

Die Benutzerauthentifizierung ist die Überprüfung der Identität eines Benutzers anhand eines Authentifizierungsanbieters. Dabei handelt es sich um ein Verzeichnis oder eine Datenbank, die die Anmeldeinformationen des Benutzers enthält und überprüfen kann, ob der Benutzer diese richtig übermittelt hat. Die Benutzerauthentifizierung wird ausgefü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 die Windows-, formularbasierte und die SAML-basierte Forderungsauthentifizierung. Informationen über die Funktionsweise dieser drei Authentifizierungsmethoden finden Sie in den folgenden Videos.

Hinweis

Die Informationen in den Videos gelten für SharePoint Server 2013 und SharePoint Server 2016.

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 im Intranet oder Internet – 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.

Beachten Sie, dass keine App-Authentifizierung erforderlich ist, wenn die SharePoint-App keine gesicherte SharePoint-Ressource zum Rendern der Seite für den Benutzer benötigt. Eine SharePoint-App, die Wettervorhersagen bereitstellt und dazu lediglich auf einen Wetterinformationsserver im Internet zugreifen muss, erfordert z. B. keine App-Authentifizierung.

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

Die Server-zu-Server-Authentifizierung ist die Überprüfung der Ressourcenanforderung eines Servers, die auf einer Vertrauensstellung basiert, die zwischen dem STS des Servers, auf dem SharePoint Server ausgeführt wird, und dem STS eines anderen Servers besteht, der das OAuth-Server-zu-Server-Protokoll unterstützt, z. B. lokal ausgeführte Bereitstellungen von SharePoint Server, Exchange Server 2016, Skype for Business 2016 oder Azure Workflow Service und SharePoint Server, das in Office 365 ausgeführt wird. 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 können Server mit Exchange Server 2016 Ressourcen von einem Server mit SharePoint Server für ein bestimmtes Benutzerkonto anfordern. Bei der App-Authentifizierung hat die App keinen Zugriff auf Anmeldeinformationen von Benutzerkonten. Der Benutzer kann am Server, der die Ressourcenanforderung stellt, derzeit angemeldet sein oder nicht. Dies hängt vom Dienst und der Anforderung ab.

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. Mit der Server-zu-Server-Authentifizierung wird die Vertrauenswürdigkeit des Servers mit SharePoint Server und dem Benutzer überprüft, den er repräsentiert.

Das für die Server-zu-Server-Authentifizierung verwendete Token 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 Office 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 Online und Exchange Online).

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

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

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

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

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

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

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