Freigeben über

Erstellen und Lesen eines Benutzerkontos mithilfe einer benutzerdefinierten Azure Active Directory B2C-Richtlinie

  • Artikel

Azure Active Directory B2C (Azure AD B2C) basiert auf Microsoft Entra ID und verwendet daher den Microsoft Entra ID-Speicher zum Speichern von Benutzerkonten. Das Benutzerprofil des Azure AD B2C-Verzeichnisses enthält einen integrierten Satz von Attributen, z. B. Vorname, Nachname, Ort, Postleitzahl und Telefonnummer, aber Sie können das Benutzerprofil um Ihre eigenen benutzerdefinierten Attribute erweitern, ohne dass ein externer Datenspeicher erforderlich ist.

Ihre benutzerdefinierte Richtlinie kann mithilfe des technischen Microsoft Entra ID-Profils eine Verbindung mit dem Microsoft Entra ID-Speicher herstellen, um Benutzerinformationen zu speichern, zu aktualisieren oder zu löschen. In diesem Artikel erfahren Sie, wie Sie eine Reihe von technischen Microsoft Entra ID-Profilen konfigurieren, um ein Benutzerkonto zu speichern und zu lesen, bevor ein JWT-Token zurückgegeben wird.

Beschreibung des Szenarios

Im Artikel Aufrufen einer REST-API mithilfe einer benutzerdefinierten Azure Active Directory B2C-Richtlinie haben wir Informationen von Benutzer*innen gesammelt, die Daten überprüft, eine REST-API aufgerufen und schließlich ein JWT zurückgegeben, ohne ein Benutzerkonto zu speichern. Wir müssen die Benutzerinformationen speichern, damit die Informationen nicht verloren gehen, nachdem die Richtlinie die Ausführung abgeschlossen hat. Nachdem wir diesmal die Benutzerinformationen erfasst und überprüft haben, müssen wir die Benutzerinformationen im Azure AD B2C-Speicher speichern und dann lesen, bevor wir das JWT-Token zurückgeben. Der vollständige Prozess ist im folgenden Diagramm dargestellt.

A flowchart of creating a user account in Azure AD.

Voraussetzungen

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 – Deklarieren von Ansprüchen

Sie müssen zwei weitere Ansprüche deklarieren, userPrincipalNameund passwordPolicies:

  1. Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem Element ClaimsSchema, und deklarieren Sie userPrincipalName- und passwordPolicies-Ansprüche mithilfe des folgenden Codes:

        <ClaimType Id="userPrincipalName">
        <DisplayName>UserPrincipalName</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Your user name as stored in the Azure Active Directory.</UserHelpText>
    </ClaimType>
    <ClaimType Id="passwordPolicies">
        <DisplayName>Password Policies</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Password policies used by Azure AD to determine password strength, expiry etc.</UserHelpText>
    </ClaimType>

    Weitere Informationen zu den Verwendungen der userPrincipalName- und passwordPolicies-Ansprüche finden Sie im Artikel Benutzerprofilattribute.

Schritt 2: Erstellen von technischen Microsoft Entra ID-Profilen

