Konfigurera ett registrerings- och inloggningsflöde med ett socialt konto med hjälp av en anpassad princip för Azure Active Directory B2C

Artikel
01/11/2024

I artikeln Konfigurera ett registrerings- och inloggningsflöde med hjälp av den anpassade principartikeln Azure Active Directory B2C konfigurerar vi inloggningsflödet för ett lokalt konto med hjälp av Azure Active Directory B2C (Azure AD B2C).

I den här artikeln lägger vi till ett inloggningsflöde för ett externt konto, till exempel ett socialt konto som Facebook. I det här fallet tillåter Azure AD B2C att en användare loggar in på ditt program med autentiseringsuppgifter från en extern leverantör av sociala identiteter (IdP).

För lokala konton identifieras ett användarkonto unikt med hjälp av användarattributetobjectId. För extern IdP använder alternativeSecurityId vi användarattribut även om det fortfarande finns ett objectId .

Förutsättningar

Om du inte redan har en skapar du en Azure AD B2C-klientorganisation som är länkad till din Azure-prenumeration.
Registrera ett webbprogram och aktivera implicit beviljande av ID-token. För omdirigerings-URI använder du https://jwt.ms.
Visual Studio Code (VS Code) måste vara installerat på datorn.
Slutför stegen i Konfigurera ett registrerings- och inloggningsflöde för lokalt konto med hjälp av en anpassad princip för Azure Active Directory B2C. Den här artikeln är en del av guideserien Skapa och kör egna anpassade principer.

Kommentar

Den här artikeln är en del av guideserien Skapa och köra egna anpassade principer i Azure Active Directory B2C. Vi rekommenderar att du startar den här serien från den första artikeln.

Steg 1 – Skapa Facebook-program

Använd stegen som beskrivs i Skapa ett Facebook-program för att hämta Facebook-app-ID och apphemlighet. Hoppa över förutsättningarna och resten av stegen i artikeln Konfigurera registrering och logga in med ett Facebook-konto .

Steg 2 – Skapa Facebook-principnyckel

Följ stegen som beskrivs i Skapa Facebook-nyckelarkivet en principnyckel i din Azure AD B2C-klientorganisation. Hoppa över förutsättningarna och resten av stegen i artikeln Konfigurera registrering och logga in med ett Facebook-konto .

För att konfigurera inloggning med Facebook måste du utföra följande steg:

Deklarera fler anspråk
Definiera fler anspråkstransformeringar för att hjälpa till med anspråksmanipuleringar som att skapa AlternativeSecurityId.
Konfigurera Facebook-anspråksprovider
Konfigurera tekniska Microsoft Entra-profiler för att läsa och skriva det sociala kontot från och till Microsoft Entra-databasen.
Konfigurera en självsäkrad teknisk profil (för att acceptera ytterligare indata från användaren eller uppdatera användarinformation) och dess innehållsdefinition.

Steg 3.1 – Deklarera fler anspråk

ContosoCustomPolicy.XML Leta upp avsnittet i ClaimsSchema filen och deklarera sedan fler anspråk med hjälp av följande kod:

    <!--<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>-->

Steg 3.2 – Definiera anspråkstransformeringar

Leta upp elementet ContosoCustomPolicy.XML ClaimsTransformations i filen och lägg till anspråkstransformeringar med hjälp av följande kod:

   <!--<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>-->

Vi har definierat tre anspråksomvandlingar som vi använder för att generera värden för alternativeSecurityId och userPrincipalName anspråk. Dessa ClaimsTransformations anropas i den tekniska OAuth2-profilen i steg 3.3.

Steg 3.3 – Konfigurera Facebook-anspråksprovider

För att göra det möjligt för användare att logga in med ett Facebook-konto måste du definiera kontot som en anspråksprovider som Azure AD B2C kan kommunicera med via en slutpunkt. Du kan definiera ett Facebook-konto som en anspråksprovider.

Leta upp ClaimsProviders elementet ContosoCustomPolicy.XML i filen och lägg till en ny anspråksprovider med hjälp av följande kod:

    <!--<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>-->

Ersätta:

facebook-app-id med värdet för Facebook appID som du fick i steg 1.
facebook-policy-key med namnet på den Facebook-principnyckel som du fick i steg 2.

Observera de anspråkstransformeringar som vi definierade i steg 3.2 i OutputClaimsTransformations samlingen.

Steg 3.4 – Skapa tekniska Profiler för Microsoft Entra

Precis som när du loggar in med ett lokalt konto måste du konfigurera Microsoft Entra Technical Profiles, som du använder för att ansluta till Microsoft Entra ID-lagring, för att lagra eller läsa ett användarkonto för sociala användare.

ContosoCustomPolicy.XML Leta upp den AAD-UserUpdate tekniska profilen i filen och lägg sedan till en ny teknisk profil med hjälp av följande kod:

    <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>

Vi har lagt till en ny teknisk Microsoft Entra-profil AAD-UserWriteUsingAlternativeSecurityId som skriver ett nytt socialt konto i Microsoft Entra-ID.

