Dela via


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

I artikeln Skapa och läsa ett användarkonto med hjälp av anpassad princip i Azure Active Directory B2C skapar en användare ett nytt användarkonto men loggar inte in på det.

I den här artikeln får du lära dig hur du skriver en anpassad princip för Azure Active Directory B2C (Azure AD B2C) som gör att en användare antingen kan skapa ett lokalt Azure AD B2C-konto eller logga in på ett. Ett lokalt konto refererar till ett konto som skapas i din Azure AD B2C-klient när en användare registrerar sig i ditt program.

Översikt

Azure AD B2C använder OpenID Anslut autentiseringsprotokoll för att verifiera användarautentiseringsuppgifter. I Azure AD B2C skickar du användarautentiseringsuppgifterna tillsammans med annan information till en säker slutpunkt, som sedan avgör om autentiseringsuppgifterna är giltiga eller inte. När du använder Azure AD B2C:s implementering av OpenID Anslut kan du i ett nötskal lägga ut registrerings-, inloggnings- och andra identitetshanteringsupplevelser i dina webbprogram till Microsoft Entra-ID.

Azure AD B2C-anpassad princip tillhandahåller en OpenID-Anslut teknisk profil som du använder för att göra ett anrop till en säker Microsoft-slutpunkt. Läs mer om OpenID Anslut teknisk profil.

Förutsättningar

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 – Konfigurera OpenID Anslut teknisk profil

För att konfigurera en OpenID-Anslut teknisk profil måste du utföra tre steg:

  • Deklarera fler anspråk.
  • Registrera appar i Azure-portalen.
  • Konfigurera slutligen själva OpenID-Anslut tekniska profilen

Steg 1.1 – Deklarera fler anspråk

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

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="grant_type">
            <DisplayName>grant_type</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="scope">
            <DisplayName>scope</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="nca">
            <DisplayName>nca</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="client_id">
            <DisplayName>client_id</DisplayName>
            <DataType>string</DataType>
            <AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
            <UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="resource_id">
            <DisplayName>resource_id</DisplayName>
            <DataType>string</DataType>
            <AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
            <UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
        </ClaimType>
    <!--</ClaimsSchema>-->

Steg 1.2 – Registrera Identity Experience Framework-program

Azure AD B2C kräver att du registrerar två program som används för att registrera och logga in användare med lokala konton: IdentityExperienceFramework, ett webb-API och ProxyIdentityExperienceFramework, en intern app med delegerad behörighet till IdentityExperienceFramework-appen.

Om du inte redan har gjort det registrerar du följande program. Om du vill automatisera genomgången nedan går du till IEF-installationsappen och följer anvisningarna:

  1. Använd stegen i Registrera IdentityExperienceFramework-programmet för att registrera Identity Experience Framework-programmet. Kopiera program-ID:t (klient), appID, för Identity Experience Framework-programregistreringen för användning i nästa steg.

  2. Använd stegen i Registrera ProxyIdentityExperienceFramework-programmet för att registrera programmet Proxy Identity Experience Framework. Kopiera program-ID:t (klient), proxyAppID, för programregistreringen för Proxy Identity Experience Framework för användning i nästa steg.

Steg 1.3 – Konfigurera OpenID Anslut teknisk profil

ContosoCustomPolicy.XML Leta upp avsnittet ClaimsProviders i filen och lägg sedan till ett Element för anspråksprovider som innehåller din OpenID-Anslut tekniska profil med hjälp av följande kod:

    <!--<ClaimsProviders>-->
        ...
        <ClaimsProvider>
            <DisplayName>OpenID Connect Technical Profiles</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="SignInUser">
                    <DisplayName>Sign in with Local Account</DisplayName>
                    <Protocol Name="OpenIdConnect" />
                    <Metadata>
                        <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We didn't find this account</Item>
                        <Item Key="UserMessageIfInvalidPassword">Your password or username is incorrect</Item>
                        <Item Key="UserMessageIfOldPasswordUsed">You've used an old password.</Item>
                        <Item Key="ProviderName">https://sts.windows.net/</Item>
                        <Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
                        <Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
                        <Item Key="response_types">id_token</Item>
                        <Item Key="response_mode">query</Item>
                        <Item Key="scope">email openid</Item>
                        <!-- Policy Engine Clients -->
                        <Item Key="UsePolicyInRedirectUri">false</Item>
                        <Item Key="HttpBinding">POST</Item>
                        <Item Key="client_id">proxyAppID</Item>
                        <Item Key="IdTokenAudience">appID</Item>
                    </Metadata>
                    <InputClaims>
                        <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="username" Required="true" />
                        <InputClaim ClaimTypeReferenceId="password" PartnerClaimType="password" Required="true" />
                        <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
                        <InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
                        <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
                        <InputClaim ClaimTypeReferenceId="client_id" DefaultValue="proxyAppID" />
                        <InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="appID" />
                    </InputClaims>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
                    </OutputClaims>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Ersätt båda instanserna av:

  • appID med program-ID (klient) för det Identity Experience Framework-program som du kopierade i steg 1.2.

  • proxyAppID med program-ID (klient) för det Proxy Identity Experience Framework-program som du kopierade i steg 1.2.

Steg 2 – Konfigurera inloggningsanvändargränssnittet

När principen körs måste användaren se ett användargränssnitt som gör att de kan logga in. Användargränssnittet har också ett alternativ för att registrera sig om de inte redan har ett konto. För att göra det måste du utföra två steg:

  • Konfigurera en självsäkrad teknisk profil som visar inloggningsformuläret för användaren.
  • Konfigurera innehållsdefinition för inloggningsanvändargränssnittet.

Steg 2.1 – Konfigurera en teknisk profil för inloggningsanvändargränssnitt