Sie müssen zwei technische Microsoft Entra ID-Profile konfigurieren. Ein technisches Profil schreibt Benutzerdetails in den Microsoft Entra ID-Speicher, das andere liest ein Benutzerkonto aus dem Microsoft Entra ID-Speicher.

  1. Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem Element ClaimsProviders, und fügen Sie mithilfe des nachstehenden Codes einen neuen Anspruchsanbieter hinzu. Dieser Anspruchsanbieter enthält die technischen Microsoft Entra ID-Profile:

        <ClaimsProvider>
        <DisplayName>Azure AD Technical Profiles</DisplayName>
        <TechnicalProfiles>
            <!--You'll add you Azure AD Technical Profiles here-->
        </TechnicalProfiles>
    </ClaimsProvider>

  2. Fügen Sie dem soeben erstellten Anspruchsanbieter mithilfe des folgenden Codes ein technisches Microsoft Entra ID-Profil hinzu:

        <TechnicalProfile Id="AAD-UserWrite">
        <DisplayName>Write user information to AAD</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Write</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
            <Item Key="UserMessageIfClaimsPrincipalAlreadyExists">The account already exists. Try to create another account</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <PersistedClaims>
            <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />        
            <PersistedClaim ClaimTypeReferenceId="displayName" />
            <PersistedClaim ClaimTypeReferenceId="givenName" />
            <PersistedClaim ClaimTypeReferenceId="surname" />
            <PersistedClaim ClaimTypeReferenceId="password"/>
            <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration,DisableStrongPassword" />
        </PersistedClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
        </OutputClaims>
    </TechnicalProfile>

    Wir haben ein neues technisches Microsoft Entra ID-Profil namens AAD-UserWrite hinzugefügt. Wir müssen die folgenden wichtigen Teile des technischen Profils beachten:

    • Vorgang: Der Vorgang gibt die auszuführende Aktion an, in diesem Fall Schreiben. Erfahren Sie mehr über andere Vorgänge in einem technischen Microsoft Entra ID-Anbieter.

    • Persistente Ansprüche: Das Element PersistedClaims enthält alle Werte, die im Microsoft Entra ID-Speicher gespeichert werden sollen.

    • InputClaims: Das Element InputClaims enthält einen Anspruch, der verwendet wird, um im Verzeichnis nach einem Konto zu suchen oder ein neues Konto zu erstellen. In der Auflistung der Eingabeansprüche für alle technischen Microsoft Entra ID-Profile muss genau ein Element „Eingabeanspruch“ vorhanden sein. Dieses technische Profil verwendet den E-Mail-Anspruch als Schlüsselbezeichner für das Benutzerkonto. Erfahren Sie mehr über andere Schlüsselbezeichner, die Sie verwenden können, um ein Benutzerkonto eindeutig zu identifizieren.

  3. Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem technischen AAD-UserWrite-Profil, und fügen Sie dann ein technisches Profil hinzu, indem Sie den folgenden Code verwenden:

        <TechnicalProfile Id="AAD-UserRead">
        <DisplayName>Read user from Azure AD storage</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Read</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">false</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="givenName"/>
            <OutputClaim ClaimTypeReferenceId="surname"/>
            <OutputClaim ClaimTypeReferenceId="displayName"/>
        </OutputClaims>
    </TechnicalProfile>

    Wir haben ein neues technisches Microsoft Entra ID-Profil namens AAD-UserRead hinzugefügt. Wir haben dieses technische Profil so konfiguriert, dass es einen Lesevorgang ausführt und die Ansprüche objectId, userPrincipalName, givenName, surname unddisplayName zurückgibt, wenn ein Benutzerkonto mit dem email im InputClaim-Abschnitt gefunden wird.

Schritt 3: Verwenden des technischen Microsoft Entra ID-Profils

Nachdem wir Benutzerdetails mithilfe des selbstbestätigten technischen UserInformationCollector-Profils erfasst haben, müssen wir mithilfe des technischen AAD-UserWrite-Profils ein Benutzerkonto in den Microsoft Entra ID-Speicher schreiben. Verwenden Sie dazu das technische AAD-UserWrite-Profil als technisches Validierungsprofil im selbstbestätigten technischen UserInformationCollector-Profil.

Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem technischen UserInformationCollector-Profil, und fügen Sie dann ein technisches AAD-UserWrite-Profil als technisches Validierungsprofil in der ValidationTechnicalProfiles-Auflistung hinzu. Sie müssen dies nach dem technischen CheckCompanyDomain-Validierungsprofil hinzufügen.

Wir verwenden das technische AAD-UserRead-Profil in den Schritten zur Orchestrierung der User Journey, um die Benutzerdetails vor der Ausgabe eines JWT-Tokens zu lesen.

Schritt 4 – Aktualisieren des technischen ClaimGenerator-Profils

