Einrichtung der Dataverse-Verbindung

Dein Portal kommuniziert mit Dataverse als eigenständige Anwendung, nicht als der Besucher, der es gerade durchstöbert. Das erfordert zwei Teile: eine App-Registrierung in der Microsoft Entra-ID, die die Zugangsdaten besitzt, und einen Anwendungsbenutzer in deiner Dataverse-Umgebung, der diesen Zugangsdaten eine Identität und eine Sicherheitsrolle verleiht. Diese Seite führt beide Seiten durch und den Zugriff, den das Portal tatsächlich benötigt.

Das ist nicht die Anmelde-App

Diese Registrierung ist die eigene Service-Identität des Portals – sie liest und schreibt Daten im Namen des Portals, und ihre Zugangsdaten liegen unter D365:ClientId / D365:ClientSecret. Eine zweite, separate Registrierung übernimmt die Anmeldung von Nutzern bei Microsoft. Halten Sie sie getrennt: Diese benötigt keine Redirect-URI und keine delegierten Berechtigungen, aber sie hat in Ihrer Umgebung deutlich mehr Macht. Siehe Entra ID Anmeldeeinrichtung

1. Registrieren Sie den Antrag

Erstelle die Registrierung im Microsoft Entra-Verwaltungszentrum, im Tenant, der deine Dataverse-Umgebung besitzt.

  1. Besuchen Sie Entra ID > App-Registrierungen und wählen Sie Neue Anmeldung.
  2. Geben Sie zum Beispiel Contoso Portal — Dataverse (Production)einen Namen ein, der das Portal und die Umgebung identifiziert. Niemand sieht dies auf einem Einwilligungsbildschirm, daher sollten Sie später Klarheit für den Prüfer bevorzugen.
  3. Unter Unterstützte Kontotypen wählen Sie Nur Einzelmieter. Diese Identität verlässt Ihre Organisation nie.
  4. Lassen Sie die Umleitungs-URI leer. Kein Benutzer wird hierher jemals umgeleitet – das Portal authentifiziert sich mit dem Fluss der Client-Zugangsdaten, von Maschine zu Maschine, ohne Browser.
  5. Wählen Sie Registrieren.
  6. Auf der Übersichtsseite kopieren Sie die Anwendungs-(Client-)ID. Dieser Wert wird D365:ClientIdzu , und Sie benötigen ihn erneut in Schritt 4, um den Anwendungsbenutzer zu erstellen.

2. Erstelle eines Kundengeheimnisses

Das Geheimnis ist die einzige Zugangsberechtigung des Portals, also betrachte sie als Schlüssel zu den Daten deiner Umgebung.

  1. Öffnen Sie Zertifikate & Geheimnisse unter Verwalten und wählen Sie den Reiter Client-Geheimnisse aus.
  2. Wählen Sie Neues Clientgeheimnis, beschreiben Sie es nach Umgebung (zum Beispiel portal-production) und wählen Sie ein Ablaufdatum aus.
  3. Kopiere sofort die Wert-Spalte – nicht die Secret ID. Sie wird nur einmal angezeigt und wird dann zu D365:ClientSecret.

Wichtig

Wenn das Geheimnis abläuft, erreicht das Portal das Dataverse komplett nicht mehr – nicht nur für eine Funktion, sondern für jede Anfrage – also gib das Ablaufdatum irgendwo an, wo du es sehen kannst. Für die Produktion vermeidet ein Zertifikatszugang die Ablauf-Klippe und AuthenticationType.Certificate akzeptiert einen anstelle des Geheimnisses.

3. API-Berechtigungen: Keine erforderlich.

Dieser Schritt ist absichtlich leer, und das überrascht die Leute. Viele ältere Leitfäden empfehlen, die Berechtigung Dynamics CRM → user_impersonation delegiert hinzuzufügen. Diese Berechtigung ist für Anwendungen, die im Auftrag eines angemeldeten Benutzers handeln. Das Portal tut das nicht – es authentifiziert sich als sich selbst, und sein Zugriff erfolgt vollständig über den Dataverse-Anwendungsbenutzer, den du im nächsten Schritt anlegst.

Anmerkung

Microsofts eigene Server-to-Server-Richtlinien sagen dasselbe: Wenn Sie sich als App verbinden, gewähren Sie Access Dynamics 365 als Organisationsnutzer nicht, da die Anwendung stattdessen an ein bestimmtes Benutzerkonto gebunden ist. Das Hinzufügen bewirkt nichts, aber es gewährt eine Funktion, die das Portal nie ausübt – lassen Sie sie weg.

4. Erstellen Sie den Anwendungsbenutzer in Dataverse