ContosoCustomPolicy.XML Leta upp den SignInUser tekniska profilen i filen och lägg till en SelfAsserted Technical Profile efter den med hjälp av följande kod:

    <TechnicalProfile Id="UserSignInCollector">
        <DisplayName>Local Account Signin</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="setting.operatingMode">Email</Item>
            <Item Key="SignUpTarget">AccountTypeInputCollectorClaimsExchange</Item>
        </Metadata>
        <DisplayClaims>
            <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
            <DisplayClaim ClaimTypeReferenceId="password" Required="true" />
        </DisplayClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="password"  />
            <OutputClaim ClaimTypeReferenceId="objectId" />
        </OutputClaims>
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="SignInUser" />
        </ValidationTechnicalProfiles>
    </TechnicalProfile>

Vi har lagt till en SelfAsserted Technical Profile, UserSignInCollector, som visar inloggningsformuläret för användaren. Vi har konfigurerat den tekniska profilen för att samla in användarens e-postadress som deras inloggningsnamn enligt metadata.setting.operatingMode Inloggningsformuläret innehåller en registreringslänk som leder användaren till ett registreringsformulär enligt metadata.SignUpTarget Du ser hur vi konfigurerar SignUpWithLogonEmailExchangeClaimsExchange i orkestreringsstegen.

Dessutom har vi lagt till SignInUser OpenID Anslut teknisk profil som en ValidationTechnicalProfile. Därför körs den tekniska SignInUser-profilen när användaren väljer knappen Logga in (se skärmbild i steg 5).

I nästa steg (steg 2.2) konfigurerar vi en innehållsdefinition som vi ska använda i den här tekniska profilen för SelfAsserted.

Steg 2.2 – Konfigurera innehållsdefinition för inloggningsgränssnitt

ContosoCustomPolicy.XML Leta upp avsnittet ContentDefinitions i filen och logga sedan in innehållsdefinition med hjälp av följande kod:

    <!--<ContentDefinitions>-->
        ...
            <ContentDefinition Id="SignupOrSigninContentDefinition">
                <LoadUri>~/tenant/templates/AzureBlue/unified.cshtml</LoadUri>
                <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
                <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:2.1.7</DataUri>
                <Metadata>
                    <Item Key="DisplayName">Signin and Signup</Item>
                </Metadata>
            </ContentDefinition>
    <!--</ContentDefinitions>-->

Vi har konfigurerat en innehållsdefinition för vår självsäkra tekniska profil, SignupOrSigninContentDefinition. Vi kan ange det i den tekniska profilen med hjälp av metadataelementet eller ange det när vi refererar till den tekniska profilen i orkestreringsstegen. Tidigare lärde vi oss att ange en innehållsdefinition direkt i den självsäkra tekniska profilen, så i den här artikeln får vi lära oss hur du anger den när vi refererar till den tekniska profilen i orkestreringsstegen, steg 3.

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

ContosoCustomPolicy.XML Leta upp HelloWorldJourney-användarresan i filen och ersätt alla dess orkestreringsstegsamling med följande kod:

    <!--<OrchestrationSteps>-->
        ...
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition">
            <ClaimsProviderSelections>
                <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
            </ClaimsProviderSelections>
            <ClaimsExchanges>
                <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" />
            </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
                <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                  <Value>accountType</Value>
                  <Value>company</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
        </OrchestrationStep>
        
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" />
            </ClaimsExchanges>
        </OrchestrationStep>  
      
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>                
        
        <OrchestrationStep Order="6" Type="ClaimsExchange">
            <ClaimsExchanges>
            <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>          
        </OrchestrationStep>                
        
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    <!--</OrchestrationSteps>-->

I orkestreringssteg två till fem har vi använt förhandsvillkor för att avgöra om Orchestration Step ska köras. Vi måste avgöra om användaren loggar in eller registrerar sig.

När den anpassade principen körs:

  • Orkestrering steg 1 – Visar inloggningssidan, så att användaren kan logga in eller välja länken Registrera dig nu . Observera att vi anger den innehållsdefinition som den självsäkra tekniska profilen UserSignInCollector använder för att visa inloggningsformuläret.

  • Orkestrering steg 2 – Det här steget körs om användaren registrerar sig (objectId finns inte), så vi visar formuläret för val av kontotyp genom att anropa den självsäkra tekniska profilen AccountTypeInputCollector .

  • Orkestrering steg 3 – Det här steget körs om användaren registrerar sig (objectId inte finns) och att en användare inte väljer ett företag accountType. Därför måste vi be användaren att ange en accessCode genom att anropa den självsäkra tekniska profilen AccessCodeInputCollector .

  • Orkestrering steg 4 – Det här steget körs om användaren registrerar sig (objectId finns inte), så vi visar registreringsformuläret genom att anropa den självsäkra tekniska profilen UserInformationCollector .

  • Orkestrering steg 5 – Det här steget läser kontoinformation från Microsoft Entra-ID (vi anropar AAD-UserRead teknisk profil för Microsoft Entra-ID), så det körs oavsett om en användare registrerar sig eller loggar in.

  • Orkestrering steg 6 – Det här steget anropar den tekniska profilen UserInputMessageClaimGenerator för att sammanställa användarens hälsningsmeddelande.

  • Orkestrering steg 7 – Slutligen monterar och returnerar steg 8 JWT-token i slutet av principens körning.

Steg 4 – 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 5 – Testprincip

Följ stegen i Testa den anpassade principen för att testa din anpassade princip. När principen körs visas ett gränssnitt som liknar skärmbilden nedan:

screenshot of sign-up or sign-in interface.

Du kan logga in genom att ange e-postadress och lösenord för ett befintligt konto. Om du inte redan har ett konto måste du välja länken Registrera dig nu för att skapa ett nytt användarkonto.

Nästa steg