Wir verwenden das technische ClaimGenerator-Profil, um drei Anspruchstransformationen auszuführen: GenerateRandomObjectIdTransformation, CreateDisplayNameTransformation und CreateMessageTransformation.

  1. Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem technischen ClaimGenerator-Profil, und ersetzen Sie es durch den folgenden Code:

        <TechnicalProfile Id="UserInputMessageClaimGenerator">
        <DisplayName>User Message Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="message" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateMessageTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

    <TechnicalProfile Id="UserInputDisplayNameGenerator">
        <DisplayName>Display Name Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateDisplayNameTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

    Wir haben das technische Profil in zwei separate technische Profile unterteilt. Das technische UserInputMessageClaimGenerator-Profil generiert die als Anspruch im JWT-Token gesendete Nachricht. Das technische UserInputDisplayNameGenerator-Profil generiert den displayName-Anspruch. Der displayName-Anspruchswert muss verfügbar sein, bevor das technische AAD-UserWrite-Profil den Benutzerdatensatz in den Microsoft Entra ID-Speicher schreibt. Im neuen Code entfernen wir die GenerateRandomObjectIdTransformation, da das objectId von Microsoft Entra ID erstellt und zurückgegeben wird, nachdem ein Konto erstellt wurde, sodass wir es nicht selbst innerhalb der Richtlinie generieren müssen.

  2. Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem technischen UserInformationCollector-Profil, und fügen Sie dann das technische UserInputDisplayNameGenerator-Profil als technisches Validierungsprofil hinzu. Danach sollte die ValidationTechnicalProfiles-Auflistung des technischen UserInformationCollector-Profils ähnlich dem folgenden Code aussehen:

        <!--<TechnicalProfile Id="UserInformationCollector">-->
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="CheckCompanyDomain">
                <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                        <Value>accountType</Value>
                        <Value>work</Value>
                        <Action>SkipThisValidationTechnicalProfile</Action>
                    </Precondition>
                </Preconditions>
            </ValidationTechnicalProfile>                        
            <ValidationTechnicalProfile ReferenceId="DisplayNameClaimGenerator"/>
            <ValidationTechnicalProfile ReferenceId="AAD-UserWrite"/>
        </ValidationTechnicalProfiles>
    <!--</TechnicalProfile>-->

    Sie müssen das technische Validierungsprofil vor AAD-UserWrite hinzufügen, da der displayName-Anspruchswert verfügbar sein muss, bevor das technische AAD-UserWrite-Profil den Benutzerdatensatz in den Microsoft Entra ID-Speicher schreibt.

Schritt 5 – Aktualisieren der Schritte zur Orchestrierung der User Journey

Suchen Sie Ihre HelloWorldJourney-User Journey, und fügen Sie alle Orchestrierungsschritte mit dem folgenden Code hinzu:

    <!--<OrchestrationSteps>-->
        <OrchestrationStep Order="1" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
            </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetUserInformationClaimsExchange" TechnicalProfileReferenceId="UserInformationCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

Im Orchestrierungsschritt 4 führen wir das technische AAD-UserRead-Profil aus, um die Benutzerdetails (die in das JWT-Token eingeschlossen werden sollen) aus dem erstellten Benutzerkonto zu lesen.

Da wir den message-Anspruch im Orchestrierungsschritt 5 nicht speichern, führen wir den UserInputMessageClaimGenerator aus, um den message-Anspruch für die Aufnahme in das JWT-Token zu generieren.

Schritt 6 – Hochladen der Richtlinie

Führen Sie die Schritte unter Hochladen einer benutzerdefinierten Richtliniendatei aus, um Ihre Richtliniendatei hochzuladen. Wenn Sie eine Datei mit dem gleichen Namen wie eine 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 7 – Testen der Richtlinie

Führen Sie die Schritte unter Testen der benutzerdefinierten Richtlinie aus, um Ihre benutzerdefinierte Richtlinie zu testen.

Nachdem die Richtlinie die Ausführung abgeschlossen hat und Sie Ihr ID-Token erhalten haben, überprüfen Sie, dass der Benutzerdatensatz erstellt wurde:

  1. Melden Sie sich im Azure-Portal als Benutzer mit Berechtigungen der Rollen „Globaler Administrator“ oder „Administrator für privilegierte Rollen“ an.

  2. Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C Mandanten zu wechseln.

  3. Wählen Sie unter Azure-Dienste die Option Azure AD B2C aus. Oder verwenden Sie das Suchfeld, um nach Azure AD B2C zu suchen und diese Option auszuwählen.

  4. Wählen Sie unter Verwalten die Option Benutzer aus.

  5. Suchen Sie das soeben von Ihnen erstellte Benutzerkonto, und wählen Sie es aus. Das Kontoprofil sieht ähnlich aus wie im nachfolgenden Screenshot:

    A screenshot of creating a user account in Azure AD.

In unserem technischen Microsoft Entra ID-Profil AAD-UserWrite geben wir an, dass wir eine Fehlermeldung auslösen, wenn der Benutzer oder die Benutzerin bereits vorhanden ist.