Ersätt B2C_1A_TokenSigningKeyContainer med den tokensigneringsnyckel som du skapade i Konfigurera signeringen.

ContosoCustomPolicy.XML I filen lägger du till ytterligare en teknisk Microsoft Entra-profil efter den AAD-UserWriteUsingAlternativeSecurityId tekniska profilen med hjälp av följande kod:

   <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>

Vi har lagt till en ny teknisk Microsoft Entra-profil AAD-UserReadUsingAlternativeSecurityId som läser ett nytt socialt konto från Microsoft Entra-ID. Den används alternativeSecurityId som en unik identifierare för det sociala kontot.

Ersätt B2C_1A_TokenSigningKeyContainer med den tokensigneringsnyckel som du skapade i Konfigurera signeringen.

Steg 3.5 – Konfigurera innehållsdefinition

När en användare har loggat in kan du samla in viss information från dem med hjälp av en självsäkrad teknisk profil. Därför måste du konfigurera innehållsdefinitionen för den självsäkra tekniska profilen.

Leta upp elementet ContosoCustomPolicy.XML ContentDefinitions i filen och lägg sedan till en ny innehållsdefinition i ContentDefinitions samlingen med hjälp av följande kod:

    <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>

Vi använder den här innehållsdefinitionen som metadata i en självsäkrad teknisk profil i nästa steg (steg 3.6).

Steg 3.6 – Konfigurera en självsäkrad teknisk profil

Den självsäkra tekniska profilen som du konfigurerar i det här steget används för att samla in mer information från användaren eller uppdatera liknande information som hämtas från det sociala kontot.

ContosoCustomPolicy.XML Leta upp avsnittet i ClaimsProviders filen och lägg sedan till en ny anspråksprovider med hjälp av följande kod:

    <!--<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>-->

Anspråksprovidern som vi har lagt till innehåller en självsäkrad teknisk profil, SelfAsserted-Social. Den självsäkra tekniska profilen använder den AAD-UserWriteUsingAlternativeSecurityId tekniska profilen som en teknisk valideringsprofil. Därför körs den AAD-UserWriteUsingAlternativeSecurityId tekniska profilen när användaren väljer knappen Fortsätt (se skärmbild i steg 7).

Observera också att vi har lagt till innehållsdefinitionen, socialAccountsignupContentDefinition, som vi konfigurerade i steg 3.5 i metadataavsnittet.

Steg 4 – Uppdatera orkestreringsstegen för användarens resa

ContosoCustomPolicy.XML Leta upp användarens HelloWorldJourney resa i filen och ersätt alla orkestreringssteg med stegen som visas i följande kod:

    <!--<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>-->

I orkestreringen har vi använt för att referera till tekniska profiler som gör det möjligt för en användare att logga in med hjälp av ett socialt konto.

När den anpassade principen körs:

Orkestrering steg 1 – Det här steget innehåller ett ClaimsProviderSelections element som visar de tillgängliga inloggningsalternativ som en användare kan välja mellan. I det här fallet har vi bara ett alternativ, FacebookExchange, så när principen körs tas användarna direkt till Facebook.com i steg 2 enligt TargetClaimsExchangeId attributet.
Orkestrering steg 2 – Den Facebook-OAUTH tekniska profilen körs, så användaren omdirigeras till Facebook för att logga in.
Orkestrering steg 3 – I steg 3 körs den AAD-UserReadUsingAlternativeSecurityId tekniska profilen för att försöka läsa det sociala användarkontot från Microsoft Entra ID-lagring. Om det sociala kontot hittas objectId returneras som ett utdataanspråk.
Orkestrering steg 4 – Det här steget körs om användaren inte redan finns (objectId finns inte). Det visar formuläret som samlar in mer information från användaren eller uppdaterar liknande information som hämtas från det sociala kontot.
Orkestrering steg 5 – Det här steget körs om användaren inte redan finns (objectId finns inte), så den AAD-UserWriteUsingAlternativeSecurityId tekniska profilen körs för att skriva det sociala kontot till Microsoft Entra-ID.
Orkestrering steg 6 – Slutligen monterar och returnerar steg 6 JWT-token i slutet av principens körning.

Steg 5 – Uppdatera förlitande parts utdataanspråk

Leta upp elementet ContosoCustomPolicy.XML i RelyingParty filen och ersätt sedan alla utdataanspråkssamlingen med följande kod:

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

Vi har lagt till identitetsprovidern (identityProvider) som ett utdataanspråk, så den inkluderas i den JWT-token som returneras till det förlitande partprogrammet.

Steg 6 – Ladda upp princip

Följ stegen i Ladda upp en anpassad principfil för att ladda upp principfilen. Om du laddar upp en fil med samma namn som den som redan finns i portalen kontrollerar du att du väljer Skriv över den anpassade principen om den redan finns.

Steg 7 – Testprincip

Följ stegen i Testa den anpassade principen för att testa din anpassade princip.

