Entra ID Anmeldeeinrichtung

Power Portals Pro meldet Nutzer bei Microsoft über den Standardanbieter AddMicrosoftAccount von ASP.NET Core an, der eine App-Registrierung in Microsoft Entra ID benötigt. Die Registrierung zeigt Entra, dass Ihr Portal Anmeldungen anfordern darf, wohin es Nutzer zurückschicken kann und mit welchen Zugangsdaten es sich beweisen kann. Diese Seite führt alle Eigenschaften durch, auf die das Portal tatsächlich angewiesen ist.

Das ist nicht die Dataverse-Verbindungs-App

In einem typischen Portal sind zwei separate Registrierungen beteiligt, und das Verwechseln dieser Daten ist ein häufiger Fehler beim ersten Durchlauf. Die Dataverse-Verbindungs-App ist ein Service-Principal, der Daten als das Portal selbst liest und schreibt, und ihre Zugangsdaten liegen unter D365:ClientId / D365:ClientSecret. Die auf dieser Seite beschriebene Registrierung ist nur für die Anmeldung von Nutzern gedacht, und ihre Zugangsdaten liegen unter Authentication:Microsoft:ClientId / ClientSecret. Verwenden Sie zwei Registrierungen – sie benötigen unterschiedliche Eigenschaften und haben einen sehr unterschiedlichen Explosionsradius, falls sie geleakt werden.

1. Registrieren Sie den Antrag

Erstelle die Registrierung im Microsoft Entra-Verwaltungszentrum. Du benötigst mindestens die Rolle des Anwendungsentwicklers im Mieter.

  1. Melden Sie sich im Entra-Verwaltungszentrum an, und wenn Sie mehr als einem Mieter angehören, verwenden Sie das Einstellungssymbol , um zu dem Mieter zu wechseln, der die Registrierung besitzen sollte. Eine App-Registrierung kann danach nicht mehr zwischen Mietern verschoben werden.
  2. Besuchen Sie Entra ID > App-Registrierungen und wählen Sie Neue Anmeldung.
  3. Geben Sie zum Beispiel Contoso Portal Sign-Ineinen Namen ein. Nutzer sehen diesen Namen auf dem Einwilligungsbildschirm, also machen Sie ihn als Ihr Portal bekannt. Er kann später geändert werden.
  4. Unter Unterstützte Kontotypen wählen Sie die Zielgruppe, die zu Ihrem Portal passt – siehe die untenstehende Tabelle. Dies ist die Eigenschaft, die entscheidet, wer sich anmelden darf.
  5. Wählen Sie Registrieren.
  6. Auf der Übersichtsseite kopieren Sie die Anwendungs-(Client-)ID. Dieser Wert wird zu Authentication:Microsoft:ClientId.

Auswahl unterstützter Kontotypen

Diese Einstellung ist die Eingangstür des Portals. Wählen Sie die engste Option, die trotzdem alle abdeckt, die sich anmelden müssen:

Unterstützte Kontotypen Wer kann sich anmelden
Nur Einzelmieter – <Ihr Mieter> Nur Nutzer und Gäste in Ihrem eigenen Tenant. Die richtige Wahl für ein mitarbeiterorientiertes Portal – es passt zur Zielgruppe der internen Nutzer in der Projektvorlage.
Mehrere Entra-ID-Mieter Benutzer in jedem Entra-Tenant, aber keine persönlichen Microsoft-Konten. Nutzen Sie dies für Partner- oder B2B-Portale, bei denen sich jeder Nutzer mit einem Arbeits- oder Schulkonto aus seiner eigenen Organisation anmeldet.
Jeder Entra ID Tenant + Persönliche Microsoft-Konten Arbeits-, Schul- und Privatkonten (Outlook.com, Hotmail, Xbox). Die breiteste Option und die übliche Wahl für ein kundenorientiertes Portal, bei dem Besucher möglicherweise keiner Organisation angehören.
Nur persönliche Konten Nur Microsoft-Konten für Verbraucher – keine Arbeits- oder Schulkonten.

Anmerkung

