Teilen über


Einrichten eines Registrierungs- und Anmeldeflows mit Social Media-Konto mithilfe einer benutzerdefinierten Azure Active Directory B2C-Richtlinie

Im Artikel Einrichten eines Registrierungs- und Anmeldeflows mithilfe einer benutzerdefinierten Azure Active Directory B2C-Richtlinie haben wir den Anmeldeflow für ein lokales Konto mithilfe von Azure Active Directory B2C (Azure AD B2C) eingerichtet.

In diesem Artikel fügen wir einen Anmeldeflow für ein externes Konto hinzu, z. B. für ein Social Media-Konto wie Facebook. In diesem Fall ermöglicht Azure AD B2C einem Benutzer, sich mit Anmeldeinformationen eines externen Identitätsanbieters (IdP) für Social Media bei Ihrer Anwendung anzumelden.

Bei lokalen Konten wird ein Benutzerkonto mithilfe des objectIdBenutzerattributes eindeutig identifiziert. Für den externen IdP verwenden wir das alternativeSecurityId-Benutzerattribut, obwohl noch ein objectId vorhanden ist.

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 – Erstellen einer Facebook-Anwendung

Führen Sie die Schritte unter Erstellen einer Facebook-Anwendung aus, um eine App-ID und ein App-Geheimnis für Facebook zu erhalten. Überspringen Sie die Voraussetzungen und die übrigen Schritte im Artikel Einrichten der Registrierung und Anmeldung mit einem Facebook-Konto.

Schritt 2 – Erstellen eines Facebook-Richtlinienschlüssels

Führen Sie die unter Erstellen des Facebook-Schlüssels beschriebenen Schritte aus, um einen Richtlinienschlüssel in Ihrem Azure AD B2C-Mandanten zu speichern. Überspringen Sie die Voraussetzungen und die übrigen Schritte im Artikel Einrichten der Registrierung und Anmeldung mit einem Facebook-Konto.

Schritt 3 – Konfigurieren der Anmeldung mit Facebook

Zum Konfigurieren der Anmeldung mit Facebook müssen Sie die folgenden Schritte ausführen:

  • Deklarieren weiterer Ansprüche
  • Definieren Sie weitere Anspruchstransformationen, um Anspruchsbearbeitungen wie das Erstellen von AlternativeSecurityId zu erleichtern.
  • Konfigurieren des Facebook-Anspruchsanbieters
  • Konfigurieren Sie technische Microsoft Entra-Profile, um das Social Media-Konto von der Microsoft Entra-Datenbank zu lesen und in diese zu schreiben.
  • Konfigurieren Sie ein selbstbestätigtes technisches Profil (zum Akzeptieren zusätzlicher Benutzereingaben oder Aktualisieren von Benutzerdetails) und dessen Inhaltsdefinition.

Schritt 3.1 – Deklarieren weiterer Ansprüche

Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem Abschnitt ClaimsSchema und deklarieren Sie dann mithilfe des folgenden Codes weitere Ansprüche:

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="issuerUserId">
            <DisplayName>Username</DisplayName>
            <DataType>string</DataType>
            <UserHelpText/>
            <UserInputType>TextBox</UserInputType>
            <Restriction>
                <Pattern RegularExpression="^[a-zA-Z0-9]+[a-zA-Z0-9_-]*$" HelpText="The username you provided is not valid. It must begin with an alphabet or number and can contain alphabets, numbers and the following symbols: _ -" />
            </Restriction>
        </ClaimType>
        
        <ClaimType Id="identityProvider">
            <DisplayName>Identity Provider</DisplayName>
            <DataType>string</DataType>
            <UserHelpText/>
        </ClaimType>
        
        <ClaimType Id="authenticationSource">
            <DisplayName>AuthenticationSource</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Specifies whether the user was authenticated at Social IDP or local account.</UserHelpText>
        </ClaimType>  
        
        <ClaimType Id="upnUserName">
            <DisplayName>UPN User Name</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>The user name for creating user principal name.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="alternativeSecurityId">
            <DisplayName>AlternativeSecurityId</DisplayName>
            <DataType>string</DataType>
            <UserHelpText/>
        </ClaimType>
        
        <ClaimType Id="mailNickName">
            <DisplayName>MailNickName</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Your mail nick name as stored in the Azure Active Directory.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="newUser">
            <DisplayName>User is new or not</DisplayName>
            <DataType>boolean</DataType>
            <UserHelpText/>
        </ClaimType>
    <!--</ClaimsSchema>-->

