Planen der App-Authentifizierung in SharePoint Server
**Gilt für:**SharePoint 2013, SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016
**Letztes Änderungsdatum des Themas:**2018-03-05
Zusammenfassung: Informationen zur Planung der App-Authentifizierung in SharePoint 2013 und SharePoint Server 2016.
Bei der App-Authentifizierung handelt es sich um die Überprüfung der Identität einer externen App für SharePoint sowie der Autorisierung von sowohl dieser App als auch verbundener Benutzer, wenn die App Zugriff auf eine sichere SharePoint-Ressource anfordert. App-Authentifizierung tritt auf, wenn eine externe Komponente einer SharePoint Store-App oder einer App-Katalog, wie z. b. ein Webserver, der sich im Intranet oder im Internet befindet, versucht, auf eine sichere SharePoint-Ressource zuzugreifen. So gilt beispielsweise eine App für SharePoint, die eine Komponente enthält, die in Microsoft Azure ausgeführt wird, als externe App. App-Authentifizierung ermöglicht eine Reihe neuer Funktionen und Szenarien, die erzielt werden können, indem Apps die Möglichkeit erhalten, Daten aus SharePoint-Ressourcen in die verarbeiteten Ergebnisse einzubeziehen und diese Benutzern anzuzeigen.
Zur Bereitstellung der von einer App für SharePoint angeforderten Ressourcen muss der Server, auf dem SharePoint Server ausgeführt wird, folgende Schritte durchführen:
Überprüfen der Vertrauenswürdigkeit der anfordernden App.
Zum Authentifizieren der anfordernden App müssen Sie den Server, auf dem SharePoint Server ausgeführt wird, so konfigurieren, dass der App vertraut wird, wenn diese die Anfrage sendet. Dies ist eine unidirektionale Vertrauensbeziehung.
Sicherstellen, dass der von der App angeforderte Zugriffstyp autorisiert ist.
Zur Autorisierung des Zugriffs vertraut SharePoint Server auf eine Reihe festgelegter App-Berechtigungen, die bei der Installation in der App-Manifestdatei angegeben wurden, sowie auf die Berechtigungen, die mit dem Benutzer verbunden sind, in dessen Namen die App ausgeführt wird. SharePoint Server basiert weiterhin auf den Berechtigungen, die SPAppPrincipal gewährt wurden, als die Vertrauensstellung mithilfe des Set-SPAppPrincipalPermission PowerShell-Cmdlets hergestellt wurde.
Beachten Sie, dass die App-Authentifizierung in SharePoint Server von der Benutzerauthentifizierung unabhängig ist und dass sie nicht als Authentifizierungsprotokoll für die Anmeldung von SharePoint-Benutzern verwendet wird. App-Authentifizierung verwendet das Open Authorization (OAuth) 2.0-Protokoll und fügt keine Authentifizierungsebene zum Satz der Benutzerauthentifizierungs- oder Anmeldeprotokolle, wie WS-Federation, hinzu. Es sind keine neuen Benutzerauthentifizierungsprotokolle in SharePoint Server verfügbar. App-Authentifizierung und OAuth werden nicht in den Identitätsanbieterlisten aufgeführt.
Inhalt dieses Artikels:
Einführung
Feststellen der vertrauenswürdigen Beziehungen
Auswählen der Benutzerauthentifizierungsmethoden für lokale Apps
Bereitstellen des eingehenden Zugriffs aus externen Anwendungen, die das Internet hostet
Überlegungen zu Adressbenutzerprofil-Anwendungsdiensten
Einführung
Die Planung der App-Authentifizierung besteht aus den folgenden Aufgaben:
Feststellen der vertrauenswürdigen Beziehungen, die Sie auf einer Farm konfigurieren müssen, auf der SharePoint Server ausgeführt wird, und die den externen Apps entsprechen, die Anfragen an SharePoint-Ressourcen stellen werden.
Bereitstellen des eingehenden Zugriffs aus externen Anwendungen, die im Internet gehostet werden.
Wichtig
Die Webanwendungen, die App-Authentifizierungsendpunkte enthalten (für eingehende Anfragen von Apps für SharePoint) müssen so konfiguriert werden, dass sie Secure Sockets Layer (SSL) verwenden. Sie können OAuth in SharePoint Server so konfigurieren, dass SSL nicht erforderlich ist. Wir empfehlen dies jedoch nur für Testzwecke, zur Vereinfachung der Konfiguration oder zum Erstellen einer App-Entwicklungsumgebung.
Hinweis
Sie müssen nur App-Authentifizierung für eine SharePoint-Farm planen, wenn Sie eine oder mehrere externe Apps für SharePoint verwenden, die deren Ressourcen benötigen.
Feststellen der vertrauenswürdigen Beziehungen
Sie müssen die SharePoint-Farm so konfigurieren, dass sie Zugriffstoken vertraut, wenn diese von Ressourcenanfragen stammen, die von den folgenden externen App-Typen gesendet werden:
Von Anbietern gehostete Apps werden auf eigenen Servern im Internet oder Intranet ausgeführt, sie werden in Microsoft Azure registriert, und sie verwenden ACS, um das Zugriffstoken abzurufen.
Bei von Anbietern gehosteten Apps müssen Sie die SharePoint-Farm so konfigurieren, dass sie der ACS-Instanz der vom Anbieter gehosteten App vertraut.
Apps mit hoher Vertrauenswürdigkeit werden auf eigenständigen Servern in Ihrem Intranet ausgeführt, und sie verwenden ein Signaturzertifikat zur digitalen Signierung der Zugriffstoken, die von den Apps generiert werden.
Apps mit hoher Vertrauenswürdigkeit verwenden das Server-zu-Server-Protokoll, um im Namen eines Benutzers Ressourcen anzufordern. Konfigurieren Sie für Apps mit hoher Vertrauenswürdigkeit die SharePoint-Farm mit dem JSON (JavaScript Object Notation)-Metadatenendpunkt des Servers, der die App hostet. Sie können die Vertrauensstellung auch manuell konfigurieren. Weitere Informationen finden Sie unter Konfigurieren der App-Authentifizierung in SharePoint Server 2013
Weitere Informationen zu Apps mit hoher Vertrauenswürdigkeit finden Sie unter Gewusst wie: Erstellen besonders vertrauenswürdiger Apps für SharePoint 2013 unter Verwendung des Server-zu-Server-Protokolls.
Auswählen der Benutzerauthentifizierungsmethoden für lokale Apps
Bei einer lokalen App handelt es sich entweder um eine anbietergehostete App, die auf einem lokalen Server gehostet wird, oder um eine von SharePoint gehostete App. In Tabelle 1 werden die verschiedenen Benutzerauthentifizierungsmethoden von SharePoint Server aufgeführt; außerdem wird angegeben, ob eine bestimmte Methode für lokale SharePoint Server-Apps verwendet werden kann.
Tabelle 1. Benutzerauthentifizierungsmethoden und Unterstützung durch lokale Apps
| Authentifizierungsmethode | Von in SharePoint gehosteten Apps unterstützt | Von vom Anbieter gehosteten Apps unterstützt |
|---|---|---|
NTLM |
Ja |
Ja |
Kerberos |
Ja, aber nur bei Konfiguration für die Verwendung von NTLM als Ausweichauthentifizierungsmethode. Kerberos allein wird nicht unterstützt. |
Ja |
Standard |
Ja |
Ja |
Anonym |
Ja |
Ja |
Formularbasierte Authentifizierung unter Verwendung des Standardanbieters von ASP.NET |
Ja |
Ja |
Formularbasierte Authentifizierung unter Verwendung des Lightweight Directory Access-Protokolls (LDAP) |
Ja |
Ja |
SAML (Security Assertion Markup Language)-Authentifizierung |
Ja, wenn der Identitätsanbieter Platzhalter bei der Rückgabe-URL-Registrierung unterstützt und den wreply-Parameter berücksichtigt. Wenn Sie SharePoint Server für das Verwenden des wreply-Parameters konfigurieren möchten, geben Sie die folgenden Befehle an der Microsoft PowerShell-Eingabeaufforderung ein: Hinweis Die Active Directory-Verbunddienste (AD FS) 2.0-Version unterstützt keine Platzhalter bei der Rückgabe-URL-Registrierung. |
Ja |
Weitere Informationen zu Benutzerauthentifizierungsmethoden in SharePoint Server finden Sie unter Planen der Benutzerauthentifizierungsmethoden in SharePoint Server.
Bereitstellen des eingehenden Zugriffs aus externen Anwendungen, die das Internet hostet
Wenn externe von einem Anbieter gehostete Apps sich im Internet befinden, müssen Sie einen umgekehrten Webproxy konfigurieren, der die App-Authentifizierung ausführt und Ressourcen von Intranet-SharePoint-Farmen anfordert. Ein konfigurierter umgekehrter Webproxy am Rand des Netzwerks muss eingehende HTTPS-Verbindungen (HTTP über SSL) von den Apps zu den SharePoint-Farmen zulassen. Normalerweise erkennen Sie die HTTPS-basierten URLs, auf die die externen Apps zugreifen, und konfigurieren den umgekehrten Proxy so, dass diese URLs unter Bereitstellung der angemessenen Sicherheit veröffentlicht werden.
Überlegungen zu Adressbenutzerprofil-Anwendungsdiensten
Apps mit hoher Vertrauenswürdigkeit generieren ihre eigenen Zugriffstoken, die eine Assertion der Identität des Benutzers enthalten, in dessen Namen die Apps ausgeführt werden. Der Server, auf dem SharePoint Server ausgeführt wird und der die eingehenden Ressourcenanforderungen verarbeitet, muss die Anforderung mit einem bestimmten SharePoint-Benutzer auflösen, ein Vorgang, der auch „Aktivieren der Identität des Benutzers“ genannt wird. Beachten Sie, dass sich dieser Vorgang von der App-Authentifizierung für von Anbietern gehostete Apps unterscheidet, bei denen eine Erkennung des Benutzers, jedoch keine Assertion erfolgt.
Um die Identität eines Benutzers zu aktivieren, verwendet ein Server, auf dem SharePoint Server ausgeführt wird, die Ansprüche des eingehenden Zugriffstokens und löst diese mit einem bestimmten SharePoint-Benutzer auf. Standardmäßig verwendet SharePoint Server die integrierte Benutzerprofildienst-Anwendung zur Identitätsauflösung.
Im Folgenden sind die Hauptbenutzerattribute für die Aktivierung der Benutzeridentität aufgeführt:
Die Windows-Sicherheits-ID (SID)
Der Benutzerprinzipalname (UPN) für Active Directory-Domänendienste (AD DS)
Die SMTP-Adresse (Simple Mail Transfer Protocol)
Die SIP-Adresse (Session Initiation Protocol)
Die App muss daher mindestens eines dieser Benutzerattribute enthalten, und dieses Attribut muss sich in den Benutzerprofilen befinden. Wir empfehlen eine regelmäßige Synchronisierung der Identitätsspeicher mit der Benutzerprofildienst-Anwendung.
Weiterhin geht SharePoint Server von nur einem Eintrag für eine vorhandene Suchanfrage in der Benutzerprofildienst-Anwendung aus, die auf einem oder mehreren dieser vier Attribute basiert. Andernfalls wird eine Fehlerbedingung zurückgegeben, dass mehrere Benutzerprofile gefunden wurden. Sie sollten daher nicht mehr benötigte Benutzerprofile regelmäßig in der Benutzerprofildienst-Anwendung löschen, um mehrfach vorhandene Benutzerprofile zu vermeiden.
Wenn für einen Benutzer ein Benutzerprofil vorhanden ist und die betreffenden Gruppenmitgliedschaften nicht synchronisiert werden, wird der Zugriff möglicherweise verweigert, wenn dem Benutzer Zugriff auf eine bestimmte Ressource gewährt werden sollte. Sie sollten daher sicherstellen, dass Gruppenmitgliedschaften mit der Benutzerprofildienst-Anwendung synchronisiert werden.