Testen Sie Ihre benutzerdefinierte Richtlinie erneut, indem Sie dieselbe Email Adresseverwenden. Anstatt dass die Richtlinie bis zum Abschluss ausgeführt wird, um ein ID-Token auszugeben, sollten Sie eine Fehlermeldung ähnlich dem folgenden Screenshot sehen.

A screenshot of error as account already exists.

Hinweis

Der Kennwort-Anspruchswert ist eine sehr wichtige Information, seien Sie also sehr vorsichtig, wie Sie ihn in Ihrer benutzerdefinierten Richtlinie behandeln. Aus einem ähnlichen Grund behandelt Azure AD B2C den Kennwortanspruchswert als einen besonderen Wert. Wenn Sie den Kennwortanspruchswert im selbstbestätigten technischen Profil sammeln, ist dieser Wert nur innerhalb desselben technischen Profils oder innerhalb eines technischen Validierungsprofils verfügbar, auf welches dasselbe selbstbestätigte technische Profil verweist. Sobald die Ausführung dieses selbstbestätigten technischen Profils abgeschlossen ist und zu einem anderen technischen Profil wechselt, geht der Wert verloren.

E-Mail-Adresse des Benutzers überprüfen

Es wird empfohlen, die E-Mail-Adresse eines Benutzers zu überprüfen, bevor Sie diese zum Erstellen eines Benutzerkontos verwenden. Wenn Sie E-Mail-Adressen überprüfen, stellen Sie sicher, dass die Konten von echten Benutzern erstellt wurden. Sie helfen Benutzern auch dabei, sicher zu sein, dass sie ihre richtigen E-Mail-Adressen verwenden, um ein Konto zu erstellen.

Die benutzerdefinierte Richtlinie von Azure AD B2C bietet eine Möglichkeit, die E-Mail-Adresse mithilfe des Anzeigesteuerelements zur Überprüfung zu überprüfen. Sie senden einen Prüfcode an die E-Mail-Adresse. Nachdem der Code gesendet wurde, liest der Benutzer die Nachricht, gibt den Prüfcode in das vom Anzeigesteuerelement bereitgestellte Steuerelement ein und wählt die Schaltfläche Code überprüfen aus.

Ein Anzeigesteuerelement ist ein Benutzeroberflächenelement mit spezieller Funktionalität, das mit dem Back-End-Dienst von Azure Active Directory B2C (Azure AD B2C) interagiert. Es ermöglicht dem Benutzer das Durchführen von Aktionen auf der Seite, die ein technisches Validierungsprofil auf dem Back-End aufrufen. Anzeigesteuerelemente werden auf der Seite angezeigt, und ein selbstbestätigtes technisches Profil verweist auf diese.

Führen Sie die folgenden Schritte aus, um die E-Mail-Überprüfung mithilfe eines Anzeigesteuerelements hinzuzufügen:

Anspruch deklarieren

Sie müssen einen Anspruch deklarieren, der zum Halten des Prüfcodes verwendet werden soll.

Um den Anspruch zu deklarieren, suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem ClaimsSchema-Element, und deklarieren Sie den verificationCode-Anspruch mithilfe des folgenden Codes:

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="verificationCode">
            <DisplayName>Verification Code</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Enter your verification code</UserHelpText>
            <UserInputType>TextBox</UserInputType>
        </ClaimType>
    <!--</ClaimsSchema>-->

Konfigurieren eines technischen Profils zum Senden und Überprüfen von Code

Azure AD B2C verwendet das technische Microsoft Entra ID-Profil für die Self-Service-Kennwortzurücksetzung, um eine E-Mail-Adresse zu überprüfen. Dieses technische Profil kann einen Code generieren und an eine E-Mail-Adresse senden, oder es überprüft den Code, je nachdem, wie Sie es konfigurieren.

Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem ClaimsProviders-Element, und fügen Sie den Anspruchsanbieter mithilfe des folgenden Codes hinzu:

    <ClaimsProvider>
        <DisplayName>Azure AD self-service password reset (SSPR)</DisplayName>
        <TechnicalProfiles>
            <TechnicalProfile Id="AadSspr-SendCode">
            <DisplayName>Send Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">SendCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
            <TechnicalProfile Id="AadSspr-VerifyCode">
            <DisplayName>Verify Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">VerifyCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="verificationCode" />
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
        </TechnicalProfiles>
    </ClaimsProvider>