Schritt 3.2 – Definieren von Anspruchstransformationen

Suchen Sie in der ContosoCustomPolicy.XML-Datei das Element ClaimsTransformations und fügen Sie mithilfe des folgenden Codes Anspruchstransformationen hinzu:

   <!--<ClaimsTransformations>-->
       ...
       <ClaimsTransformation Id="CreateRandomUPNUserName" TransformationMethod="CreateRandomString">
           <InputParameters>
               <InputParameter Id="randomGeneratorType" DataType="string" Value="GUID" />
           </InputParameters>
           <OutputClaims>
               <OutputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="outputClaim" />
           </OutputClaims>
       </ClaimsTransformation>
   
       <ClaimsTransformation Id="CreateAlternativeSecurityId" TransformationMethod="CreateAlternativeSecurityId">
           <InputClaims>
               <InputClaim ClaimTypeReferenceId="issuerUserId" TransformationClaimType="key" />
               <InputClaim ClaimTypeReferenceId="identityProvider" TransformationClaimType="identityProvider" />
           </InputClaims>
           <OutputClaims>
               <OutputClaim ClaimTypeReferenceId="alternativeSecurityId" TransformationClaimType="alternativeSecurityId" />
           </OutputClaims>
       </ClaimsTransformation>
       
       <ClaimsTransformation Id="CreateUserPrincipalName" TransformationMethod="FormatStringClaim">
           <InputClaims>
               <InputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="inputClaim" />
           </InputClaims>
           <InputParameters>
               <InputParameter Id="stringFormat" DataType="string" Value="cpim_{0}@{RelyingPartyTenantId}" />
           </InputParameters>
           <OutputClaims>
               <OutputClaim ClaimTypeReferenceId="userPrincipalName" TransformationClaimType="outputClaim" />
           </OutputClaims>
       </ClaimsTransformation>
   <!--</ClaimsTransformations>-->

Wir haben drei Anspruchstransformationen definiert, mit denen wir Werte für alternativeSecurityId- und userPrincipalName-Ansprüche generieren. Diese Anspruchstransformationen werden im technischen OAuth2-Profil in Schritt 3.3 aufgerufen.

Schritt 3.3 – Konfigurieren des Facebook-Anspruchsanbieters

Damit sich Benutzer mit einem Facebook-Konto anmelden können, müssen Sie das Konto als Anspruchsanbieter definieren, mit dem Azure AD B2C über einen Endpunkt kommunizieren kann. Sie können ein Facebook-Konto als Anspruchsanbieter definieren.

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

    <!--<ClaimsProviders>-->
        ...
        <ClaimsProvider>
            <!-- The following Domain element allows this profile to be used if the request comes with domain_hint 
                    query string parameter, e.g. domain_hint=facebook.com  -->
            <Domain>facebook.com</Domain>
            <DisplayName>Facebook</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="Facebook-OAUTH">
                <!-- The text in the following DisplayName element is shown to the user on the claims provider 
                        selection screen. -->
                <DisplayName>Facebook</DisplayName>
                <Protocol Name="OAuth2" />
                <Metadata>
                    <Item Key="ProviderName">facebook</Item>
                    <Item Key="authorization_endpoint">https://www.facebook.com/dialog/oauth</Item>
                    <Item Key="AccessTokenEndpoint">https://graph.facebook.com/oauth/access_token</Item>
                    <Item Key="HttpBinding">GET</Item>
                    <Item Key="UsePolicyInRedirectUri">0</Item>                
                    <Item Key="client_id">facebook-app-id</Item>
                    <Item Key="scope">email public_profile</Item>
                    <Item Key="ClaimsEndpoint">https://graph.facebook.com/me?fields=id,first_name,last_name,name,email</Item>
                    <Item Key="AccessTokenResponseFormat">json</Item>
                </Metadata>
                <CryptographicKeys>
                    <Key Id="client_secret" StorageReferenceId="facebook-policy-key" />
                </CryptographicKeys>
                <InputClaims />
                <OutputClaims>
                    <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="id" />
                    <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
                    <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
                    <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
                    <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
                    <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="facebook.com" AlwaysUseDefaultValue="true" />
                    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
                </OutputClaims>
                <OutputClaimsTransformations>
                    <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
                    <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
                    <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
                </OutputClaimsTransformations>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Ersetzen Sie:

  • facebook-app-id mit dem Wert der Facebook appID, den Sie in Schritt 1 erhalten haben.
  • facebook-policy-key mit dem Namen des Facebook-Richtlinienschlüssels, den Sie in Schritt 2 erhalten haben.

