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.

In diesem Modell hört das Portal auf zu entscheiden, was ein Nutzer tun darf, und Dataverse entscheidet stattdessen. Jeder Portal-Kontakt wird von seinem eigenen Dataverse-Nutzer unterstützt, jede Anfrage wird als dieser Nutzer gestellt, und der Zugriff erfolgt nach dem, was die Sicherheitsrollen dieses Benutzers erlauben – das gleiche Sicherheitsmodell, das eine modellgetriebene App steuert. Nichts im Portal wird konsultiert, und nichts im Portal kann es erweitern. Der Haken ist, woher diese Rollen kommen: Dataverse erlaubt einem bereitgestellten Portal-Nutzer nur eine Rolle, die von der Plattform generiert wurde, und das Einzige, was sie generiert, ist Power Pages. Dieses eine Modell stützt sich also auf Power Pages auf eine Weise, wie es der Rest von Power Portals Pro nie tut – Schritt 3 erklärt genau, wie weit das geht.

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

1. Installation der Power Pages Framework-Komponenten

Die Unterstützung eines Kontakts mit einem Dataverse-Nutzer beruht auf einer Plattformfähigkeit, die nur existiert, wenn sich die Power Pages-Komponenten in der Umgebung befinden: der systemverwaltete Benutzer, ein Benutzerdatensatz, der keine Lizenz kostet und zur Imitation existiert. Wenn die Umgebung noch nie eine Power Pages-Seite beherbergt hat, erstellen Sie jetzt eine – jede Vorlage funktioniert, und eine Testseite ist in Ordnung. Siehe Erstellen und verwalten Sie eine Website. Aus diesen Komponenten ergibt sich zwei Dinge: der Benutzer, der von jedem Kontakt unterstützt wird, und die Sicherheitsrollen, die dieser Nutzer innehaben darf.

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 Power Pages Site-Eintrag (powerpagesite) auf den Ihre Konfiguration referenziert bleibt, da jeder bereitgestellte Benutzer in einer powerpagesusermapping Reihe dagegen gespeichert wird – der Link zwischen einem Kontakt und dem Dataverse-Nutzer, der dafür steht.

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. Zugang mit Webrollen und Tabellenberechtigungen gewähren

Der Zugriff erfolgt durch die Sicherheitsrollen, die der Dataverse-Nutzer hinter jedem Kontakt einnimmt – aber das sind keine Rollen, die man schreiben kann. Dataverse akzeptiert nur eine systemgenerierte Rolle auf einem bereitgestellten Portalnutzer, und das Einzige, was diese generiert, ist die Funktion, die Sie in Schritt 2 aktiviert haben: Es erstellt eine gepaarte PowerPages_* Rolle für jede Webrolle auf der Website, und die Plattform weist sie zu und entzuweisen, sobald sich die Webrollenmitgliedschaft eines Kontakts ändert. Was ein Portalnutzer erreichen kann, wird daher von der Webrolle und den damit verbundenen Tabellenberechtigungen bestimmt – in der Power Pages Management-App oder mit der Power Portals Pro Enhanced Authorization Lösung installiert, auf der eigenen Webrollen-Seite Ihres Portals . Das ist der einzige Ort in Power Portals Pro, an dem ein Power Pages-Konzept entscheidet, was jemand erreichen kann, und es ist die Anforderung der Plattform und nicht unser Design. Welche Datensätze ein Benutzer erreicht, wird durch den Umfang jeder Tabellenberechtigung bestimmt, nicht durch die Besitzertiefe: Jedes Privileg einer generierten Rolle trägt einen Plattformdatensatzfilter, der davon abgeleitet ist. Das Lesen einer Tabelle kann in eine andere hineingreifen – das Lesen eines Kontos liest auch dessen Adressen – daher benötigen auch diese zugehörigen Tabellen Tabellenberechtigungen. Siehe Tabellenberechtigungen.

Anmerkung

Warum man nicht einfach eine von dir selbst erstellte Rolle zuweisen kann. Verifiziert in einer sauberen Umgebung: Die Zuweisung einer gewöhnlichen Sicherheitsrolle an einen bereitgestellten Portal-Nutzer scheitert mit "Der systemverwaltete Benutzertyp ist für die zugewiesene Rolle nicht gültig", und das Erstellen einer von der API systemgenerierten Rolle markiert wird mit "Ungültige Operation durchgeführt" abgelehnt. Die Einschränkung bezieht sich speziell auf den Benutzertyp, den das Portal bereitstellt – andere systemverwaltete Benutzer, wie ein Anwendungsnutzer, übernehmen gewöhnliche Rollen ohne Beschwerden.

4. Nutzern ihre Web-Rollen geben

