Freigeben über

Nur-App und erhöhte Rechte im SharePoint-Add-In-Modell

  • Artikel

Der Ansatz für das Erhöhen von Rechten in Ihrem Code unterscheidet sich im neuen SharePoint-Add-In-Modell von der Vorgehensweise bei voll vertrauenswürdigem Code. In einem typischen Szenario mit voll vertrauenswürdigem Code (Full Trust Code, FTC)/Farmlösung wird die RunWithElevatedPrivileges-API mit dem serverseitigen SharePoint-Objektmodellcode erstellt und über Farmlösungen bereitgestellt.

In ein SharePoint-Add-In-Modellszenario wird die AllowAppOnlyPolicy-Berechtigung oder ein Dienstkonto verwendet, um zuzulassen, dass der aktuelle Benutzer Vorgänge ausführen kann, zu deren Ausführung er nicht autorisiert ist.

Allgemeine Richtlinien

Als Faustregel werden die folgenden allgemeinen Richtlinien für das Erhöhen von Rechten in Code bereitgestellt.

  • AllowAppOnlyPolicy funktioniert nicht mit der

    • Suche, wenn das Ziel SharePoint lokal ist. SharePoint Online-Unterstützung dafür wurde hinzugefügt (Blogbeitrag)

    • CSOM-Operationen des Benutzerprofils, mit der Ausnahme, dass die Massenaktualisierungs-API des Benutzerprofils mit reinen App-Berechtigungen verwendet werden kann

    • Aktualisieren von Taxonomiediensteinträgen (Schreiben) – Lesen funktioniert

      Hinweis

      In den folgenden Szenarien müssen Sie ein spezielles Dienstkonto verwenden.

  • AllowAppOnlyPolicy ähnelt RunWithElevatedPrivileges, ist aber nicht genau gleich.

    • AllowAppOnlyPolicy führt Code basierend auf den für das SharePoint-Add-In erteilten Berechtigungen aus, nicht im Auftrag eines anderen Benutzers, der über die entsprechenden Berechtigungen zum Ausführen eines Vorgangs verfügt.

Nachfolgend finden Sie ein Beispiel zum Zurückgeben einer Nur-App-Richtlinie und deren Verwendung zum Erstellen eines Kontextobjekts.

Uri siteUrl = new Uri(ConfigurationManager.AppSettings["MySiteUrl"]);
try
  {
    //Connect to the give site using App Only token
    string realm = TokenHelper.GetRealmFromTargetUrl(siteUrl);
    var token = TokenHelper.GetAppOnlyAccessToken(TokenHelper.SharePointPrincipal, siteUrl.Authority, realm).AccessToken;

    using (var ctx = TokenHelper.GetClientContextWithAccessToken(siteUrl.ToString(), token))
    {
      // Perform operations using the app only token access.
    }
  }
  catch (Exception ex)
  {
    Console.WriteLine("Error in execution: " + ex.Message);
  }

  • Bei Verwendung der AllowAppOnlyPolicy sollten Sie beachten, dass diese nur in vom Anbieter gehosteten SharePoint-Add-Ins funktioniert.

  • Bei AllowAppOnlyPolicy wird Code nicht im Auftrag eines Benutzers ausgeführt und ist daher möglicherweise nicht für alle Szenarien geeignet.

  • Dienstkonten werden in SharePoint definiert.

    • In einem Office 365-Mandaten benötigen die Dienstkonten, abhängig von den Funktionen Ihrer Codeanforderungen, eine Office 365-Lizenz.

    • Sie können Dienstkonten pro SharePoint-Add-In erstellen oder ein einziges Konto für alle SharePoint-Add-Ins verwenden.

    • Erstellen Sie eindeutige und aussagekräftige Namen für die Dienstkonten, damit Sie die Operationen einfacher nachverfolgen können, die sie ausführen.

      Beispiel: Wenn Ihr SharePoint-Add-In Listenelemente ändert, zeigt die Spalte „Geändert von“ für die Listenelemente den Namen des Dienstkontos für das SharePoint-Add-In an.

  • Bei der Authentifizierung für Dienstkonten müssen Sie einen Benutzernamen und ein Kennwort für das Dienstkonto abrufen.

    • Der folgende Codeausschnitt veranschaulicht die Verwendung eines Benutzernamens und eines Kennworts zur Authentifizierung.

    • Setzen Sie beim Speichern und Abrufen des Benutzernamens und Kennworts auf Sicherheit.

      using (ClientContext context = new ClientContext("https://tenancy.sharepoint.com"))
{

  // Use default authentication mode
  context.AuthenticationMode = ClientAuthenticationMode.Default;
  // Specify the credentials for the account that will execute the request
  context.Credentials = new SharePointOnlineCredentials("User Name", "Password");
}

Optionen zum Erhöhen der Berechtigungen