Beachten Sie die Forderungstransformationen, die wir in Schritt 3.2 in der OutputClaimsTransformations-Sammlung definiert haben.

Schritt 3.4: Erstellen von technischen Microsoft Entra-Profilen

Genau wie bei der Anmeldung mit einem lokalen Konto müssen Sie die Technischen Microsoft Entra-Profile konfigurieren, die Sie zum Herstellen einer Verbindung mit Microsoft Entra ID-Speicher verwenden, um ein Social Media-Konto zu speichern oder zu lesen.

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

        <TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
            <DisplayName>Azure Active Directory technical profile for handling social accounts</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>
            </Metadata>        
    
            <CryptographicKeys>
                <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
            </CryptographicKeys>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" />
            </InputClaims>
            <PersistedClaims>
                <!-- Required claims -->
                <PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />
                <PersistedClaim ClaimTypeReferenceId="userPrincipalName" />
                <PersistedClaim ClaimTypeReferenceId="mailNickName" DefaultValue="unknown" />
                <PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />
    
                <!-- Optional claims -->
                <PersistedClaim ClaimTypeReferenceId="givenName" />
                <PersistedClaim ClaimTypeReferenceId="surname" />
            </PersistedClaims>
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="objectId" />
                <OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
            </OutputClaims>
    
        </TechnicalProfile>
    

    We've added a new Microsoft Entra Technical Profile AAD-UserWriteUsingAlternativeSecurityId that writes a new social account into Microsoft Entra ID.

  2. Ersetzen Sie B2C_1A_TokenSigningKeyContainer durch den Tokensignierschlüssel, den Sie unter Signierung konfigurieren erstellt haben.

  3. Fügen Sie in der ContosoCustomPolicy.XML-Datei ein weiteres technisches Azure AD-Profil nach dem technischen Profil AAD-UserWriteUsingAlternativeSecurityId hinzu, indem Sie den folgenden Code verwenden:

       <TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId">
           <DisplayName>Azure Active Directory</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="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
           </Metadata>
           <CryptographicKeys>
               <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
               </CryptographicKeys>
           <InputClaims>
               <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" />
           </InputClaims>
           <OutputClaims>
               <!-- Required claims -->
               <OutputClaim ClaimTypeReferenceId="objectId" />
    
               <!-- Optional claims -->
               <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
               <OutputClaim ClaimTypeReferenceId="displayName" />
               <OutputClaim ClaimTypeReferenceId="givenName" />
               <OutputClaim ClaimTypeReferenceId="surname" />
           </OutputClaims>
       </TechnicalProfile>
    

    We've added a new Microsoft Entra Technical Profile AAD-UserReadUsingAlternativeSecurityId that reads a new social account from Microsoft Entra ID. Es verwendet alternativeSecurityId als eindeutigen Bezeichner für das Social Media-Konto.

  4. Ersetzen Sie B2C_1A_TokenSigningKeyContainer durch den Tokensignierschlüssel, den Sie unter Signierung konfigurieren erstellt haben.

Schritt 3.5 – Konfigurieren der Inhaltsdefinition

Nachdem sich ein Benutzer angemeldet hat, können Sie mithilfe eines selbstbestätigten technischen Profils einige Informationen von diesem Benutzer sammeln. Dazu müssen Sie die Inhaltsdefinition für das selbstbestätigte technische Profil konfigurieren.

Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem Element ContentDefinitions und fügen Sie dann eine neue Inhaltsdefinition in der ContentDefinitions-Sammlung hinzu, indem Sie den folgenden Code verwenden:

    <ContentDefinition Id="socialAccountsignupContentDefinition">
        <LoadUri>~/tenant/templates/AzureBlue/selfAsserted.cshtml</LoadUri>
        <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
        <DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.7</DataUri>
        <Metadata>
            <Item Key="DisplayName">Collect information from user page alongside those from social Idp.</Item>
        </Metadata>
    </ContentDefinition>