Der ASP.NET Core-Microsoft-Anbieter autorisiert immer gegen den Multi-Audience-Endpunkt /common/ , sodass die Einstellung "Unterstützte Kontotypen" der Registrierung – nicht Ihr Anwendungscode – tatsächlich ein bestimmtes Konto akzeptiert oder ablehnt. Wenn ein Konto mit AADSTS50020abgelehnt wird, ist die Registrierung enger als die Zielgruppe, die Sie beabsichtigt haben.

2. Fügen Sie die Redirect-URI hinzu

Nach einer erfolgreichen Anmeldung schickt Entra den Nutzer zurück zu deinem Portal über den Rückrufpfad des Anbieters, der lautet /signin-microsoft. Entra leitet nur zu im Voraus registrierten Adressen um, sodass jeder Host, auf dem dein Portal läuft, einen eigenen Eintrag benötigt.

  1. Öffnen Sie Authentifizierung unter Verwalten und wählen Sie dann Plattform hinzufügen.
  2. Wählen Sie die Webplattform – nicht die Single-Page-Anwendung. Der Portalserver führt den Token-Austausch über das Client-Geheimnis durch, und das gilt auch für Blazor WebAssembly- und React-Hosts, wo die Anmeldung weiterhin serverseitig erfolgt.
  3. Gib die Adresse deines Portals an, gefolgt von /signin-microsoft.
  4. Wiederhole das für jede Umgebung. Die Entwicklungs-URL und launchSettings.json jeder bereitgestellte Host benötigen jeweils eine eigene Redirect-URI. Sie können eine Registrierung teilen, oder du kannst eine separate Registrierung pro Umgebung behalten.

Wichtig

Die Redirect-URI müssen genau mit dem übereinstimmen, was das Portal sendet – Schema, Host, Port und Pfad. https://localhost:7228/signin-microsoft und https://localhost:7228/signin-microsoft/ sind nicht dieselbe Adresse, ebenso wenig wie zwei verschiedene Ports. Entra benötigt https für alles außer localhost.

Wenn das Portal hinter einem Reverse-Proxy, Load Balancer oder Container-Ingress läuft, der TLS terminiert, konfiguriere ASP.NET Core's Forwarded-Header-Middleware. Ohne diesen glaubt die App, dass die Anfrage über einfaches HTTP angekommen ist, und erstellt eine http:// Redirect-URI, die nicht mit der registrierten https:// übereinstimmt.

3. Erstellen Sie ein Kundengeheimnis

Das Geheimnis ist, wie dein Portal beweist, dass es wirklich die registrierte Anwendung ist, wenn es den Autorisierungscode gegen ein Token tauscht.

  1. Öffnen Sie Zertifikate & Geheimnisse unter Verwalten und wählen Sie den Reiter Client-Geheimnisse aus.
  2. Wählen Sie Neues Clientgeheimnis, geben Sie ihm eine Beschreibung mit dem Namen der Umgebung (zum Beispiel portal-production) und wählen Sie ein Ablaufdatum aus.
  3. Kopieren Sie sofort die Wert-Spalte – nicht die Secret ID. Der Wert wird nur einmal angezeigt und wird dann zu Authentication:Microsoft:ClientSecret.

Wichtig

Client-Geheimnisse verfallen, und 24 Monate sind das Maximum. Wenn eines abläuft, schlägt AADSTS7000215 jede Microsoft-Anmeldung fehl, bis es ersetzt wird, also verfolgen Sie das Ablaufdatum und rotieren Sie davor. Für die Produktion vermeiden Zertifikatsdaten oder eine föderierte Identitätszugangsdaten das Problem des Ablaufgeheimnisses vollständig.

4. API-Berechtigungen überprüfen

Eine neue Registrierung erhält Microsoft Graph User.Read (delegiert) automatisch, und das ist die einzige Berechtigung, die der Anmeldefluss benötigt. Der Anbieter fordert den https://graph.microsoft.com/user.read Umfang an und liest das Profil des angemeldeten Benutzers aus https://graph.microsoft.com/v1.0/me. Wenn jemand diese Berechtigung entfernt hat, fügen Sie sie wieder unter API-Berechtigungen hinzu. Die Erteilung der Administrator-Einwilligung ist in den meisten Workforce-Tenants optional, vermeidet jedoch, jedem Benutzer beim ersten Anmelden eine Einwilligungsaufforderung zu zeigen; bei externen Tenants ist sie erforderlich.

