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

Von Bedeutung

Ab dem 1. Mai 2025 steht Azure AD B2C nicht mehr für neue Kunden zur Verfügung. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen.

Azure Active Directory B2C (Azure AD B2C) basiert auf Microsoft Entra-ID und verwendet daher Microsoft Entra ID-Speicher zum Speichern von Benutzerkonten. Das Azure AD B2C-Verzeichnisbenutzerprofil enthält eine integrierte Gruppe von Attributen, z. B. Vorname, Nachname, Ort, Postleitzahl und Telefonnummer, aber Sie können das Benutzerprofil mit Ihren eigenen benutzerdefinierten Attributen erweitern , ohne dass ein externer Datenspeicher erforderlich ist.

Ihre benutzerdefinierte Richtlinie kann mithilfe des technischen Profils von Microsoft Entra ID 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 technischer Microsoft Entra ID-Profile konfigurieren, um ein Benutzerkonto zu speichern und zu lesen, bevor ein JWT zurückgegeben wird.

Beschreibung des Szenarios

Im Artikel Call a REST API mithilfe von Azure Active Directory B2C Custom Policy sammeln wir Informationen vom Benutzer, validieren die Daten, rufen eine REST API auf und geben schließlich ein JWT zurück, ohne ein Benutzerkonto zu speichern. Wir müssen die Benutzerinformationen speichern, damit die Informationen nach Abschluss der Ausführung der Richtlinie nicht verloren gehen. Dieses Mal, nachdem wir die Benutzerinformationen gesammelt und überprüft haben, müssen wir die Benutzerinformationen im Azure AD B2C-Speicher speichern und dann lesen, bevor wir den JWT zurückgeben. Der vollständige Prozess wird im folgenden Diagramm dargestellt.

Ein Flussdiagramm zum Erstellen eines Benutzerkontos in Azure AD.

Voraussetzungen

Wenn Sie noch keins haben, erstellen Sie einen Azure AD B2C-Mandanten , der mit Ihrem Azure-Abonnement verknüpft ist.
Registrieren Sie eine Webanwendung.
Sie müssen Visual Studio Code (VS Code) auf Ihrem Computer installiert haben.
Führen Sie die Schritte unter Aufrufen einer REST-API mithilfe der benutzerdefinierten Azure Active Directory B2C-Richtlinie aus. Dieser Artikel ist Teil von Create and run your own custom policies how-to guide series.

Hinweis

Dieser Artikel ist Teil der Anleitungsreihe "Erstellen und Ausführen eigener benutzerdefinierter Richtlinien" in Azure Active Directory B2C. Es wird empfohlen, diese Reihe aus dem ersten Artikel zu starten.

Schritt 1 : Deklarieren von Ansprüchen

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

Suchen Sie im ContosoCustomPolicy.XML-Datei das ClaimsSchema-Element und deklarieren Sie die 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>

Erfahren Sie mehr über die Verwendung der userPrincipalName und passwordPolicies Claims im Artikel "Benutzerprofilattribute".

Schritt 2 : Erstellen von technischen Profilen der Microsoft Entra ID

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

Suchen Sie in der ContosoCustomPolicy.XML Datei das ClaimsProviders-Element , und fügen Sie mithilfe des folgenden Codes einen neuen Anspruchsanbieter hinzu. Dieser Anspruchsanbieter enthält die technischen Profile der Microsoft Entra-ID:
```
    <ClaimsProvider>
        <DisplayName>Azure AD Technical Profiles</DisplayName>
        <TechnicalProfiles>
            
        </TechnicalProfiles>
    </ClaimsProvider>
```

Fügen Sie in dem soeben erstellten Anspruchsanbieter mithilfe des folgenden Codes ein technisches Profil der Microsoft Entra-ID 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 Profil der Microsoft Entra ID hinzugefügt. AAD-UserWrite Beachten Sie die folgenden wichtigen Teile des technischen Profils:

