Dataverse-natives Sicherheitssetup

Vorschau

Dieses Sicherheitsmodell befindet sich derzeit in der Vorschau – sowohl Microsofts zugrundeliegende einheitliche Dataverse-Sicherheitsfunktion als auch Power Portals Pros Unterstützung dafür. Power Portals Pro folgt dem Veröffentlichungsplan von Microsoft: Sobald die Funktion bei Microsoft allgemein verfügbar ist, wird auch die Unterstützung von Power Portals Pro aus der Vorschau verschwinden. Die Vorschaubezeichnung existiert, um etwaige Änderungen zu berücksichtigen, die Microsoft während der Vorschauphase auf seiner Seite vornehmen könnte.

Das Dataverse-native Sicherheitsmodell ermöglicht es Dataverse selbst, die Sicherheit für Ihre Portalnutzer durch standardisierte Sicherheitsrollen durchzusetzen, genau so konfiguriert, wie Power Pages sie konfiguriert – Webrollen und Tabellenberechtigungen. Diese Seite erklärt die komplette Einrichtung von Anfang bis Ende.

Wie das Modell funktioniert und wie es sich auf Berechtigungshandler bezieht, siehe die Sicherheitsübersicht

1. Installation der Power Pages Framework-Komponenten

Das einheitliche Sicherheitsmodell läuft auf Komponenten, die Microsoft in Ihre Dataverse-Umgebung installiert, wenn eine Power Pages-Website erstellt wird. Wenn die Umgebung noch nie eine Power Pages-Seite gehostet hat, erstelle jetzt eine – jede Vorlage funktioniert, und eine Testseite ist in Ordnung. Siehe Websites erstellen und verwalten in der Power Pages-Dokumentation.

Anmerkung

Sie müssen nicht für die Seite bezahlen oder sie am Laufen halten – nachdem die Framework-Komponenten installiert und die Sicherheitsfunktion aktiviert ist, können Sie die Website selbst löschen. Der von Ihrer Konfiguration referenzierte Power Pages-Site-Eintrag (powerpagesite) muss in der Umgebung verbleiben, da Benutzerzuordnungen und Sicherheitsrollen-Synchronisation dagegen eingestellt werden.

2. Unified Dataverse-Sicherheit für die Seite aktivieren

Aktivieren Sie Microsofts einheitliche Dataverse-Sicherheitsfunktion für die Website, indem Sie die Schritte in "Unify Power Pages Security with Dataverse" befolgen. Sobald aktiviert, erstellt die Plattform für jede Webrolle auf der Seite eine gepaarte Dataverse-Sicherheitsrolle (benannt PowerPages_*) und hält sie synchron.

3. Webrollen und Tabellenberechtigungen konfigurieren

In der Power Pages Management-App erstellen (oder anpassen) Sie die Webrollen und Tabellenberechtigungen der Website und verknüpfen Sie jede Tabellenberechtigung mit den Webrollen, die sie erhalten sollten. Dies ist die einzige unterstützte Möglichkeit, unter diesem Modell Zugriff zu gewähren – die Plattform übersetzt die verknüpften Tabellenberechtigungen in Rechte für jede Webrolle in der synchronisierten Sicherheitsrolle jeder Webrolle. Scopes funktionieren genau wie in Power Pages (Global, Kontakt, Konto, ...), daher sind hier auch Zugriffsregeln auf Datensatzebene konfiguriert.

4. Finden Sie Ihre Power Pages-Website-ID

PowerPortalsPro benötigt die ID des powerpagesite Datensatzes der Seite. Sie können sie direkt abfragen – zum Beispiel in einem Browser öffnen <your org url>/api/data/v9.2/powerpagesites?$select=name und die powerpagesiteid Seite kopieren.

5. Bereitstellung in Power Portals Pro aktivieren

Konfigurieren SecurityOptions Sie in Ihren Servern:Program.cs

Die Konfiguration wird beim Start überprüft – wenn ProvisionSystemUsers aktiviert ist, PowerPagesSiteId muss gesetzt und auf einen bestehenden powerpagesite Datensatz aufgelöst werden, sonst startet die Anwendung nicht mit Orientierung. Ab diesem Punkt stellt PowerPortalsPro automatisch ein systemverwaltetes (C2) systemuser und einen powerpagesusermapping Datensatz für jeden Portalkontakt bereit – bei der Registrierung neuer Kontakte und faul bei der Anmeldung für bestehende – und imitiert diesen Nutzer bei jedem Dataverse-Anruf.