Die App-Registrierung allein kann Daten nicht berühren. Dataverse benötigt einen Benutzereintrag, der an sich gebunden ist, was die Client-ID in eine Identität umwandelt, die Ihre Umgebung erkennt.

  1. Melden Sie sich im Power Platform Verwaltungszentrum an.
  2. Wählen Sie im Navigationsfenster "Verwalten " aus, dann Umgebungen und dann Ihre Umgebung.
  3. Wählen Sie Einstellungen > Benutzer + Berechtigungen > Anwendungsbenutzer.
  4. Wählen Sie + Neuer App-Nutzer.
  5. Wählen Sie + App hinzufügen und suchen Sie Ihre Registrierung nach Namen oder Kunden-ID ab Schritt 1, dann wählen Sie Hinzufügen. Nur Entra-App-Registrierungen erscheinen in dieser Liste – Unternehmensanwendungen nicht.
  6. Wähle eine Business Unit. Die Root-Business Unit ist die übliche Antwort; eine Child-Unit schränkt die Erreichbarkeit des Portals ein, noch bevor Sicherheitsrollen angewendet werden.
  7. Wählen Sie das Bearbeiten-Symbol neben Sicherheitsrollen aus und weisen Sie die Rollen zu, die das Portal benötigt – der nächste Schritt behandelt, welche und warum es meist mehr als eine gibt.
  8. Wählen Sie Erstellen.

Tipp

Ein Anwendungsnutzer verbraucht keine bezahlte Lizenz, und pro Entra-App-Registrierung pro Umgebung kann man nur eine registrieren. Verwenden Sie für jede Umgebung eine separate Registrierung, damit der Entzug des Entwicklungszugriffs nie die Produktion berührt.

5. Dem Anwendungsbenutzer eine Sicherheitsrolle geben

Der Anwendungsbenutzer kann überhaupt nichts tun, bis er eine Sicherheitsrolle innehat. Es gibt zwei Wege, und welcher der richtige ist, hängt von einer einzigen Frage ab: Würden Sie es stören, dass die Zugangsdaten des Portals Daten erreichen, die das Portal selbst nie anzeigt?

Der schnelle Weg: Systemadministrator

Systemadministrator zuzuweisen funktioniert, und wenn die Umgebung nichts enthält, was du offenlegen möchtest – eine Demo, einen Prototyp, eine Sandbox, deren Daten bereits öffentlich sind – ist das eine vernünftige Entscheidung und kein Fehler. Mach es einfach bewusst. Das Portal ist internetorientiert, und diese Zugangsdaten entscheiden, wie weit ein Angreifer kommt, falls das Geheimnis jemals durchsickert. Systemadministrator bezeichnet jede Tabelle in der Umgebung, einschließlich alle, für die das Portal nie gebaut wurde.

Der Scoped-Weg: unsere Rolle, plus eine eigene

Überall dort, wo echte Daten leben, weisen Sie zwei Rollen zu. Sicherheitsrollen sind additiv, sodass der Anwendungsnutzer am Ende die Vereinigung beider erhält – und sie getrennt zu halten, ermöglicht es Ihnen, Ihre eigenen Fördermittel zu überprüfen, ohne unsere noch einmal lesen zu müssen.

  1. Weisen Sie Power Portals Pro Application User zu, der in der verwalteten Lösung ausgeliefert wird. Sie gewährt genau das, was das Framework zum Ausführen benötigt, und sonst nichts. Fügen Sie dann den Anwendungsbenutzer dem gleichnamigen Spalten-Sicherheitsprofil hinzu, das daneben ausgeliefert wird: Eine Sicherheitsrolle kann niemals eine gesicherte Spalte gewähren, und Power Pages sichert zwei Kontaktspalten, die das Framework als sich selbst schreibt, adx_identity_logonenabled und adx_identity_passwordhash. Ohne das Profil melden sich bestehende Benutzer normal an und die erste Registrierung schlägt fehl mit ohne Berechtigungen zum Erstellen eines Login Enabled-gesicherten Feldes vor. Tun Sie dasselbe für jeden Anwendungsbenutzer, mit dem das Portal verbunden ist, einschließlich der einer verwalteten Identität in einer bereitgestellten App.
  2. Erstelle eine zweite, benutzerdefinierte Rolle für deine eigenen Tabellen. Dataverse würde es dir erlauben, sie stattdessen zur ausgelieferten Rolle hinzuzufügen, aber sie getrennt zu halten: Die ausgelieferte Rolle gehört uns, ein Lösungs-Upgrade kann sie erneut anwenden, und Grants, die darin gemischt sind, sind nicht mehr prüfbar, ohne unsere zusammen mit ihnen zu lesen. Mit dem MCP-Server create_security_role erstellt er sie und assign_application_user_role gibt sie dem Anwendungsbenutzer.
  3. Füge deine Tabellen zu dieser Rolle hinzu. Wenn du den MCP-Server nutzt, braucht das keine Durchläufe des Sicherheitsrollen-Formulars – describe_role_table_privileges es wird angezeigt, was eine Rolle aktuell auf einer Tabelle gewährt und in welcher Tiefe, und add_table_privileges_to_role gewährt alles, was fehlt. Gewähren nimmt nie etwas weg: remove_table_privileges_from_role Macht das, entfernt Privilegien oder senkt deren Tiefe, und delete_security_role löscht eine Rolle, sobald sie niemand mehr innehat. Keine von ihnen berührt eine verwaltete Rolle, auch nicht die ausgelieferte, sodass die Zuteilungen immer in deiner landen.