Operation: Der Vorgang gibt die auszuführende Aktion an, in diesem Fall Write. Erfahren Sie mehr über andere Vorgänge in einem technischen Microsoft Entra ID-Anbieter.
Persistierte Ansprüche: Das PersistedClaims-Element enthält alle Werte, die in den Microsoft Entra ID-Speicher gespeichert werden sollen.
InputClaims: Das InputClaims-Element enthält einen Anspruch, der verwendet wird, um ein Konto im Verzeichnis nachzuschlagen oder eine neue zu erstellen. Es muss genau ein Eingabeanspruchselement in der Eingabeanspruchssammlung für alle technischen Profile der Microsoft Entra-ID vorhanden sein. Dieses technische Profil verwendet die E-Mail-Anforderung als Schlüsselkennzeichnung für das Benutzerkonto. Erfahren Sie mehr über andere Schlüsselbezeichner, die Sie eindeutig verwenden können, um ein Benutzerkonto zu identifizieren.

Suchen Sie in der ContosoCustomPolicy.XML Datei nach dem AAD-UserWrite technischen Profil, und fügen Sie anschließend mithilfe des folgenden Codes ein neues technisches Profil hinzu:

    <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 Profil der Microsoft Entra ID hinzugefügt. AAD-UserRead Dieses technische Profil wurde so konfiguriert, dass es einen Lesevorgang ausführt und die Ansprüche objectId, userPrincipalName, givenName, surname und displayName zurückgibt, wenn ein Benutzerkonto mit dem email im Abschnitt InputClaim gefunden wird.

Schritt 3 : Verwenden des technischen Profils der Microsoft Entra-ID

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

Suchen Sie in der ContosoCustomPolicy.XML Datei das UserInformationCollector technische Profil, und fügen Sie dann AAD-UserWrite technisches Profil als Validierungs-technisches-Profil in der ValidationTechnicalProfiles Sammlung hinzu. Sie müssen dies nach dem technischen Validierungsprofil CheckCompanyDomain 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 zu lesen.

Schritt 4 – Aktualisieren des technischen Profils "ClaimGenerator"

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

Suchen Sie in der ContosoCustomPolicy.XML Datei das ClaimGenerator technische 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 Profil userInputMessageClaimGenerator generiert die Nachricht, die als Anspruch im JWT gesendet wird. Das technische UserInputDisplayNameGenerator-Profil generiert den displayName-Anspruch. Der displayName-Anspruchswert muss verfügbar sein, bevor das technische Profil AAD-UserWrite den Benutzerdatensatz in den Microsoft Entra ID-Speicher schreibt. Im neuen Code entfernen wir die GenerateRandomObjectIdTransformation , da die objectId Von Microsoft Entra-ID erstellt und zurückgegeben wird, nachdem ein Konto erstellt wurde. Daher müssen wir sie nicht selbst innerhalb der Richtlinie generieren.

Suchen Sie in der ContosoCustomPolicy.XML Datei nach dem UserInformationCollector selbst bestätigten technischen Profil, und fügen Sie dann das UserInputDisplayNameGenerator technische Profil als validierungstechnisches Profil hinzu. Nachdem Sie dies getan haben, sollte die Sammlung des technischen Profils UserInformationCollectorValidationTechnicalProfiles dem folgenden Code ähneln:

    <!--<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="UserInputDisplayNameGenerator"/>
            <ValidationTechnicalProfile ReferenceId="AAD-UserWrite"/>
        </ValidationTechnicalProfiles>
    <!--</TechnicalProfile>-->

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

Schritt 5 – Aktualisieren der Schritte zur Benutzerreise-Orchestrierung

Suchen Sie Ihre User Journey HelloWorldJourney, und ersetzen Sie alle Orchestrierungsschritte durch den folgenden Code:

    <!--<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 4führen wir das AAD-UserRead technische Profil aus, um die Benutzerdetails (die im JWT enthalten sein sollen) aus dem erstellten Benutzerkonto zu lesen.