Du omdirigeras till en Facebook-inloggningssida. Ange dina Facebook-autentiseringsuppgifter och välj sedan Logga in. Du omdirigeras direkt till Facebook när vi ställer in den så i våra orkestreringssteg eftersom vi inte har flera inloggningsalternativ att välja mellan. I en app lägger du vanligtvis till en knapp som Logga in med Facebook, som när den väljs kör principen.

Om det är första gången den här principen körs (det sociala kontot finns inte redan i Microsoft Entra Storage) visas en skärmbild som den som visas nedan. Den här skärmen visas inte i efterföljande principkörningar eftersom det sociala kontot redan finns i Microsoft Entra Storage.

Ange eller uppdatera Visningsnamn, Förnamn och efternamn och välj sedan knappen Fortsätt .

När principen har slutfört körningen omdirigeras du till https://jwt.msoch du ser en avkodad JWT-token. Det ser ut ungefär som följande JWT-tokenfragment:

{
  "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]

Observera att identitetsprovidern, "idp": "facebook.com", har inkluderats i JWT-token.

I den här artikeln refererar våra orkestreringssteg för användarresor endast till tekniska profiler som gör det möjligt för en användare att logga in med hjälp av ett socialt konto. Vi kan ändra orkestreringsstegen så att en användare kan logga in med hjälp av antingen ett lokalt konto eller ett socialt konto. För att göra det visar det första orkestreringsstegets ClaimsProviderSelections element de inloggningsalternativ som är tillgängliga för användaren.

Använd följande steg för att lägga till ett kombinerat lokalt och socialt konto:

ContosoCustomPolicy.XML Leta upp den AccountTypeInputCollector självsäkra tekniska profilen i filen och lägg sedan till authenticationSource anspråk i dess utdataanspråkssamling med hjälp av följande kod:
```
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />
```

I avsnittet UserJourneys lägger du till en ny användarresa LocalAndSocialSignInAndSignUp med hjälp av följande kod:

    <!--<UserJourneys>-->
        ...
        <UserJourney Id="LocalAndSocialSignInAndSignUp">
            <OrchestrationSteps>
                <!--Orchestration steps will be added here-->
            </OrchestrationSteps>
        </UserJourney>
    <!--</UserJourneys>-->

Under den användarresa som du har skapat LocalAndSocialSignInAndSignUplägger du till orkestreringssteg med hjälp av följande kod:

    <!--<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>-->

I det första steget anger vi vilka alternativ en användare behöver välja mellan under resan, lokal eller social autentisering. I de steg som följer använder vi förhandsvillkor för att spåra det alternativ som användaren valde eller fasen för den resa som användaren befinner sig i. Vi använder till exempel anspråket authenticationSource för att skilja mellan en lokal autentiseringsresa och en social autentiseringsresa.

I avsnittet RelyingParty ändrar du DefaultUserJourneysReferenceId till LocalAndSocialSignInAndSignUp
Använd proceduren i steg 6 och steg 7 för att ladda upp och köra principen. När du har kört principen visas en skärm som liknar följande skärmbild.

Du kan observera att en användare kan registrera sig eller logga in med antingen ett lokalt konto eller ett socialt konto.

Nästa steg

Läs mer om hur du definierar en teknisk OAuth2-profil i en anpassad Azure Active Directory B2C-princip.

Dela via

Förutsättningar

Steg 1 – Skapa Facebook-program

Steg 2 – Skapa Facebook-principnyckel

Steg 3.1 – Deklarera fler anspråk

Steg 3.2 – Definiera anspråkstransformeringar

Steg 3.3 – Konfigurera Facebook-anspråksprovider

Steg 3.4 – Skapa tekniska Profiler för Microsoft Entra

Steg 3.5 – Konfigurera innehållsdefinition

Steg 3.6 – Konfigurera en självsäkrad teknisk profil

Steg 4 – Uppdatera orkestreringsstegen för användarens resa

Steg 5 – Uppdatera förlitande parts utdataanspråk

Steg 6 – Ladda upp princip

Steg 7 – Testprincip

Nästa steg

Feedback

Ytterligare resurser

Dela via

Förutsättningar

Steg 1 – Skapa Facebook-program

Steg 2 – Skapa Facebook-principnyckel

Steg 3 – Konfigurera inloggning med Facebook

Steg 3.1 – Deklarera fler anspråk

Steg 3.2 – Definiera anspråkstransformeringar

Steg 3.3 – Konfigurera Facebook-anspråksprovider

Steg 3.4 – Skapa tekniska Profiler för Microsoft Entra

Steg 3.5 – Konfigurera innehållsdefinition

Steg 3.6 – Konfigurera en självsäkrad teknisk profil

Steg 4 – Uppdatera orkestreringsstegen för användarens resa

Steg 5 – Uppdatera förlitande parts utdataanspråk

Steg 6 – Ladda upp princip

Steg 7 – Testprincip

En kombinerad lokal och social inloggning

Nästa steg

Feedback

Ytterligare resurser