Wichtig

Bei erweiterter Autorisierung zuweisen Power Portals Pro Application User - Enhanced Authorization Sie stattdessen. Sie wird in der Power Portals Pro Enhanced Authorization-Lösung ausgeliefert und ist eine Supermenge der oben genannten Rolle – alle Privilegien, die man gewährt, in gleicher Tiefe, plus die für das Lesen von Webrollen und die Wartung der Webrollenkonfiguration. Sie ersetzt die ausgelieferte Rolle, anstatt sie beizutreten, daher ist die Zuweisung beider harmlos, aber sinnlos. Ohne diese kann das Portal Webrollen nicht lesen: Neuen Benutzern werden keine zugewiesen, und das Portal zeigt ihnen nichts, ohne einen Fehler zu melden. Das Sicherheitsprofil der Spalte wird in jedem Fall benötigt – keine Sicherheitsrolle, so breit sie auch sein mag, kann eine gesicherte Spalte gewähren.

Was die verschiffte Rolle bereits abdeckt

Power Portals Pro Application User wird von den Aufrufen abgeleitet, die das Framework als sich selbst macht, sodass es verfolgt, was das Framework tatsächlich benötigt, anstatt das, was damals sinnvoll erschien:

Was das Portal bewirkt Zugreifen Sie auf die Rollenbedürfnisse
Registriert und meldet sich in Portalnutzern an Erstellen, Lesen und Schreiben auf contact, sowie Erstellen, Lesen, Schreiben und Löschen auf adx_externalidentity, das die Verbindung zwischen einem Portalbenutzer und einem externen Login speichert.
Bindet Raster an Dataverse-Ansichten und formatiert Werte Lesen Sie weiter savedquery, und lesen Sie weiter organization, usersettings und transactioncurrency so werden Daten, Zahlen und Währung korrekt formatiert.
Sendet Bestätigungs- und Passwort-Zurücksetzungs-E-Mail Erstellen, lesen und schreiben auf email, und lesen auf die queue Ihre konfigurierte Absenderadresse aufgelöst wird.
Portalrollen erstellen, lesen, schreiben und löschen auf ppp_portalrole und ppp_portalroleconfiguration, sowie Append/AppendTo un, contact damit Rollen zugewiesen werden können. Das Portal selbst liest diese nur zur Laufzeit; die Schreibrechte sind vorhanden, damit das RoleManager<PortalRole> für Hosts funktioniert, die Rollen im Code verwalten, und so funktionieren die Portal-Rollen-Tools des MCP-Servers in einem Projekt, das als Anwendungsbenutzer verbunden ist.
Validiert die Website-Lizenz Berechtigung, die ppp_ProWebsiteLicenseCheck Aktion auszuführen, und Read on ppp_powerportalsprowebsite — die Aktion läuft im Kontext des Anrufers, sodass sie die Website-Einträge als Anwendungsbenutzer liest. Wenn einer eines eines der beiden fehlt, gibt jeder lizenzierte Endpunkt 402 zurück, was sich wie eine abgelaufene Lizenz und nicht wie ein fehlendes Privileg aussieht.
Dataverse-native Sicherheit Erstellen, lesen und schreiben auf systemuser, Lesen weiter businessunit und role, Erstellen und Lesen weiterpowerpagesusermapping, Weiterlesen und das powerpagesiteGesetz im Namen eines anderen Nutzers, auf dem die Identifikation beruht.

Was absichtlich nicht abgedeckt wird, sind deine eigenen Tabellen – keine Rolle, die wir ausliefern, kann wissen, welche sie sind, und genau dafür ist die oben genannte benutzerdefinierte Rolle gedacht. Erwarte Erstellen, Lesen, Schreiben und Löschen auf jeder Tabelle, die dein Portal offenlegt, in dem Umfang, den du den Besuchern erhoffst. Das ist der Großteil der Arbeit und ist völlig spezifisch für deine Anwendung.