Power Portals Pro liest Folgendes aus diesem Profil aus, wenn es einen Portalnutzer verknüpft oder erstellt:

Grapheneigenschaft Anspruch Wie das Portal es nutzt
id NameIdentifier Der stabile Schlüssel für den externen Login. Gespeichert gegen den Portal-Benutzer, sodass dasselbe Microsoft-Konto bei jeder späteren Anmeldung auf denselben Benutzer aufgelöst wird.
mail / userPrincipalName Email Sie werden mit bestehenden Kontakten (und Systemnutzern) abgeglichen, um den Portalbenutzer zu finden, zu dem diese Anmeldung gehört, und als E-Mail-Adresse verwendet, wenn ein neues Konto erstellt wird. Welche Kontaktspalten durchsucht werden, ist konfigurierbar – siehe Abgleich einer externen Anmeldung mit einem Kontakt.
givenName, surname GivenName, Surname Füllt den Vor- und Nachnamen im Registrierungsformular vor, wenn ein neuer Portalnutzer erstellt wird.

Anmerkung

Die Immobilie mail ist für Konten leer, die kein Exchange-Postfach haben, in diesem Fall greift der Anbieter auf userPrincipalName. Eine UPN ist nicht immer eine routable E-Mail-Adresse – insbesondere Gastkonten tragen UPNs in Form user_contoso.com#EXT#@yourtenant.onmicrosoft.com –, also wenn Ihr Portal Nutzer per E-Mail übereinstimmt, sollten diese Konten nicht mit einem bestehenden Kontakt übereinstimmen.

5. Speichern Sie die Kunden-ID und das Geheimnis

Das Portal liest beide Werte aus der Konfiguration unter dem Authentication:Microsoft Abschnitt. In der Entwicklung sollte man sie in Benutzergeheimnissen halten, anstatt appsettings.json dass sie nie die Quellcode-Kontrolle erreichen:

Oder aus der Befehlszeile, im Verzeichnis des Serverprojekts:

Tipp

In gehosteten Umgebungen sollten die gleichen Schlüssel wie Umgebungsvariablen oder aus einem geheimen Speicher bereitgestellt werden. Umgebungsvariablen verwenden einen doppelten Unterstrich anstelle des Doppelpunkts — Authentication__Microsoft__ClientId und Authentication__Microsoft__ClientSecret — da der Doppelpunkttrenner nicht plattformübergreifend portabel ist.

6. Aktivieren Sie den Anbieter in Program.cs

Registrieren Sie den Anbieter zusammen mit dem Rest Ihrer Authentifizierungseinrichtung im Serverprojekt:Program.cs

Die Projektvorlage schreibt diesen Aufruf für Sie, wenn Sie die Internal Users oder Both audience auswählen oder wenn Sie sich für die Microsoft-Anmeldung für externe Benutzer anmelden. Wenn Sie das Projekt ohne diese erstellt haben, kommentierten Program.cs die gleichen Aufruf-Ships in — entkommentieren Sie und geben die beiden Konfigurationswerte an.

7. Anmelden und überprüfen

Führen Sie das Portal aus und öffnen Sie die Anmeldeseite. Ein Microsoft-Button erscheint nun unter den Anmeldeoptionen. Beim ersten Anmelden eines Kontos verknüpft das Portal die Microsoft-Identität mit einem Portalnutzer – indem ein bestehender Kontakt per E-Mail abgestimmt wird, wo möglich, und ansonsten den Besucher mit vorausgefülltem Namen und E-Mail-Adresse durch die Registrierung führt.

Wenn das Konto auch als Dataverse systemuserexistiert, kann die Sitzung als dieser interne Benutzer statt als Kontakt ausgeführt werden. Dieses Verhalten erfordert keine zusätzliche Konfiguration bei der App-Registrierung: Siehe SystemUser-Anmeldung

Fehlerbehebung