Es gibt eine Reihe von Optionen, um Berechtigungen zu erhöhen.

  • OAuth (AllowAppOnlyPolicy)
    • S2S (Unteroption)
    • ACS (Unteroption)
  • Dienstkonto
    • Remote gehosteter Code (Beispiel: Azure WebJob)

Wichtig

Die Verwendung von Azure ACS (Access Control Services) für SharePoint Online wurde am 27. November 2023 eingestellt. Weitere Informationen finden Sie in der Ankündigung zur vollständigen Einstellung. Die Verwendung von Azure ACS außerhalb des SharePoint-Kontexts wurde bereits am 7. November 2018 eingestellt und endet jetzt.

Die Einstellung bedeutet, dass das Feature keine neuen Investitionen erhält, aber weiterhin unterstützt wird. Ende der Lebensdauer bedeutet, dass das Feature nicht mehr zur Verfügung steht.

OAuth (AllowAppOnlyPolicy)

Bei dieser Option wird die AllowAppOnlyPolicy im AppPermissionRequests-Element auf „true“ festgelegt, und Berechtigungen werden im SharePoint-Add-In-Manifest festgelegt. OAuth wird verwendet, um Zugriffstoken zurückzugeben, um dem SharePoint-Add-In zu ermöglichen, Vorgänge auszuführen, für die es über Berechtigungen verfügt.

S2S-Unteroption

Die S2S-Unteroption funktioniert nur in lokalen SharePoint-Umgebungen.

Bei der Authentifizierung über OAuth in einem S2S-Szenario wird die TokenHelper::GetS2SAccessTokenWithWindowsIdentity-Methode wird verwendet, um das Zugriffstoken für das SharePoint-Add-In zurückzugeben. Das Zugriffstoken ermöglicht dem SharePoint-Add-In, alle Vorgänge auszuführen, die dem SharePoint-Add-In im SharePoint-Add-In-Manifest gewährt wurden.

Diese Option wird nicht im Auftrag eines Benutzers ausgeführt und ist daher möglicherweise nicht für alle Szenarien geeignet.

Wann ist die Option geeignet?

Wenn Sie in einem SharePoint-S2S-Szenario Berechtigungen erhöhen müssen, ist dies eine gute Option, da sie mit S2S funktioniert und sehr einfach zu implementieren ist.

Erste Schritte

Im folgenden Artikel wird veranschaulicht, wie AllowAppOnlyPolicy bei S2S verwendet wird.

ACS-Unteroption

Die ACS-Unteroption funktioniert in lokalen und Office 365-SharePoint-Umgebungen.

Bei der Authentifizierung über OAuth in einem ACS-Szenario wird die TokenHelper::GetAppOnlyAccessTokenmethod-Methode wird verwendet, um das Zugriffstoken für das SharePoint-Add-In zurückzugeben. Anschließend wird die TokenHelper::GetClientContextWithAccessToken-Methode aufgerufen, um den Clientkontext aufzurufen, der zum Durchführen von Vorgängen erforderlich ist, für die dem SharePoint-Add-In Berechtigungen basierend auf den im SharePoint-Add-In-Manifest gewährten Berechtigungen erteilt wurden.

Diese Option wird nicht im Auftrag eines Benutzers ausgeführt und ist daher möglicherweise nicht für alle Szenarien geeignet.

Wann ist die Option geeignet?

Wenn Sie in einem SharePoint-ACS-Szenario Berechtigungen erhöhen müssen, ist dies eine gute Option, da sie mit ACS funktioniert und sehr einfach zu implementieren ist. Diese Option ist geeignet, wenn Sie eine lokale SharePoint-Umgebung haben, die eine Vertrauensstellung mit ACS aufgebaut hat. Dies ist die einzige OAuth-Option, wenn sie über eine Office 365-SharePoint-Umgebung verfügen.

Erste Schritte

Im folgenden Artikel wird veranschaulicht, wie AllowAppOnlyPolicy bei ACS verwendet wird.

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.

Dienstkonto

In diesem Muster wird die SharePointOnlineCredentials-Klasse verwendet, um den Kontext eines Benutzers einzurichten, der Code ausführt.

Wann ist die Option geeignet?

Wenn Sie Code im Auftrag eines bestimmten Benutzers (Dienstkonto) ausführen müssen, ist dies eine gute Option, da Aktionen im Benutzerkonto (Dienstkonto) und unter den Berechtigungen des SharePoint-Add-Ins ausgeführt werden.

Erste Schritte

Im folgenden Artikel wird die SharePointOnlineCredentials-Klasse veranschaulicht, um den Kontext eines Benutzers einzurichten, der Code ausführt.

Gilt für

  • Office 365 mit mehreren Mandanten (MT)
  • Office 365 dediziert (D) teilweise
  • SharePoint 2013 lokal – teilweise

Muster für dedizierte und lokale Umgebungen sind identisch mit SharePoint-Add-In-Modelltechniken, aber es gibt Unterschiede bezüglich der verwendbaren Technologien.