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.

Fügen Sie die E-Mail-Verifizierungsbehauptungen hinzu

Die Adresse eines Arbeits- oder Schulkontos sind Verzeichnisdaten, die der Administrator seines Mieters auf alles setzen kann, daher sendet das Portal standardmäßig beim ersten Anmelden eine Bestätigungs-E-Mail, anstatt ihm zu vertrauen. Entra kann die Adresse im ID-Token bestätigen, und das Portal behandelt sie als verifiziert, wenn es dies tut: wenn verified_primary_email oder verified_secondary_email listet sie auf, oder wenn angegeben wird xms_edov , dass seine Domain eine ist, die der eigene Mieter des Nutzers verifiziert hat. Entra sendet diese Ansprüche nur, wenn die Registrierung danach fragt:

  1. Öffnen Sie die Registrierung und wählen Sie Token-Konfiguration.
  2. Wählen Sie + Optionale Behauptung hinzufügen, wählen Sie den ID-Tokentyp , kreuzen email, xms_edov, verified_primary_email und verified_secondary_email, und wählen Sie Hinzufügen. Wenn Sie danach gefragt werden, aktivieren Sie die Microsoft Graph-Berechtigung email , die die Ansprüche benötigen. Es handelt sich um eine grundlegende Anmeldeberechtigung, mit der Benutzer selbst zustimmen können; in einem Tenant, der nur Administratoren die Zustimmung zu Apps erlaubt, genehmigt ein Administrator diese zusammen mit dem Rest der App.

Oder fügen Sie sie dem optionalClaims Abschnitt des Registrierungsmanifests hinzu und fügen die von Microsoft Graph delegierte email Berechtigungen unter API-Berechtigungen hinzu:

Wichtig

Füge sie dem ID-Token hinzu, nicht dem Zugriffstoken. Das Portal liest sie vom ID-Token, das Microsoft beim Anmelden zurückgibt; Ansprüche auf dem Zugriffstoken erreichen nur eine API, die diese Registrierung offenlegt, von der eine Anmelderegistrierung nichts hat. Der MCP-Server create_signin_app_registration fügt sie für dich hinzu.

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

Organisationen auseinanderzuhalten

Bei einer Multi-Tenant-Registrierung melden sich Menschen aus vielen Organisationen im selben Portal an. Jede Microsoft-Anmeldung trägt ihre Entra-Tenant-ID als Claim PortalClaimTypes.TenantId auf die Sitzung, wird auf User.GetTenantId() dem Server gelesen und als von tenantId GET /api/auth/megemeldet. Nutzen Sie sie, um eine Sitzung einer Organisation zuzuordnen, zum Beispiel um zu überprüfen, ob jemand, der einen Sitz beansprucht, dem Tenant gehört, der ihn gekauft hat. Das ist die zuverlässige Methode: Die Tenant-ID stammt von einem Token, das Microsoft signiert hat, während die Adresse eines Arbeits- oder Schulkontos die ist, die der Administrator dieser Organisation eingegeben hat.

Auf andere Weise signierte Sitzungen haben keinen Mieter: lokale Konten, andere Anbieter und nachgeahmte Sitzungen, daher kann ein nachgeahmter Kontakt nicht als Mitglied der Organisation des Administrators durchgehen.

Wichtig

Jedes persönliche Microsoft-Konto meldet denselben Tenant, 9188040d-6c67-4c5b-b112-36a304b66dad (MicrosoftAccountEmailVerification.PersonalAccountTenantId). Es identifiziert keine Organisation. Lehnen Sie es ab, wo der Tenant steht, oder jedes persönliche Konto zählt als Mitglied derselben Organisation.

Fehlerbehebung