Wir verwenden diese Inhaltsdefinition als Metadaten in einem selbstbestätigten technischen Profil im nächsten Schritt (Schritt 3.6).

Schritt 3.6 – Konfigurieren eines selbstbestätigten technischen Profils

Das selbstbestätigte technische Profil, das Sie in diesem Schritt konfigurieren, wird verwendet, um weitere Informationen vom Benutzer zu sammeln oder ähnliche aus dem Social Media-Konto erhaltene Informationen zu aktualisieren.

Suchen Sie in der ContosoCustomPolicy.XML-Datei den Abschnitt ClaimsProviders und fügen Sie dann mithilfe des folgenden Codes einen neuen Anspruchsanbieter hinzu:

    <!--<ClaimsProviders>-->
        ...
        <ClaimsProvider>
            <DisplayName>Self Asserted for social sign in</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="SelfAsserted-Social">
                    <DisplayName>Collect more info during social signup</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
                    <Metadata>
                      <Item Key="ContentDefinitionReferenceId">socialAccountsignupContentDefinition</Item>
                    </Metadata>
                    <CryptographicKeys>
                      <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
                    </CryptographicKeys>
                    <InputClaims>
                      <!-- These claims ensure that any values retrieved in the previous steps (e.g. from an external IDP) are prefilled. 
                           Note that some of these claims may not have any value, for example, if the external IDP did not provide any of
                           these values, or if the claim did not appear in the OutputClaims section of the IDP.
                           In addition, if a claim is not in the InputClaims section, but it is in the OutputClaims section, then its
                           value will not be prefilled, but the user will still be prompted for it (with an empty value). -->
                      <InputClaim ClaimTypeReferenceId="displayName" />
                      <InputClaim ClaimTypeReferenceId="givenName" />
                      <InputClaim ClaimTypeReferenceId="surname" />
                    </InputClaims>
                    <!---User will be asked to input or update these values-->
                    <DisplayClaims>
                        <DisplayClaim ClaimTypeReferenceId="displayName"/>
                        <DisplayClaim ClaimTypeReferenceId="givenName"/>
                        <DisplayClaim ClaimTypeReferenceId="surname"/>
                    </DisplayClaims>

                    <OutputClaims>
                      <!-- These claims are not shown to the user because their value is obtained through the "ValidationTechnicalProfiles"
                           referenced below, or a default value is assigned to the claim. A claim is only shown to the user to provide a 
                           value if its value cannot be obtained through any other means. -->
                      <OutputClaim ClaimTypeReferenceId="objectId" />
                      <OutputClaim ClaimTypeReferenceId="newUser" />
                      <!---<OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />-->
          
                      <!-- Optional claims. These claims are collected from the user and can be modified. If a claim is to be persisted in the directory after having been 
                           collected from the user, it needs to be added as a PersistedClaim in the ValidationTechnicalProfile referenced below, i.e. 
                           in AAD-UserWriteUsingAlternativeSecurityId. -->
                      <OutputClaim ClaimTypeReferenceId="displayName" />
                      <OutputClaim ClaimTypeReferenceId="givenName" />
                      <OutputClaim ClaimTypeReferenceId="surname" />
                    </OutputClaims>
                    <ValidationTechnicalProfiles>
                      <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
                    </ValidationTechnicalProfiles>
                  </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Der hinzugefügte Anspruchsanbieter enthält das selbstbestätigte technische Profil SelfAsserted-Social. Das selbstbestätigte technische Profil verwendet das Technische Profil AAD-UserWriteUsingAlternativeSecurityId als Technisches Validierungsprofil. Daher wird das Technisches Profil AAD-UserWriteUsingAlternativeSecurityId ausgeführt, wenn der Benutzer die Schaltfläche Weiter auswählt (siehe Screenshot in Schritt 7).

Beachten Sie außerdem, dass wir die Inhaltsdefinition hinzugefügt socialAccountsignupContentDefinition haben, die wir in Schritt 3.5 im Metadatenabschnitt konfiguriert haben.