Wir haben zwei technische Profile AadSspr-SendCode und AadSspr-VerifyCode konfiguriert. AadSspr-SendCode generiert und sendet einen Code an die im InputClaims-Abschnitt angegebene E-Mail-Adresse, während AadSspr-VerifyCode den Code überprüft. Sie geben die Aktion, die Sie ausführen möchten, in den Metadaten des technischen Profils an.

Konfigurieren eines Anzeigesteuerelements

Sie müssen ein Anzeigesteuerelement für die E-Mail-Überprüfung konfigurieren, um die E-Mail-Adressen von Benutzern überprüfen zu können. Das von Ihnen konfigurierte Anzeigesteuerelement für die E-Mail-Überprüfung ersetzt den E-Mail-Anzeigeanspruch, den Sie zum Sammeln einer E-Mail-Adresse vom Benutzer verwenden.

Führen Sie zum Konfigurieren eines Anzeigesteuerelements die folgenden Schritte aus:

  1. Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem BuildingBlocks-Abschnitt, und fügen Sie dann mithilfe des folgenden Codes ein Anzeigesteuerelement als untergeordnetes Element hinzu:

        <!--<BuildingBlocks>-->
        ....
        <DisplayControls>
            <DisplayControl Id="emailVerificationControl" UserInterfaceControlType="VerificationControl">
              <DisplayClaims>
                <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
                <DisplayClaim ClaimTypeReferenceId="verificationCode" ControlClaimType="VerificationCode" Required="true" />
              </DisplayClaims>
              <OutputClaims></OutputClaims>
              <Actions>
                <Action Id="SendCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-SendCode" />
                  </ValidationClaimsExchange>
                </Action>
                <Action Id="VerifyCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-VerifyCode" />
                  </ValidationClaimsExchange>
                </Action>
              </Actions>
            </DisplayControl>
        </DisplayControls> 
    <!--</BuildingBlocks>-->

    Wir haben ein Anzeigesteuerelement emailVerificationControl deklariert. Beachten Sie folgende wichtigen Teile:

    • DisplayClaims – Genau wie in einem selbstbestätigten technischen Profil gibt dieser Abschnitt eine Auflistung von Ansprüchen an, die vom Benutzer innerhalb des Anzeigesteuerelements gesammelt werden sollen.

    • Aktionen – Gibt die Reihenfolge der Aktionen an, die vom Anzeigesteuerelement ausgeführt werden sollen. Jede Aktion verweist auf ein technisches Profil, das für die Ausführung der Aktionen verantwortlich ist. Beispielsweise verweist SendCode auf das technische AadSspr-SendCode-Profil, das einen Code generiert und an eine E-Mail-Adresse sendet.

  2. Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem selbstbestätigten technischen UserInformationCollector-Profil, und ersetzen Sie den E-Mail-Anzeigeanspruch durch die emailVerificationControl-Anzeigesteuerung:

    Von:

        <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>

    Nach:

        <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />

  3. Verwenden Sie das Verfahren in Schritt 6 und Schritt 7, um Ihre Richtlinie hochzuladen und auszuführen. Dieses Mal müssen Sie Ihre E-Mail-Adresse überprüfen, bevor ein Benutzerkonto erstellt wird.

Aktualisieren des Benutzerkontos mithilfe des technischen Microsoft Entra ID-Profils

Sie können ein technisches Microsoft Entra ID-Profil so konfigurieren, dass ein Benutzerkonto aktualisiert wird, anstatt zu versuchen, ein neues zu erstellen. Legen Sie hierzu das technische Microsoft Entra ID-Profil so fest, dass ein Fehler ausgelöst wird, wenn das angegebene Benutzerkonto nicht bereits in der Metadata-Auflistung vorhanden ist. Verwenden Sie dazu den folgenden Code. Der Vorgang muss auf Schreiben festgelegt werden:

    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>

Verwenden von benutzerdefinierten Attributen

In diesem Artikel haben Sie erfahren, wie Sie Benutzerdetails mithilfe integrierter Benutzerprofilattribute speichern. Sie müssen jedoch oftmals für die Verwaltung Ihres spezifischen Szenarios Ihre eigenen benutzerdefinierten Attribute erstellen. Befolgen Sie dazu die Anweisungen im Artikel Definieren von benutzerdefinierten Attributen in Azure Active Directory B2C.

Nächste Schritte