Da wir den message Anspruch nicht speichern, führen wir im Orchestrierungsschritt 5 den UserInputMessageClaimGenerator aus, um den message Anspruch zur Einbindung in das JWT zu generieren.

Schritt 6 : Uploadrichtlinie

Folgen Sie den Schritten in Datei für benutzerdefinierte Richtlinien hochladen, um Ihre Richtliniendatei hochzuladen. Wenn Sie eine Datei mit demselben Namen wie die datei hochladen, die sich bereits im Portal befindet, stellen Sie sicher, dass Sie die benutzerdefinierte Richtlinie überschreiben, falls sie bereits vorhanden ist.

Schritt 7 – Testrichtlinie

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, überprüfen Sie, ob der Benutzerdatensatz erstellt wurde:

Melden Sie sich beim Azure-Portal an.
Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben aus, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C-Mandanten zu wechseln.
Wählen Sie unter Azure-DiensteAzure AD B2C aus. Oder verwenden Sie das Suchfeld, um Azure AD B2C zu suchen und auszuwählen.
Wählen Sie unter Verwalten die Option Benutzer aus.
Suchen Sie das soeben erstellte Benutzerkonto, und wählen Sie es aus. Das Kontoprofil sieht ähnlich wie der folgende Screenshot aus:

In unserem technischen Profil der AAD-UserWrite Microsoft Entra ID geben wir an, dass eine Fehlermeldung ausgelöst wird, wenn der Benutzer bereits vorhanden ist.

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

Screenshot des Fehlers bei einem bereits vorhandenen Konto

Hinweis

Der Wert des Kennwortanspruchs ist ein sehr wichtiger Informationsteil. Achten Sie daher darauf, wie Sie ihn in Ihrer benutzerdefinierten Richtlinie behandeln. Aus einem ähnlichen Grund behandelt Azure AD B2C den Kennwortanspruchswert als sonderwert. Wenn Sie den Wert des Kennwortanspruchs im selbst bestätigten technischen Profil erfassen, ist dieser Wert nur innerhalb desselben technischen Profils oder in einem Validierungs-technischen Profil verfügbar, auf das von diesem selbst bestätigten technischen Profil verwiesen wird. Nachdem die Ausführung dieses selbstbestätigten technischen Profils abgeschlossen und der Wechsel zu einem anderen technischen Profil vollzogen wurde, geht der Wert verloren.

Überprüfen der E-Mail-Adresse des Benutzers

Es wird empfohlen, die E-Mail-Adresse eines Benutzers zu überprüfen, bevor Sie sie zum Erstellen eines Benutzerkontos verwenden. Wenn Sie E-Mail-Adressen überprüfen, stellen Sie sicher, dass die Konten von echten Benutzern erstellt werden. Sie helfen Benutzern auch, sicherzustellen, 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 Überprüfungsanzeigesteuerelements zu überprüfen. Sie senden einen Überprüfungscode an die E-Mail. Nachdem der Code gesendet wurde, liest der Benutzer die Nachricht, gibt den Überprüfungscode in das vom Anzeigesteuerelement bereitgestellte Steuerelement ein und wählt die Schaltfläche " Code überprüfen " aus.

Ein Anzeigesteuerelement ist ein Benutzeroberflächenelement, das über spezielle Funktionen verfügt und mit dem Azure Active Directory B2C (Azure AD B2C)-Back-End-Dienst interagiert. Er ermöglicht es dem Benutzer, Aktionen auf der Seite auszuführen, die ein technisches Überprüfungsprofil am Back-End aufrufen. Anzeigesteuerelemente werden auf der Seite angezeigt, und ein selbstbestätigtes technisches Profil verweist darauf.

Führen Sie die folgenden Schritte aus, um die E-Mail-Verifizierung mithilfe eines Anzeigeelements hinzuzufügen:

Anspruch deklarieren

Sie müssen einen Anspruch deklarieren, der zum Halten des Überprüfungscodes verwendet werden soll.