Schritt 4 – Aktualisieren der Schritte zur Orchestrierung der User Journey

Suchen Sie in der ContosoCustomPolicy.XML-Datei nach der HelloWorldJourney-User Journey, und ersetzen Sie alle Orchestrierungsschritte durch die im folgenden Code gezeigten Schritte:

    <!--<OrchestrationSteps>-->
        ...
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp">
            <ClaimsProviderSelections>
                <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
            </ClaimsProviderSelections>
        </OrchestrationStep>
    
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="FacebookExchange"
                    TechnicalProfileReferenceId="Facebook-OAUTH" />
            </ClaimsExchanges>
        </OrchestrationStep>
    
        <!-- For social IDP authentication, attempt to find the user account in the
        directory. -->
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" />
            </ClaimsExchanges>
        </OrchestrationStep>
    
        <!-- Show self-asserted page only if the directory does not have the user account
        already (i.e. we don't have an objectId).  -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
            </ClaimsExchanges>
        </OrchestrationStep>
    
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    <!--</OrchestrationSteps>-->

In der Orchestrierung haben wir auf technische Profile verwiesen, die es einem Benutzer ermöglichen, sich mit einem Social Media-Konto anzumelden.

Wenn die benutzerdefinierte Richtlinie ausgeführt wird:

  • Orchestrierungsschritt 1: Dieser Schritt enthält ein Element ClaimsProviderSelections, das die verfügbaren Anmeldeoptionen auflistet, aus denen ein Benutzer auswählen kann. In diesem Fall haben wir nur eine Option, nämlich FacebookExchange. Wenn also die Richtlinie ausgeführt wird, werden die Benutzer in Schritt 2 direkt zu Facebook.com weitergeleitet, wie durch das TargetClaimsExchangeId-Attribut dargestellt.

  • Orchestrierungsschritt 2: Das technische Profil Facebook-OAUTH wird ausgeführt, sodass der Benutzer zur Anmeldung zu Facebook weitergeleitet wird.

  • Orchestrierungsschritt 3: In Schritt 3 wird das technische Profil AAD-UserReadUsingAlternativeSecurityId ausgeführt, um zu versuchen, das Social Media-Konto des Benutzers aus dem Microsoft Entra ID-Speicher zu lesen. Wenn das Social Media-Konto gefunden wird, wird objectId als Ausgabeanspruch zurückgegeben.

  • Orchestrierungsschritt 4 – Dieser Schritt wird ausgeführt, wenn der Benutzer noch nicht vorhanden ist (objectId ist nicht vorhanden). Es zeigt das Formular an, das weitere Informationen vom Benutzer sammelt oder ähnliche Informationen aktualisiert, die aus dem Social-Media-Konto abgerufen wurden.

  • Orchestrierungsschritt 5 – Dieser Schritt wird ausgeführt, wenn der Benutzer noch nicht vorhanden ist (objectId ist nicht vorhanden), sodass das technische Profil AAD-UserWriteUsingAlternativeSecurityId ausgeführt wird, um das Social Media-Konto in Azure AD zu schreiben.

  • Orchestrierungsschritt 6 – Schließlich wird in Schritt 6 das JWT-Token am Ende der Ausführung der Richtlinie zusammengesetzt und zurückgegeben.

Schritt 5 – Aktualisieren von Ausgabeansprüchen der vertrauenden Seite

Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem Element RelyingParty und ersetzen Sie dann alle Ausgabeanspruchsauflistungen durch den folgenden Code:

    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surname" />
    <OutputClaim ClaimTypeReferenceId="email" />
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
    <OutputClaim ClaimTypeReferenceId="identityProvider" />

Wir haben den Identitätsanbieter (identityProvider) als Ausgabeanspruch hinzugefügt, sodass er in das JWT-Token aufgenommen wird, das an die Anwendung der vertrauenden Seite zurückgegeben wird.

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.

Sie werden zu einer Facebook-Anmeldeseite weitergeleitet. Geben Sie Ihre Facebook-Anmeldeinformationen ein, und wählen Sie dann Anmelden aus. Sie werden direkt zu Facebook weitergeleitet, da wir es in unseren Orchestrierungsschritten so festgelegt haben, da wir nicht mehrere Anmeldeoptionen zur Auswahl haben. In der Regel fügen Sie in einer App eine Schaltfläche wie Mit Facebook anmelden hinzu, die – wenn ausgewählt – die Richtlinie ausführt.

Wenn diese Richtlinie zum ersten Mal ausgeführt wird (ein Social Media-Konto ist noch nicht im Microsoft Entra-Speicher vorhanden), sehen Sie einen Screenshot wie den unten abgebildeten. Dieser Bildschirm wird bei nachfolgenden Richtlinienausführungen nicht mehr angezeigt, da das Social Media-Konto bereits im Microsoft Entra-Speicher vorhanden ist.

Screenshot of sign-in flow with social account.

Geben Sie Anzeigename, Vorname und Nachname ein, oder aktualisieren Sie diese, und wählen Sie dann die Schaltfläche Weiter aus.

Nachdem die Ausführung der Richtlinie abgeschlossen ist, werden Sie zu https://jwt.ms weitergeleitet, und es wird ein decodiertes JWT-Token angezeigt. Es sieht ähnlich aus wie der folgende JWT-Tokenschnipsel:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "pxLOMWFgP4T..."
}.{
   ...
  "acr": "b2c_1a_contosocustompolicy",
   ...
  "given_name": "Maurice",
  "family_name": "Paulet",
  "name": "Maurice Paulet",
  "email": "maurice.p@contoso.com",
  "idp": "facebook.com"
}.[Signature]

