SystemUser-Anmeldung

Power Portals Pro erkennt angemeldete Dataverse-Datensätze systemuser als Portalnutzer – zusammen mit den standardmäßig contactunterstützten Nutzern. Es ist keine Konfiguration erforderlich: Wenn sich ein Benutzer über eine Microsoft-Authentifizierung anmeldet, sucht das Portal zunächst nach einem Match; systemuserfalls vorhanden, läuft die Sitzung als dieser Systemuser, und Dataverse erzwingt die Sicherheit durch Imitation. Wenn kein passender Systemuser gefunden wird, fällt die Anmeldung auf den Kontaktpfad zurück. Dasselbe Portal kann sowohl interne Dataverse-lizenzierte Mitarbeiter als auch externe Kundenkontakte gleichzeitig bedienen.

Wenn das wichtig ist

Der systembenutzerunterstützte Fluss ist nützlich, wenn:

Das Portal bedient Mitarbeiter – Mitarbeiter, Support-Agenten, Partner mit Dataverse-Lizenzen –, die bereits als Systemnutzer bereitgestellt sind.
Man möchte, dass Dataverse-Sicherheitsrollen die einzige Wahrheitsquelle für das sind, was diese Nutzer sehen und tun können.
Du möchtest keine Identität duplizieren, indem du für jeden Mitarbeiter einen parallelen contact Datensatz führst.

Nur Microsoft-Authentifizierung
Nur der externe Anbieter der Microsoft / Entra-ID kann auf einen Systemuser auflösen; Benutzer werden mit systemuser.azureactivedirectoryobjectidabgeglichen, und jeder SystemBenutzer mit isdisabled = true wird blockiert. Lokaler Benutzername/Passwort und andere externe Anbieter (Google usw.) melden sich immer als Kontakt an.

Wie es funktioniert

Bei einer Microsoft-Anmeldung folgt das Portal:

Sucht die authentifizierte Azure AD Object ID gegen systemuser.azureactivedirectoryobjectid. Wenn ein aktiver Datensatz übereinstimmt, ist die Sitzung an diesen Systemuser gebunden.
Andernfalls fällt er auf den kontaktunterstützten Fluss zurück (wobei der externe Login über abgestimmt wird adx_externalidentity).
Für Systemuser-Sitzungen ist es so systemuserid eingestellt, ServiceClient.CallerId dass jeder Dataverse-Aufruf als angemeldeter Benutzer ausgeführt wird – mit deren Sicherheitsrollen, Geschäftseinheitsbereich und zeilenebenem Zugriff. Portalseitige ITablePermissionHandler / ITableRecordPermissionHandler Instanzen werden für die Anfrage umgangen.
Raster, Formulare und Buttons spiegeln die tatsächlichen Dataverse-Privilegien des Nutzers wider – RetrieveUserPrivilegesRequest berechnet und zwischengespeichert pro Nutzer. Kontaktsitzungen fließen wie bisher weiterhin über die registrierten Betreuer.

Sicherheitsmodell

Für systembenutzerunterstützte Sitzungen, weil CallerId Imitation die Durchsetzung an Dataverse delegiert:

Die Sicherheit auf Datensatz- und Spaltenebene stammt aus den Dataverse-Sicherheitsrollen des angemeldeten Nutzers – nicht aus dem Portalcode.
Sicherheit auf Feldebene, hierarchische Eigentumsverhältnisse und Geschäftseinheits-Scoping gelten alle automatisch.
Portalseitige Berechtigungshandler (ITablePermissionHandler / ITableRecordPermissionHandler) werden für die Anfrage umgangen. Sie laufen weiterhin wie gewohnt für kontaktgestützte Sitzungen im selben Portal.
Die Dataverse-Sicherheitsrollen des Nutzers werden als ClaimTypes.Role Claims auf den Principal projiziert, sodass bestehende [Authorize(Roles = "…")] Attribute und User.IsInRole(...) Prüfungen gegen diese wirken, ohne dass pro Anfrage ein zusätzlicher Dataverse-Roundtrip erforderlich ist. Ansprüche werden bei der Prinzipalvalidierung aktualisiert, sodass Rollenzuweisungen in Dataverse innerhalb des Sicherheitsstempelintervalls (~10 Minuten) aufgenommen werden, ohne eine erneute Anmeldung zu erzwingen.

Admins: Testing als Kontakt

Portaladministratoren müssen in der Regel die Kontakterfahrung überprüfen – wird die Startseite für einen angemeldeten Kunden korrekt angezeigt? Versteckt dieser Fall diesen Symbolleisten-Button korrekt? – ohne ihre Fähigkeit zu verlieren, Admin-Aktionen auszuführen. Power Portals Pro unterstützt dies direkt: Ein Administrator kann eine Microsoft-Anmeldung sowohl mit einem systemuser (seinem internen Konto) als auch mit einem contact (Testdatensatz oder seinem eigenen Kundendatensatz) verknüpfen lassen und zwischen den beiden wechseln, ohne sich abzumelden.

Wähler beim Anmelden. Wenn eine Microsoft-Anmeldung auf mehr als eine Identität aufgelöst wird, zeigt die Seite nach dem Rückruf einen Wähler, der jeden Kandidaten auflistet (Art + Anzeigename + E-Mail). Wenn man eine auswählt, meldet sich der Nutzer für den Rest der Sitzung als diese Identität an.
Erinnerte mich an die Wahl. Der Wähler schreibt ein kleines Cookie-per-Provider-Key, sodass nachfolgende Anmeldemeldungen den Prompt überspringen und direkt zur zuletzt gewählten Identität gelangen. Der erinnerte Pick wird aktualisiert, sobald der Nutzer während der Sitzung wechselt, sodass die nächste mehrdeutige Anmeldung die neue Präferenz respektiert.
Wechsel während der Sitzung. Wenn der angemeldete Nutzer eine Geschwisteridentität hat, erscheint im Profilmenü ein Eintrag "Switch to contact" / "Switch to systemuser". Es postet auf /api/auth/switch-identity, wodurch das Auth-Cookie für die alternative Identität erneut ausgegeben wird – keine neue OAuth-Hin- und Rückreise erforderlich. Der Endpunkt liest die Alt-Identitäts-ID vom Hauptmann (nie vom Anfrage-Body), daher kann ein manipulierter Klick den Benutzer nicht als jemand anderes anmelden.

Gemischte Zielgruppen: Gestalten Sie Ihre Daten entsprechend
Ein einzelnes Portal kann sowohl Systemnutzer als auch Kontaktnutzer in derselben Bereitstellung bedienen. Wenn deine Anpassungen FetchXML-Filter enthalten, die Zeilen nach adx_contactid == currentUserId abgrenzen (ein häufiges Muster bei Kontaktportalen), ergeben diese Filter keinen Sinn, wenn der angemeldete Nutzer ein SystemUser ist. Verzweigen Sie Ihren Anpassungscode auf der Benutzerart, damit jede Zielgruppe die passenden Daten sieht.

Privilegien-Caches

Die umweltweite Privilegien-Metadatenkarte wird einmal beim Anwendungsstart geladen und unbegrenzt zwischengespeichert; Neustarte die Anwendung (oder den Aufruf IPrivilegeMetadataCache.InvalidateAsync) neu, um neue Tabellen oder Berechtigungsschema-Änderungen zu erkennen. Die effektiven Privilegien jedes angemeldeten SystemUsers werden 24 Stunden lang zwischengespeichert und können mit IUserPrivilegeCache.InvalidateAsync(userId)entfernt werden.