Ein Kontakt erhält den Zugriff auf eine Webrolle, indem er die Webrolle hält. Um Webrollen automatisch an neue Nutzer zu übertragen, installieren Sie die Power Portals Pro Enhanced Authorization-Lösung und fügen Sie Regeln auf der Web-Rollen-Seite Ihres Portals hinzu (WebRoleAdmin, enthalten in beiden Projektvorlagen): Jede Regel gibt jedem neuen Nutzer eine Webrolle oder denen, die einer FetchXML-Regel über Kontakte entsprechen. Regeln werden einmal pro Kontakt ausgeführt – wenn das Portal sie registriert und wenn sich ein bestehender Kontakt erstmals mit einem externen Login anmeldet – sodass eine Webrolle, die ein Administrator später entfernt, entfernt bleibt. Sie können Webrollen auch manuell in der Power Pages Management-App zuweisen.

Anmerkung

Die Enhanced Authorization-Lösung ist getrennt von Power Portals Pro Core, da sie von Power Pages abhängt. Um Webrollen zuzuweisen, benötigt der Anwendungsbenutzer Read on the Web Role Configuration table, Read and AppendTo on Web Roles sowie Read, Append and AppendTo on site components (powerpagecomponent), wobei Power Pages Webrollen speichert. Die Web Roles-Seite läuft als angemeldeter Administrator, und Dataverse erlaubt nur das, was sowohl er als auch der Anwendungsbenutzer tun dürfen, sodass der Anwendungsbenutzer zusätzlich Erstellen, Schreiben, Löschen und Anhängen in der Konfigurationstabelle benötigt; Erstellen, Schreiben, Löschen und Anhängen auf Webrollen; Erstellen, Lesen, Schreiben, Löschen, Anfügen und Anhängen auf Tabellenberechtigungen (mspp_entitypermission); Erstellen, Schreiben und Löschen auf Standortkomponenten; und AppendTo auf Websites (mspp_website), da jede Webrolle und Tabellenberechtigung die Seite, zu der sie gehört, benannt wird.

5. 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.

6. 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.

7. Überprüfe, was ein Nutzer tatsächlich tun kann

Ein bereitgestellter Nutzer wird beim ersten Anmelden seines Kontakts erstellt, daher ist die schnellste Kontrolle, sich als echter Portal-Nutzer anzumelden und auszuprobieren, was er tun darf und was nicht. Sein Zugriff ist genau das, was ihre Sicherheitsrollen erlauben: Keine portalseitige Konfiguration befindet sich davor, und nichts im Portal erweitert ihn.

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

Abgemeldete Besucher werden durch denselben Mechanismus abgedeckt. Die Plattform erstellt einen anonymen, systemverwalteten Nutzer für die Seite – Identität PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com – und Power Portals Pro imitiert ihn bei jeder nicht authentifizierten Anfrage. Welche Sicherheitsrollen auch immer dieser Nutzer innehat, das ist das, was ein anonymer Besucher erreichen kann, also gib ihm den schmalen, schreibgeschützten Zugriff, den ein ausgeloggter Besucher haben sollte, und nicht mehr.

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 der eigenen Tischsicherheit des Portals aus?

Sitzungen nach diesem Modell umgehen alles, was eine Tabellenregistrierung beschreibt – ihre Operationen, ihre Spalten, ihren Zeilenumfang und das Eigentumsstempel, egal ob man sie mit AddTableAccess einem beschrieben oder geschrieben hat ITablePermissionProvider – genau wie interne systemuser Anmeldungen, weil Dataverse stattdessen durchsetzt. Welche Zeilen ein Nutzer erreicht und wem ein Datensatz gehört, zu dem er selbst gehört, sind seine Sicherheitsrollen zu entscheiden, wie alles andere auch. Man muss nichts davon schreiben oder registrieren. Registrierungen sperren weiterhin Sitzungen, die nicht von einem bereitgestellten Benutzer gesichert werden (die Funktion deaktiviert, eine Sitzung, in der die Bereitstellung fehlschlug und das Framework auf portalseitige Sicherheit zurückfiel, oder anonyme Besucher auf einer Seite ohne den anonymen Nutzer), sodass bestehende Portale schrittweise migrieren können. Portalrollen gelten auch nicht für diese Sitzungen: Sie werden weder zugewiesen noch gelesen nach diesem Modell gelesen.

Unterscheidung bereitgestellter Benutzer in Ihrer Benutzeroberfläche

Sitzungen tragen einen PortalUserType Anspruch mit dem ganzzahligen Wert des PortalUserType Enums: Contact (klassischer Portalbenutzer), SystemUser (echtes internes Anmeldeprotokoll) 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 von GET /api/auth/me als CurrentUserResponse.PortalUserTypezurückgegeben. Verwenden Sie die GetPortalUserType() und-Erweiterungen GetDataverseSystemUserId() auf ClaimsPrincipal, und präsentieren Sie niemals eine ContactStubUser Sitzung als interner Benutzer.

Rollenansprüche folgen demselben Modell. Die Sitzung eines bereitgestellten Nutzers trägt die Webrollen , die er hält – die Namen, die ein Administrator zugewiesen hat – zusammen mit den PowerPages_* damit verbundenen Sicherheitsrollen, und keine Portalrollen. Gate auf Webrollen mit [AuthorizeWebRole("Dealers")] oder <PortalRoleView WebRole="Dealers"> in Blazor und <AuthorizedView webRoles="Dealers"> in React; GET /api/auth/me listet sie als webRolesauf.

API-Referenz