Azure AD B2C多步骤自定义策略

问题描述

限时删除！！

我们在注册过程中使用了Azure AD B2C自定义策略，在使用AAD-UserWriteUsingLogonEmail技术配置文件在Azure AD B2C中实际创建用户之前，我们需要执行多个步骤(多个屏幕).

We are using Azure AD B2C custom policies for our sign up process and we have multiple steps (multiple screens) before actually creating the user in Azure AD B2C using the AAD-UserWriteUsingLogonEmail technical profile.

假设我们通过以下3个技术资料定义了3个步骤:

Let's say we have 3 steps defined by the following 3 technical profiles:

第一步:

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail-FirstStep">
      <DisplayName>Email signup</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
        <Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
        <Item Key="EnforceEmailVerification">True</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
      </CryptographicKeys>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="title" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="givenName" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="surName" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true" />
        <OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
      </OutputClaims>
      <!-- no user created at this point -->
    </TechnicalProfile>

第二步:

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail-SecondStep">
      <DisplayName>Email signup</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
        <Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
        <Item Key="EnforceEmailVerification">True</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
      </CryptographicKeys>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
        <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
        <OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
      </OutputClaims>
      <!-- no user created at this point -->
    </TechnicalProfile>

第三步:

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail-ThirdStep">
      <DisplayName>Email Signup</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
        <Item Key="ContentDefinitionReferenceId">api.riskwarningtermsconditions</Item>
        <Item Key="EnforceEmailVerification">False</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
      </CryptographicKeys>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectId" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" />
        <OutputClaim ClaimTypeReferenceId="newUser" />

        <OutputClaim ClaimTypeReferenceId="agreeTermsConditions" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="agreeRiskWarning" Required="true"/>
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
      </ValidationTechnicalProfiles>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
    </TechnicalProfile>

当然，我们通过这三个步骤来完成用户旅程，最后以发行令牌结束.

And of course, we have a user journey using these 3 steps in sequence ending by the issuing of the token.

如果我们按原样使用用户旅程，则最终确实会创建该用户，但该用户被阻止登录Azure门户.

If we use the user journey as is, at the end of it, the user is indeed created but is blocked for sign in on Azure portal.

如果我们更改收集到的声明的顺序，并且现在在最后一步中收集密码声明，那么将正确创建用户，并且不会阻止用户登录.因此，密码似乎是一种特殊的声明...

If we change the order of the collected claims and we now collect the password claim during the last step, then the user is correctly created and not blocked for sign in. So it seems that password is a special claim...

从UX的角度来看，我们希望用户在步骤2中输入密码.我们的配置中可能缺少什么? (技术资料或用户旅程).

From a UX perspective, we want the user to enter his password at step 2. What could we missing in our configuration ? (tech profile or user journey).

我的AAD-UserWriteUsingLogonEmail看起来像这样:

My AAD-UserWriteUsingLogonEmail looks like that :

<TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
      <Metadata>
        <Item Key="Operation">Write</Item>
        <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
      </Metadata>
      <IncludeInSso>false</IncludeInSso>
      <InputClaimsTransformations>
        <InputClaimsTransformation ReferenceId="CreateDisplayNameFromFirstNameAndLastName" />
      </InputClaimsTransformations>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
      </InputClaims>
      <PersistedClaims>
        <!-- Required claims -->
        <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
        <PersistedClaim ClaimTypeReferenceId="newPassword" PartnerClaimType="password"/>
        <PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />
        <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration" />

        <PersistedClaim ClaimTypeReferenceId="Verified.strongAuthenticationPhoneNumber" PartnerClaimType="strongAuthenticationPhoneNumber" />

        <!-- Optional claims. -->
        <PersistedClaim ClaimTypeReferenceId="givenName" />
        <PersistedClaim ClaimTypeReferenceId="surname" />
      </PersistedClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectId" />
        <OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
        <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
        <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
      </OutputClaims>
      <IncludeTechnicalProfile ReferenceId="AAD-Common" />
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
    </TechnicalProfile>

推荐答案

如果创建的帐户没有密码，则该帐户将无法登录.

If an account is created without a password, then it is disabled for sign-in.

即用户对象的 accountEnabled 属性设置为false.

我认为该帐户是在没有密码的情况下创建的，因为无法将密码声明(例如 newPassword 声明)从一个步骤(即您的第二个步骤)传递到另一步骤(即您的第二个步骤)第三步).

I believe this account is being created without a password because a password claim (e.g. the newPassword claim) can't be passed from one step (i.e. your second step) to another one (i.e. your third step).

即密码声明作用域"到给定的步骤.

i.e. A password claim is "scoped" to a given step.

这意味着从最终用户那里收集密码声明的编排步骤必须与将其写入 User 对象的步骤相同.

This means the orchestration step that collects the password claim from the end user must be the same step that writes it to the User object.

这篇关于Azure AD B2C多步骤自定义策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

1403页，肝出来的..