Beachten Sie, dass der Identitätsanbieter "idp": "facebook.com" in das JWT-Token eingeschlossen wurde.

Eine kombinierte lokale und Social Media-Anmeldung

In diesem Artikel beziehen sich unsere Schritte zur User Journey-Orchestrierung nur auf technische Profile, die es einem Benutzer ermöglichen, sich mit einem Social Media-Konto anzumelden. Wir können die Orchestrierungsschritte ändern, um es einem Benutzer zu ermöglichen, sich entweder mit einem lokalen Konto oder einem Social Media-Konto anzumelden. Dazu listet das ClaimsProviderSelections-Element des ersten Orchestrierungsschritts die Anmeldeoptionen auf, die dem Benutzer zur Verfügung stehen.

Führen Sie die folgenden Schritte aus, um ein kombiniertes lokales und Social Media-Konto hinzuzufügen:

  1. Suchen Sie in der ContosoCustomPolicy.XML-Datei nach dem selbstbestätigten technischen Profil AccountTypeInputCollector, und fügen Sie dann den authenticationSource-Anspruch der Ausgabeanspruchsauflistung hinzu, indem Sie den folgenden Code verwenden:

        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />
    
  2. Fügen Sie im UserJourneys-Abschnitt mithilfe des folgenden Codes die neue Benutzerreise LocalAndSocialSignInAndSignUp hinzu:

        <!--<UserJourneys>-->
            ...
            <UserJourney Id="LocalAndSocialSignInAndSignUp">
                <OrchestrationSteps>
                    <!--Orchestration steps will be added here-->
                </OrchestrationSteps>
            </UserJourney>
        <!--</UserJourneys>-->
    
  3. Fügen Sie in der von Ihnen erstellten Benutzerreise LocalAndSocialSignInAndSignUp mithilfe des folgenden Codes Orchestrierungsschritte hinzu:

        <!--<UserJourneys>
            ...
            <UserJourney Id="LocalAndSocialSignInAndSignUp">
                <OrchestrationSteps>-->
                <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition">
                    <ClaimsProviderSelections>
                      <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
                      <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
                    </ClaimsProviderSelections>
                    <ClaimsExchanges>
                      <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" />
                    </ClaimsExchanges>
                </OrchestrationStep>
                <!-- Check if the user has selected to sign in using one of the social providers -->
                <OrchestrationStep Order="2" Type="ClaimsExchange">
                    <Preconditions>
                        <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                            <Value>objectId</Value>
                            <Action>SkipThisOrchestrationStep</Action>
                        </Precondition>
                    </Preconditions>
                    <ClaimsExchanges>
                        <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
                        <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
                    </ClaimsExchanges>
                </OrchestrationStep>
    
                <!--For Local sign in option start-->
    
                <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>work</Value>
                          <Action>SkipThisOrchestrationStep</Action>
                        </Precondition>
                        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                            <Value>authenticationSource</Value>
                            <Value>socialIdpAuthentication</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>
                        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                            <Value>authenticationSource</Value>
                            <Value>socialIdpAuthentication</Value>
                            <Action>SkipThisOrchestrationStep</Action>
                        </Precondition>
                    </Preconditions>
                    <ClaimsExchanges>
                        <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" />
                    </ClaimsExchanges>
                </OrchestrationStep>  
    
                <OrchestrationStep Order="5" Type="ClaimsExchange">
                    <Preconditions>
                        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                            <Value>authenticationSource</Value>
                            <Value>socialIdpAuthentication</Value>
                            <Action>SkipThisOrchestrationStep</Action>
                        </Precondition>
                    </Preconditions>
                    <ClaimsExchanges>
                        <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
                    </ClaimsExchanges>
                </OrchestrationStep>                
                <!--For Local sign in option end-->
    
                <!--For social sign in option start-->
                <!-- For social IDP authentication, attempt to find the user account in the
                directory. -->
                <OrchestrationStep Order="6" Type="ClaimsExchange">
                   <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>localIdpAuthentication</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                   </Preconditions>
                    <ClaimsExchanges>
                        <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" />
                    </ClaimsExchanges>
                </OrchestrationStep>
    
                <!-- Show self-asserted page only if the directory does not have the user account
                already (i.e. we do not have an objectId).  -->
                <OrchestrationStep Order="7" Type="ClaimsExchange">
                    <Preconditions>
                        <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                            <Value>objectId</Value>
                            <Action>SkipThisOrchestrationStep</Action>
                        </Precondition>
                        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                            <Value>authenticationSource</Value>
                            <Value>localIdpAuthentication</Value>
                            <Action>SkipThisOrchestrationStep</Action>
                        </Precondition>
                    </Preconditions>
                    <ClaimsExchanges>
                        <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
                    </ClaimsExchanges>
                </OrchestrationStep>
    
                <OrchestrationStep Order="8" Type="ClaimsExchange">
                    <Preconditions>
                        <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                            <Value>objectId</Value>
                            <Action>SkipThisOrchestrationStep</Action>
                        </Precondition>
                        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                            <Value>authenticationSource</Value>
                            <Value>localIdpAuthentication</Value>
                            <Action>SkipThisOrchestrationStep</Action>
                        </Precondition>
                    </Preconditions>
                    <ClaimsExchanges>
                        <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
                    </ClaimsExchanges>
                </OrchestrationStep>
                <!--For social sign in option end-->
                <OrchestrationStep Order="9" Type="ClaimsExchange">
                    <ClaimsExchanges>
                    <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
                    </ClaimsExchanges>          
                </OrchestrationStep>
    
                <OrchestrationStep Order="10" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
               <!-- </OrchestrationSteps>
            </UserJourney>
        </UserJourneys>-->
    

    Im ersten Schritt geben wir die Optionen an, die Benutzerinnen in ihrer Journey, der lokalen Authentifizierung oder der Authentifizierung über soziale Profile, auswählen müssen. In den folgenden Schritten verwenden wir Vorbedingungen, um die vom Benutzer ausgewählte Option nachzuverfolgen, oder die Phase der Journey, in der sich der Benutzer befindet. Beispielsweise verwenden wir den authenticationSource-Anspruch, um zwischen einer Journey mit lokaler Authentifizierung und einer Journey mit Authentifizierung über soziale Profile zu unterscheiden.

  4. Ändern Sie im RelyingParty -Abschnitt den Wert der DefaultUserJourney‘sReferenceId in LocalAndSocialSignInAndSignUp

  5. Verwenden Sie das Verfahren in Schritt 6 und Schritt 7, um Ihre Richtlinie hochzuladen und auszuführen. Nachdem Sie die Richtlinie ausgeführt haben, wird ein Bildschirm ähnlich dem folgenden Screenshot angezeigt.

    A screenshot of combined local and social sign-up or sign-in interface.

    Sie können beobachten, dass sich ein Benutzer entweder mit einem lokalen Konto oder einem Social Media-Konto registrieren oder anmelden kann.

Nächste Schritte