6. Web-Rollen an Kontakte zuweisen

Gewähren Sie einzelnen Nutzern den Zugriff, indem Sie Webrollen ihren Kontakten zuweisen – in der Power Pages Management-App oder programmatisch über die powerpagecomponent_mspp_webrole_contact Beziehung. Die Plattform weist die synchronisierten Sicherheitsrollen automatisch zu und entfernt sie, sobald sich die Web-Rollen-Mitgliedschaft ändert.

Tipp

Dataverse speichert die effektiven Rechte jedes Benutzers pro Serverknoten, sodass Rollen- und Privilegienänderungen von wenigen Sekunden bis zu einigen Minuten dauern können, bis sie nach einer Zuweisung in Kraft treten. Berücksichtigen Sie das in Tests und in jedem Flow, der Zugriff gewährt und dann sofort darauf reagiert.

Anonyme Besucher

Ausgeschriebene Besucher werden vom gleichen Modell abgedeckt. Power Pages erstellt automatisch einen anonymen Nutzer für die Seite – einen systemverwalteten Benutzer mit der Identität PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com – und PowerPortalsPro imitiert ihn bei jeder nicht authentifizierten Anfrage. Gewähren Sie anonymen Zugriff auf Power-Pages-Weise: Markieren Sie eine Webrolle als Anonyme Benutzerrolle der Seite in der Power Pages Management-App und verknüpfen Sie Tabellenberechtigungen dazu; Die synchronisierte Sicherheitsrolle bestimmt dann, was ausgeloggte Besucher sehen können.

Anmerkung

Der Anonyme Nutzer wird von Power Pages faul erstellt, sodass Seiten, die vor der einheitlichen Sicherheitsfunktion erstellt wurden, möglicherweise noch keine haben (er wird über die kontaktlosen powerpagesusermapping Datensätze der Seite entdeckt – der Nutzer selbst ist für Attributsanfragen unsichtbar – und ein Kandidat wird erst akzeptiert, nachdem seine Identität mit dem bekannten Anonymous-Benutzernamen überprüft wurde). Wenn es nicht gefunden werden kann, greifen anonyme Besucher auf portalseitige Berechtigungshandler zurück – also kein anonymer Datenzugriff , es sei denn, die Handler sind registriert – und das Framework protokolliert das Ergebnis beim Start und versucht es regelmäßig erneut.

Wie sieht es mit Permission-Handlern aus?

Sitzungen unter diesem Modell werden komplett umgangen ITablePermissionHandler – ITableRecordPermissionHandler genau wie interne systemuser Anmeldungen –, weil Dataverse die Sicherheit nativ über die Rollen des personierten Nutzers durchsetzt. Du musst keinen Code für Berechtigungshandler schreiben oder registrieren. Handler gelten weiterhin für Sitzungen, die nicht von einem nachgeahmten Systemnutzer unterstützt werden (die Funktion deaktiviert, eine Sitzung, bei der die Bereitstellung fehlschlug und das Framework auf portalseitige Sicherheit zurückfiel, oder anonyme Besucher auf einer Seite ohne den anonymen Benutzer), sodass bestehende handlerbasierte Portale schrittweise migrieren können.

Unterscheidung bereitgestellter Benutzer in Ihrer Benutzeroberfläche

Sitzungen tragen einen PortalUserType Anspruch mit dem ganzzahligen Wert des PortalUserType Enums: Contact (klassischer Portalbenutzer), SystemUser (echte interne Anmeldung) oder ContactStubUser (ein Kontakt, der von einem bereitgestellten systemverwalteten Benutzer unterstützt wird); ContactStubUser Sitzungen tragen zusätzlich einen SystemUserId Anspruch mit der bereitgestellten Benutzer-ID, der aus dem autoritativen powerpagesusermapping Datensatz gelöst wird. Dasselbe Enum wird durch GET /api/auth/me als CurrentUserInfo.PortalUserTypezurückgegeben. Verwenden Sie die GetPortalUserType() und-Erweiterungen GetDataverseSystemUserId() auf ClaimsPrincipal, und präsentieren Sie niemals eine ContactStubUser Sitzung als interner Benutzer.

API-Referenz