Um den Anspruch in der ContosoCustomPolicy.XML Datei zu deklarieren, suchen Sie das ClaimsSchema Element, und deklarieren verificationCode Sie den 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>-->

"Ein technisches Profil zum Senden und Verifizieren von Codes konfigurieren"

Azure AD B2C verwendet das technische Profil der Microsoft Entra ID SSPR , um eine E-Mail-Adresse zu überprüfen. Dieses technische Profil kann einen Code an eine E-Mail-Adresse generieren und senden oder den Code je nach Konfiguration überprüft.

Suchen Sie in der ContosoCustomPolicy.XML Datei das 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 konfiguriert und AadSspr-VerifyCode. AadSspr-SendCode generiert und sendet einen Code an die im InputClaims Abschnitt angegebene E-Mail-Adresse, während AadSspr-VerifyCode der Code überprüft wird. Sie geben die Aktion an, die Sie in den Metadaten des technischen Profils ausführen möchten.

Konfigurieren eines Anzeigesteuerelements

Sie müssen ein Anzeigesteuerelement für die E-Mail-Überprüfung konfigurieren, um die E-Mail-Adresse der Benutzer zu überprüfen. 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 von Benutzenden verwenden.

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

Suchen Sie in der ContosoCustomPolicy.XML Datei den BuildingBlocks Abschnitt, und fügen Sie dann ein Anzeigesteuerelement als untergeordnetes Element hinzu, indem Sie den folgenden Code verwenden:

    <!--<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 deklariert. emailVerificationControl Beachten Sie die folgenden wichtigen Teile:

DisplayClaims – Genau wie in einem selbst bestätigten technischen Profil gibt dieser Abschnitt eine Sammlung 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 AadSspr-SendCode technische Profil, das einen Code an eine E-Mail-Adresse generiert und sendet.

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

Von:
```
    <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
```
Nach:
```
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
```
Verwenden Sie das Verfahren in Schritt 6 und Schritt 7 , um Ihre Richtliniendatei hochzuladen und zu testen. Dieses Mal müssen Sie Ihre E-Mail-Adresse überprüfen, bevor ein Benutzerkonto erstellt wird.

Aktualisieren des Benutzerkontos mithilfe des technischen Profils der Microsoft Entra-ID

Sie können ein technisches Microsoft Entra-ID-Profil konfigurieren, um ein Benutzerkonto zu aktualisieren, anstatt zu versuchen, eine neue zu erstellen. Legen Sie dazu das technische Profil der Microsoft Entra-ID fest, um einen Fehler auszulösen, wenn das angegebene Benutzerkonto nicht bereits in der Metadatensammlung vorhanden ist, indem Sie den folgenden Code verwenden. Entfernen Sie außerdem den Key="UserMessageIfClaimsPrincipalAlreadyExists Metadateneintrag. Der Vorgang muss auf "Schreiben" festgelegt werden:

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

Verwenden von benutzerdefinierten Attributen

In diesem Artikel haben Sie erfahren, wie Sie Benutzerdetails mithilfe integrierter Benutzerprofilattribute speichern. Sie müssen jedoch häufig eigene benutzerdefinierte Attribute erstellen, um Ihr spezifisches Szenario zu verwalten. Befolgen Sie dazu die Anweisungen unter Definieren von benutzerdefinierten Attributen im Azure Active Directory B2C-Artikel .

Erfahren Sie, wie Sie einen Registrierungs- und Anmeldeablauf für ein lokales Konto mithilfe einer benutzerdefinierten Azure Active Directory B2C-Richtlinie einrichten.
Erfahren Sie, wie Sie benutzerdefinierte Attribute in Ihrer benutzerdefinierten Richtlinie definieren.
Weitere Informationen finden Sie unter Hinzufügen eines Kennwortablaufs zu einer benutzerdefinierten Richtlinie.
Erfahren Sie mehr über das technische Profil der Microsoft Entra ID.

Feedback

War diese Seite hilfreich?

Last updated on 2025-05-08