Erstellen von SharePoint Embedded-Anwendungen

  • 6 Minuten

Entwickler können Anwendungen erstellen, die die leistungsstarken Datei- und Dokumentverwaltungsfunktionen in SharePoint über SharePoint Embedded nutzen. Diese Arten von Anwendungen verfügen über zwei unterschiedliche Komponenten.

  • Eine Komponente ist für die Ausführung von CRUD-Vorgängen für SharePoint Embedded mithilfe von Microsoft Graph-APIs verantwortlich.
  • Die andere Komponente implementiert die Schnittstelle für Benutzer, um die in SharePoint Embedded gespeicherten Dokumente zu nutzen und zu speichern.

Einführung in SharePoint Embedded

SharePoint Embedded bietet Entwicklern eine schnellere Möglichkeit, Datei- und Dokumentanwendungen zu erstellen. SharePoint Embedded wird von SharePoint unterstützt. Entwickler können die gleichen leistungsstarken Datei- und Dokumentfunktionen integrieren, die SharePoint in ihren eigenen benutzerdefinierten Anwendungen bietet.

Eine weitere Möglichkeit, SharePoint Embedded zu betrachten, ist, dass Ihre benutzerdefinierte Anwendung SharePoint für alle Dokumentspeicher- und Zusammenarbeitsfunktionen verwendet. Dadurch wird SharePoint Embedded effektiv als "headless-API" für das Dokumentspeichersystem von SharePoint verwendet.

App-Dokumente verbleiben in ihrem Microsoft 365-Mandanten

Wenn ein Consumer eine SharePoint Embedded-Anwendung in ihrem Microsoft 365-Mandanten installiert/registriert, erstellt SharePoint Embedded eine weitere SharePoint-Partition. Diese Speicherpartition verfügt nicht über eine Benutzeroberfläche, aber stattdessen sind die Dokumente in der Partition nur über APIs zugänglich. Dies bedeutet, dass alle Dokumente für den ISV oder die Anwendung des Entwicklers zugänglich sind, die Dokumente sich jedoch nur im Microsoft 365-Mandanten des Consumers befinden.

Microsoft 365-Consumereinstellungen gelten für App-Dokumente

Alle Dokumente, die in der SharePoint-Partition gespeichert sind, die von der SharePoint Embedded-App erstellt wurde, befinden sich im Microsoft 365-Mandanten des Consumers und unterliegen daher den Microsoft 365-Mandanteneinstellungen des Consumers.

Grundlegendes zu verschiedenen Typen von App-Berechtigungen und dem Fluss "Im Auftrag von"

Beim Erstellen von Anwendungen für den Zugriff auf REST-APIs wie Microsoft Graph und SharePoint Online erfordern verschiedene Aufgaben unterschiedliche Zugriffstypen. Um dies zu beheben, ist OAuth v2.0 ein offener Standard für die Autorisierung, die für den API-Zugriff verwendet wird, einschließlich Microsoft Graph und SharePoint Online. Sie bietet Anwendungen delegierten Zugriff auf geschützte Ressourcen im Namen eines Benutzers. Dies umfasst zwei Arten von Berechtigungen: App+Benutzer (auch als delegierte Bezeichnet) und Nur App (oder Anwendung).

  • App+Benutzerberechtigungen (oder delegierte Berechtigungen): Bei diesem Modell handelt es sich um ein Zwei-Parteien-Berechtigungsmodell. Die Anwendung führt Aufgaben aus und ruft APIs im Namen eines angemeldeten Benutzers auf. Die Anwendung erhält delegierte Berechtigungen von dem Benutzer, der sich bei ihr anmeldet, und erbt die Berechtigungen, über die der Benutzer verfügt, einschließlich aller Einschränkungen, z. B. nicht auf bestimmte Daten zugreifen oder bestimmte Aktionen ausführen zu können. Diese spiegeln die Aufgaben wider, die der Benutzer der App während der Sitzung in ihrem Namen gestattet hat.

    Beispielsweise kann einer App die Berechtigung erteilt werden, eine E-Mail im Namen eines Benutzers zu senden, aber wenn der Benutzer nicht über die Berechtigung zum Senden einer E-Mail verfügt, kann die App sie auch nicht senden.

    Diese Art von Berechtigung wird häufig verwendet, wenn Ihre App wie der angemeldete Benutzer funktioniert, für Anwendungsszenarien, in denen die Interaktion im Namen eines Benutzers erfolgt und die Berechtigungen je nach Benutzer variieren sollten, der die Zustimmung erteilt.

  • Nur App-Berechtigungen (oder Anwendungsberechtigungen): Dagegen werden nur App-Berechtigungen verwendet, wenn eine App unabhängig von einem Benutzer auf Ressourcen zugreifen muss. Die Anwendung erhält die Berechtigungen, die sich selbst direkt gewährt werden, unabhängig von den Benutzerberechtigungen. Sie ermöglicht der Anwendung den Zugriff auf den API-Dienst mit eigener Identität und eigenen Berechtigungen. Dies ist ideal für Hintergrunddienste oder Daemons, die unabhängig von einer Benutzersitzung ausgeführt werden.