Wichtig

Impersonation schränkt den Anwendungsbereich ein. Sie erweitert ihn nie. Unter der Dataverse-nativen Sicherheit markiert das Portal jede Anfrage mit der Identität des angemeldeten Besuchers, und Dataverse wendet die Schnittstelle der Rechte dieses Besuchers und des Anwendungsbenutzers an – eine Operation ist nur erlaubt, wenn beide das Privileg dafür besitzen. Die Rolle des Anwendungsbenutzers ist also eine Obergrenze für das, was ein Besucher tun kann. Ein Besucher, dessen eigene Rolle Lesen auf einer Tabelle gewährt, liest trotzdem nichts, wenn der Anwendungsbenutzer diese nicht hat, und das Hinzufügen einer Tabelle zu Ihrer benutzerdefinierten Rolle gewährt einem Besucher nie mehr als seine bereits erlaubte Rolle.

6. Speichere die Verbindungseinstellungen

Das Portal liest diese aus der Konfiguration unter dem Abschnitt D365 . Bewahren Sie sie während der Entwicklung in Benutzergeheimnissen auf, damit sie nie zur Quellcode-Kontrolle gelangen:

EmailSenderEmailAddress ist die Adresse, von der die ausgehende E-Mail des Portals gesendet wird. Sie muss mit einem queue oder einem aktivierten systemuser in der Umgebung übereinstimmen – eine Warteschlange ist die übliche Wahl, da sie keine Portal-Post an eine Person bindet, die später gehen könnte.

Erstellung der Absender-Warteschlange

Starten Sie in Exchange Online: Erstellen Sie ein gemeinsames Postfach für die Adresse, von der das Portal stammen sollte – no-reply@yourcompany.com ist die übliche Wahl. Ein gemeinsames Postfach benötigt keine Lizenz. Dann geben Sie im Maker-Portal erweiterte Einstellungen → Business Management → Queues → New der Warteschlange diese Adresse und speichern; Dataverse erstellt einen Postfacheintrag dafür im Exchange Online-Profil der Umgebung. Eine Warteschlange ist die richtige Antwort für einen Absender, der keine Antwort hat, und sie ist besser, als das Portal auf das Konto eines Kollegen zu zeigen – dessen Name sonst auf jeder automatisierten Nachricht stehen würde, die das Portal sendet, und dessen Abgang das Senden überhaupt stoppen würde.

Wichtig

Das Postfach muss weiterhin genehmigt und aktiviert werden. Öffnen Sie den Postfacheintrag der Warteschlange und führen Sie die E-Mail genehmigt – was nur ein globaler Office-365- oder Exchange-Administrator tun darf – und dann Test & Enable Mailbox. Bis das vorbei ist, akzeptiert Dataverse alles, was das Portal sendet, und liefert nichts davon. Kein Fehler erreicht das Portal, sodass das genau wie funktionierende E-Mails aussieht, bis jemand meldet, nie eine Passwort-Zurücksetzungsmeldung erhalten zu haben. Der MCP-Server create_email_queue führt die Warteschlange, die Genehmigung und den Test in einem Anruf durch und check_email_sender erklärt einen Absender, der nicht zustellt.

Tipp

In gehosteten Umgebungen sollten die gleichen Schlüssel wie Umgebungsvariablen oder aus einem geheimen Speicher bereitgestellt werden, wobei anstelle des Doppelpunkts – , D365__Secret , – ein doppelter Unterstrich verwendet D365__ClientIdwird, da der Doppelpunkttrenner nicht plattformübergreifend portabel ist.

Tipp

Sobald du auf Azure ausgerollt bist, kannst du komplett abbrechen ClientSecret . Setze D365:ManagedIdentityId auf die Client-ID einer benutzerzugewiesenen verwalteten Identität und das Portal authentifiziert sich stattdessen als diese Identität – kein Geheimnis und also nichts, das abläuft. Es benötigt einen eigenen Anwendungsbenutzer, der aus dieser Client-ID genau wie in Schritt 4 erstellt wird. Für eine Umgebung in einem anderen Tenant setzt D365:TenantId man das auch, und die Identität wird stattdessen zum Zugangsnachweis der App-Registrierung D365:ClientId . Siehe Azure-Deployment.

7. Verbindung verkabeln

Das Serverprojekt konfiguriert ConnectionOptions sich, wenn es das Framework registriert:

Die Projektvorlage schreibt das für dich, also gibt es in einem generierten Projekt hier nichts hinzuzufügen – gib die drei Konfigurationswerte an und die Verbindung funktioniert. Starte das Portal und durchsuche jede Seite, die von Dataverse-Daten unterstützt wird, um es zu bestätigen.

Fehlerbehebung