Einrichten eines Registrierungs- und Anmeldeflows für ein lokales Konto mithilfe einer benutzerdefinierten Azure Active Directory B2C-Richtlinie
Im Artikel Erstellen und Lesen eines Benutzerkontos mithilfe einer benutzerdefinierten Azure Active Directory B2C-Richtlinie erstellt ein Benutzer ein neues Benutzerkonto, meldet sich aber nicht bei diesem an.
In diesem Artikel erfahren Sie, wie Sie eine benutzerdefinierte Azure Active Directory B2C (Azure AD B2C)-Richtlinie schreiben, die es einem Benutzer ermöglicht, entweder ein lokales Azure AD B2C-Konto zu erstellen, oder sich bei einem solchen anzumelden. Ein lokales Konto ist ein Konto, das in Ihrem Azure AD B2C-Mandanten erstellt wird, wenn sich ein Benutzer für Ihre Anwendung registriert.
Übersicht
Azure AD B2C verwendet das OpenID Connect-Authentifizierungsprotokoll zum Überprüfen der Benutzeranmeldeinformationen. In Azure AD B2C senden Sie die Benutzeranmeldeinformationen zusammen mit anderen Informationen an einen sicheren Endpunkt, der dann bestimmt, ob die Anmeldeinformationen gültig sind oder nicht. Kurz gesagt: Wenn Sie die Azure AD B2C-Implementierung von OpenID Connect verwenden, können Sie die Registrierung, die Anmeldung und andere Erfahrungen der Identitätsverwaltung in Ihren Webanwendungen nach Microsoft Entra auslagern.
Die benutzerdefinierte Azure AD B2C-Richtlinie stellt ein technisches OpenID Connect-Profil bereit, das Sie verwenden, um einen sicheren Microsoft-Endpunkt aufzurufen. Erfahren Sie mehr über das technische OpenID Connect-Profil.
Voraussetzungen
Wenn Sie noch nicht über einen Azure AD B2C-Mandanten verfügen, erstellen Sie einen, der mit Ihrem Azure-Abonnement verknüpft ist.
Registrieren Sie eine Webanwendung, und aktivieren Sie die implizite Gewährung von ID-Token. Verwenden Sie https://jwt.ms für den Umleitungs-URI.
Auf Ihrem Computer muss Visual Studio Code (VS Code) installiert sein.
Führen Sie die Schritte unter Erstellen und Lesen eines Benutzerkontos mithilfe der benutzerdefinierten Azure Active Directory B2C-Richtlinie aus. Dieser Artikel ist Teil der Schrittanleitungsreihe „Erstellen und Ausführen eigener benutzerdefinierter Richtlinien“.
Hinweis
Dieser Artikel ist Teil der Schrittanleitungsreihe „Erstellen und Ausführen Ihrer eigenen benutzerdefinierten Richtlinien in Azure Active Directory B2C“. Wir empfehlen Ihnen, diese Reihe mit dem ersten Artikel zu beginnen.
Schritt 1 – Konfigurieren des technischen OpenID Connect-Profils
Zum Konfigurieren eines technischen OpenID Connect-Profils müssen Sie drei Schritte ausführen:
- Deklarieren Sie weitere Ansprüche.
- Registrieren Sie Apps in Ihrem Azure-Portal.
- Konfigurieren Sie schließlich das technische OpenID Connect-Profil selbst
Schritt 1.1 – Deklarieren weiterer Ansprüche
Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem Abschnitt ClaimsSchema, und fügen Sie dann mithilfe des folgenden Codes weitere Ansprüche hinzu:
<!--<ClaimsSchema>-->
...
<ClaimType Id="grant_type">
<DisplayName>grant_type</DisplayName>
<DataType>string</DataType>
<UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
</ClaimType>
<ClaimType Id="scope">
<DisplayName>scope</DisplayName>
<DataType>string</DataType>
<UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
</ClaimType>
<ClaimType Id="nca">
<DisplayName>nca</DisplayName>
<DataType>string</DataType>
<UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
</ClaimType>
<ClaimType Id="client_id">
<DisplayName>client_id</DisplayName>
<DataType>string</DataType>
<AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
<UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
</ClaimType>
<ClaimType Id="resource_id">
<DisplayName>resource_id</DisplayName>
<DataType>string</DataType>
<AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
<UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
</ClaimType>
<!--</ClaimsSchema>-->
Schritt 1.2 – Registrieren von Identity Experience Framework-Anwendungen
Azure AD B2C erfordert, dass Sie zwei Anwendungen registrieren, die zur Registrierung und Anmeldung von Benutzern mit lokalen Konten verwendet werden: IdentityExperienceFramework (eine Web-API) und ProxyIdentityExperienceFramework (eine native App) mit delegierter Berechtigung für die IdentityExperienceFramework-App.
Registrieren Sie die folgenden Anwendungen, wenn Sie dies noch nicht getan haben. Befolgen Sie die Anweisungen in der IEF-Setup-App, um die nachfolgende exemplarische Vorgehensweise zu automatisieren:
Verwenden Sie die Schritte unter Registrieren der IdentityExperienceFramework-Anwendung, um die Identity Experience Framework-Anwendung zu registrieren. Kopieren Sie die Anwendungs-ID (Client-ID), appID, für die Registrierung der Identity Experience Framework-Anwendung zur Verwendung im nächsten Schritt.
Verwenden Sie die Schritte unter Registrieren der ProxyIdentityExperienceFramework-Anwendung, um die Proxy-Identity Experience Framework-Anwendung zu registrieren. Kopieren Sie die Anwendungs-ID (Client-ID), proxyAppID, für die Registrierung der Proxy-Identity Experience Framework-Anwendung zur Verwendung im nächsten Schritt.
Schritt 1.3 – Konfigurieren des technischen OpenID Connect-Profils
Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem Abschnitt ClaimsProviders, und fügen Sie dann ein Element „Anspruchsanbieter“ hinzu, das Ihr technisches OpenID Connect-Profil enthält, indem Sie den folgenden Code verwenden:
<!--<ClaimsProviders>-->
...
<ClaimsProvider>
<DisplayName>OpenID Connect Technical Profiles</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="SignInUser">
<DisplayName>Sign in with Local Account</DisplayName>
<Protocol Name="OpenIdConnect" />
<Metadata>
<Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We didn't find this account</Item>
<Item Key="UserMessageIfInvalidPassword">Your password or username is incorrect</Item>
<Item Key="UserMessageIfOldPasswordUsed">You've used an old password.</Item>
<Item Key="ProviderName">https://sts.windows.net/</Item>
<Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
<Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
<Item Key="response_types">id_token</Item>
<Item Key="response_mode">query</Item>
<Item Key="scope">email openid</Item>
<!-- Policy Engine Clients -->
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="client_id">proxyAppID</Item>
<Item Key="IdTokenAudience">appID</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="username" Required="true" />
<InputClaim ClaimTypeReferenceId="password" PartnerClaimType="password" Required="true" />
<InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
<InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
<InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
<InputClaim ClaimTypeReferenceId="client_id" DefaultValue="proxyAppID" />
<InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="appID" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
</OutputClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<!--</ClaimsProviders>-->
Ersetzen Sie beide Instanzen von:
appID mit der Anwendungs-ID (Client)-ID der Identity Experience Framework-Anwendung, die Sie in Schritt 1.2 kopiert haben.
proxyAppID mit der Anwendungs-ID (Client)-ID der Proxy-Identity Experience Framework-Anwendung, die Sie in Schritt 1.2 kopiert haben.
Schritt 2 – Konfigurieren der Anmeldebenutzeroberfläche
Wenn Ihre Richtlinie ausgeführt wird, muss dem Benutzer eine Benutzeroberfläche angezeigt werden, über die er sich anmelden kann. Die Benutzeroberfläche hat auch eine Option, sich zu registrieren, wenn der Benutzer noch nicht über ein Konto verfügt. Dazu müssen Sie zwei Schritte ausführen:
- Konfigurieren Sie ein selbstbestätigtes technisches Profil, das dem Benutzer das Anmeldeformular anzeigt.
- Konfigurieren Sie die Inhaltsdefinition für die Anmeldebenutzeroberfläche.
Schritt 2.1 – Konfigurieren eines technischen Profils für die Anmeldebenutzeroberfläche
Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem technischen SignInUser-Profil, und fügen Sie anschließend ein technisches SelfAsserted-Profil hinzu, indem Sie den folgenden Code verwenden:
<TechnicalProfile Id="UserSignInCollector">
<DisplayName>Local Account Signin</DisplayName>
<Protocol Name="Proprietary"
Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="setting.operatingMode">Email</Item>
<Item Key="SignUpTarget">AccountTypeInputCollectorClaimsExchange</Item>
</Metadata>
<DisplayClaims>
<DisplayClaim ClaimTypeReferenceId="email" Required="true" />
<DisplayClaim ClaimTypeReferenceId="password" Required="true" />
</DisplayClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="password" />
<OutputClaim ClaimTypeReferenceId="objectId" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="SignInUser" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
Wir haben das technische SelfAsserted-Profil UserSignInCollector hinzugefügt, das dem Benutzer das Anmeldeformular anzeigt. Wir haben das technische Profil so konfiguriert, dass die E-Mail-Adresse des Benutzers als Anmeldename erfasst wird, wie in den setting.operatingMode-Metadaten beschrieben. Das Anmeldeformular enthält einen Registrierungslink, der den Benutzer zu einem Registrierungsformular führt, wie in den SignUpTarget-Metadaten beschrieben. In den Orchestrierungsschritten sehen Sie, wie wir SignUpWithLogonEmailExchangeClaimsExchange einrichten.
Außerdem haben wir das technische OpenID Connect-Profil SignInUser als ValidationTechnicalProfile hinzugefügt. Daher wird das technische SignInUser-Profil ausgeführt, wenn der Benutzer die Schaltfläche Anmelden auswählt (siehe Screenshot in Schritt 5).
Im nächsten Schritt (Schritt 2.2) konfigurieren wir eine Inhaltsdefinition, die wir in diesem technischen SelfAsserted-Profil verwenden.
Schritt 2.2 – Konfigurieren der Inhaltsdefinition der Anmeldeschnittstelle
Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem Abschnitt ContentDefinitions, und melden Sie sich dann bei Inhaltsdefinition mit dem folgenden Code an:
<!--<ContentDefinitions>-->
...
<ContentDefinition Id="SignupOrSigninContentDefinition">
<LoadUri>~/tenant/templates/AzureBlue/unified.cshtml</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:2.1.7</DataUri>
<Metadata>
<Item Key="DisplayName">Signin and Signup</Item>
</Metadata>
</ContentDefinition>
<!--</ContentDefinitions>-->
Wir haben eine Inhaltsdefinition für unser selbstbestätigtes technisches Profil SignupOrSigninContentDefinition konfiguriert. Wir können sie im technischen Profil mithilfe des Metadatenelements angeben, oder sie angeben, wenn wir in den Orchestrierungsschritten auf das technische Profil verweisen. Zuvor haben wir erfahren, wie Sie eine Inhaltsdefinition direkt im selbstbestätigten technischen Profil angeben. In diesem Artikel erfahren wir nun, wie sie angegeben wird, wenn wir in den Orchestrierungsschritten, Schritt 3, auf das technische Profil verweisen.
Schritt 3 – Aktualisieren der Schritte zur Orchestrierung der User Journey
Suchen Sie in der ContosoCustomPolicy.XML-Datei nach der HelloWorldJourney-User Journey, und ersetzen Sie deren Orchestrierungsschritte-Auflistung durch den folgenden Code:
<!--<OrchestrationSteps>-->
...
<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition">
<ClaimsProviderSelections>
<ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
</ClaimsProviderSelections>
<ClaimsExchanges>
<ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="3" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
<Precondition Type="ClaimEquals" ExecuteActionsIf="true">
<Value>accountType</Value>
<Value>company</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="4" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="5" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="6" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
<!--</OrchestrationSteps>-->
In den Orchestrierungsschritten zwei bis fünf haben wir Vorbedingungen verwendet, um zu bestimmen, ob der Schritt „Orchestrierung“ ausgeführt werden soll. Wir müssen ermitteln, ob sich der Benutzer anmeldet oder registriert.
Wenn die benutzerdefinierte Richtlinie ausgeführt wird:
Orchestrierung – Schritt 1 – Zeigt die Anmeldeseite an, damit sich der Benutzer anmelden oder den Link Jetzt registrieren auswählen kann. Beachten Sie, dass wir die Inhaltsdefinition angeben, die das selbstbestätigte technische Profil UserSignInCollector verwendet, um das Anmeldeformular anzuzeigen.
Orchestrierung – Schritt 2 – Dieser Schritt wird ausgeführt, wenn sich der Benutzer registriert (
objectIdist nicht vorhanden). Daher wird das Formular zur Auswahl des Kontotyps angezeigt, indem das selbstbestätigte technische Profil AccountTypeInputCollector aufgerufen wird.Orchestrierung – Schritt 3 – Dieser Schritt wird ausgeführt, wenn sich der Benutzer registriert (
objectIdist nicht vorhanden) und dieser Benutzer kein UnternehmenaccountTypeauswählt. Daher müssen wir den Benutzer bitten, einaccessCodeeinzugeben, indem das selbstbestätigte technische Profil AccessCodeInputCollector aufgerufen wird.Orchestrierung – Schritt 4 – Dieser Schritt wird ausgeführt, wenn sich der Benutzer registriert (objectId ist nicht vorhanden). Daher wird das Registrierungsformular angezeigt, indem das selbstbestätigte technische Profil UserInformationCollector aufgerufen wird.
Orchestrierung – Schritt 5: In diesem Schritt werden Kontoinformationen aus Microsoft Entra ID gelesen (das technische Microsoft Entra ID-Profil
AAD-UserReadwird aufgerufen), sodass eine Ausführung unabhängig davon stattfindet, ob sich ein*e Benutzer*in registriert oder anmeldet.Orchestrierung – Schritt 6 – Dieser Schritt ruft das technische Profil UserInputMessageClaimGenerator auf, um die Begrüßungsnachricht des Benutzers zusammenzustellen.
Orchestrierung – Schritt 7 – Schließlich wird in Schritt 8 das JWT-Token am Ende der Ausführung der Richtlinie zusammengesetzt und zurückgegeben.
Schritt 4 – Hochladen der Richtlinie
Führen Sie die Schritte unter Hochladen einer benutzerdefinierten Richtliniendatei aus, um Ihre Richtliniendatei hochzuladen. Wenn Sie eine Datei mit demselben Namen wie die Datei hochladen, die bereits im Portal vorhanden ist, stellen Sie sicher, dass Sie Überschreiben der benutzerdefinierten Richtlinie, sofern sie bereits vorhanden ist auswählen.
Schritt 5 – Testen der Richtlinie
Führen Sie die Schritte unter Testen der benutzerdefinierten Richtlinie aus, um Ihre benutzerdefinierte Richtlinie zu testen. Sobald die Richtlinie ausgeführt wird, wird eine Schnittstelle ähnlich dem folgenden Screenshot angezeigt:
Sie können sich anmelden, indem Sie die Email Adresse und das Kennwort eines vorhandenen Kontos eingeben. Wenn Sie noch kein Konto haben, müssen Sie den Link Jetzt registrieren auswählen, um ein neues Benutzerkonto zu erstellen.
Nächste Schritte
Erfahren Sie, wie Sie einen Registrierungs- und Anmeldeflow mithilfe eines Social Media-Kontos mithilfe einer benutzerdefinierten Azure Active Directory B2C-Richtlinie einrichten.
Erfahren Sie, wie Sie den Registrierungslink entfernen, damit sich Benutzer einfach anmelden können.
Erfahren Sie mehr über das technische OpenID Connect-Profil.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für