Wenn Sie z. B. über eine Anwendung verfügen, die auf alle Dateien in einer Dokumentbibliothek zugreifen muss, sind auch solche, die nicht für benutzerseitig freigegeben sind, nur App-Berechtigungen die richtige Wahl.

Anwendungsberechtigungen können nur von einem Administrator eingewilligt werden, da sie häufig höhere Berechtigungen gewähren.

Zusätzlich zu diesen beiden Optionen kann ein dritter OAuth 2.0-Flow, On-Behalf-Of (auch als OBO-Flow bezeichnet) verwendet werden, wenn eine Anwendung eine Aufgabe im Namen des Benutzers ausführen muss. So funktioniert der gesamte OBO-Fluss:

  1. Eine Clientanwendung authentifiziert sich beim Autorisierungsserver (z. B. Microsoft Entra ID) und fordert ein Zugriffstoken für eine API an (z. B. den API-Server unseres Projekts).
  2. Der Benutzer meldet sich an und ermöglicht der Anwendung, in ihrem Namen zu handeln.
  3. Die Clientanwendung empfängt ein Zugriffstoken und ein Aktualisierungstoken, das die Sitzung des Benutzers darstellt.
  4. Wenn die Clientanwendung einen anderen Dienst wie SharePoint Online im Namen des Benutzers aufrufen muss, sendet sie das Zuvor Authorization im HTTP-Header abgerufene Zugriffstoken.
  5. Unsere serverseitige API überprüft das Zugriffstoken und verarbeitet die Anforderung. Wenn ein anderer Dienst (z. B. SharePoint Online) im Namen des Benutzers aufgerufen werden muss, ruft er ein Token von Microsoft Entra ID ab, indem dieses bereits abgerufene Token angezeigt wird.
  6. Microsoft Entra ID gibt ein "neues" Zugriffstoken für SharePoint Online aus, das der API-Server unseres Projekts jetzt zum Aufrufen von SharePoint Online verwenden kann.

In einem praktischen Szenario mit Microsoft Graph oder SharePoint Online ist es nicht ideal, die Anwendung für jeden einzelnen Vorgang anzumelden, wenn ein Benutzer möchte, dass eine App auf seinen Kalender zugreifen kann. Stattdessen muss sich der Benutzer mit dem OBO-Fluss nur einmal authentifizieren, und die Anwendung führt alle autorisierten Vorgänge in ihrem Namen aus.

Daher vereinfacht der OBO-Flow die Benutzererfahrung und erhöht die Sicherheit des Systems, indem sichergestellt wird, dass Berechtigungen bei jeder Aufrufkette überprüft werden.

Zusammenfassung

In diesem Abschnitt haben Sie die ersten Schritte zum Erstellen einer Webanwendung ausgeführt, die CRUD-Vorgänge für einen SharePoint Embedded-Container ausführt.