Azure AD B2C会在SignUp策略中预先填充自定义属性 [英] Azure AD B2C pre-populate a custom attribute in the SignUp policy

问题描述

从Web应用程序(ASP.Net MVC)调用时，Azure AD B2C是否支持在注册策略"中预填充自定义属性?

Does Azure AD B2C support pre-populating a custom attribute in the SignUp Policy when called from the Web application (ASP.Net MVC)?

我们可以创建一个自定义SignUp属性，但是我们无法在文档中找到有关如何传递值以填充该自定义属性的规范.如果不支持此功能，是否有人找到解决方法?

We can create a custom SignUp attribute but we weren't able to find a specification in the documentation how to pass value to populate the custom attribute. If this is not supported out of the box, does anybody found a workaround?

如果有人遇到类似情况并找到了有用的解决方案，以下是有关上下文的更多详细信息:

Here are some more details for the context in case somebody has faced a similar scenario and found a useful solution:

我们探索了使用Azure AD B2C解决以下情况的选项:注册用户通过发送邀请电子邮件来邀请其他人注册应用程序，该电子邮件包含指向应用程序登录页面的URL以及特殊的邀请代码(guid )作为查询参数，因此它可以单击链接并重定向到注册"页面.被邀请人创建帐户后，我们需要使用代码将新创建的用户与发送邀请的用户相关联.

We explore the options to solve the following scenario with Azure AD B2C: a registered user invites another person to signup to the application by sending an invitation email which has the url to the application’s login page along with a special invitation code(guid) as a query param, so it can click on the link and to be redirected to the Signup page. After the invited person creates an account, we need to use the code in order to associate the newly created user to the user who sent the invitation.

当前，这是使用默认标识提供程序在ASP.Net中实现的(使用AspNet ...表存储数据库中的用户数据).通过使用Azure AD B2C替换本地身份提供程序，我们在往返于Azure AD B2C Signup页面的过程中失去了上下文.用户单击电子邮件上的链接并进入SIgnUp页面，但邀请代码未预先填充.

Currently this is implemented in the ASP.Net using the default identity provider (storing the user data in database with AspNet... tables). With replacing the local identity provider with the Azure AD B2C, we are loosing the context during the round-trip to the Azure AD B2C Signup page. The user clicks on the link on the email and gets to the SIgnUp page but the invitation code is not pre-populated.

推荐答案

邀请流程的有效示例是

A working sample of an invitation flow is here.

在WingTipGamesWebApplication项目中，InvitationController控制器类具有两个操作方法，Create和Redeem.

In the WingTipGamesWebApplication project, the InvitationController controller class has two action methods, Create and Redeem.

Create操作方法将已签名的兑换链接发送到被邀请用户的电子邮件地址.此兑换链接包含此电子邮件地址.还可以包含邀请代码.

The Create action method sends a signed redemption link to the email address for the invited user. This redemption link contains this email address. It could also contain the invitation code.

Redeem操作方法处理兑换链接.它传递电子邮件地址，作为JWT中的 verified_email 声明，该声明已用Wingtip Games应用程序的客户机密签名(请参见WingTipGamesWebApplication中Startup类中的CreateSelfIssuedToken方法)项目)，从兑换链接到邀请政策.它还可以传递邀请代码.

The Redeem action method handles the redemption link. It passes the email address, as the verified_email claim in a JWT that is signed with the client secret of the Wingtip Games application (see the CreateSelfIssuedToken method in the Startup class in the WingTipGamesWebApplication project), from the redemption link to the Invitation policy. It could also pass the invitation code.

邀请政策可以在 邀请政策将 verified_email 声明声明为输入声明:

The Invitation policy declares the verified_email claim as an input claim:

<RelyingParty>
  <DefaultUserJourney ReferenceId="Invitation" />
  <TechnicalProfile Id="Invitation">
    <InputTokenFormat>JWT</InputTokenFormat>
      <CryptographicKeys>
        <Key Id="client_secret" StorageReferenceId="WingTipGamesClientSecret" />
    </CryptographicKeys>
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" />
    </InputClaims>
  </TechnicalProfile>
</RelyingParty>

extension_verifiedEmail 声明类型(声明为只读字段(因此最终用户无法修改))被映射到 verified_email >输入声明:

The extension_verifiedEmail claim type, which is declared as a read-only field (so that it can't be modified by the end user), is mapped to the verified_email input claim:

<BuildingBlocks>
  <ClaimsSchema>
    <ClaimType Id="extension_VerifiedEmail">
      <DisplayName>Verified Email</DisplayName>
      <DataType>string</DataType>
      <DefaultPartnerClaimTypes>
        <Protocol Name="OAuth2" PartnerClaimType="verified_email" />
        <Protocol Name="OpenIdConnect" PartnerClaimType="verified_email" />
        <Protocol Name="SAML2" PartnerClaimType="http://schemas.wingtipb2c.net/identity/claims/verifiedemail" />
      </DefaultPartnerClaimTypes>
      <UserInputType>Readonly</UserInputType>
    </ClaimType>
  </ClaimsSchema>
</BuildingBlocks>

邀请用户旅程可以在 邀请用户旅程的第二个编配步骤将执行 LocalAccount-Registration-VerifiedEmail 技术资料:

The second orchestration step of the Invitation user journey executes the LocalAccount-Registration-VerifiedEmail technical profile:

<UserJourney Id="Invitation">
  <OrchestrationSteps>
    ...
    <OrchestrationStep Order="2" Type="ClaimsExchange">
      <ClaimsExchanges>
        ...
        <ClaimsExchange Id="LocalAccountRegistrationExchange" TechnicalProfileReferenceId="LocalAccount-Registration-VerifiedEmail" />
      </ClaimsExchanges>
    </OrchestrationStep>
  </OrchestrationSteps>
</UserJourney>

LocalAccount-Registration-VerifiedEmail 技术配置文件使用已验证的电子邮件地址注册本地帐户:

The LocalAccount-Registration-VerifiedEmail technical profile registers the local account with the verified email address:

<TechnicalProfile Id="LocalAccount-Registration-VerifiedEmail">
  <DisplayName>WingTip Account</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ContentDefinitionReferenceId">api.localaccount.registration</Item>
    <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
    <Item Key="language.button_continue">Create</Item>
  </Metadata>
  <CryptographicKeys>
    <Key Id="issuer_secret" StorageReferenceId="TokenSigningKeyContainer" />
  </CryptographicKeys>
  <InputClaimsTransformations>
    <InputClaimsTransformation ReferenceId="CreateEmailFromVerifiedEmail" />
  </InputClaimsTransformations>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="extension_VerifiedEmail" Required="true" />
    <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
    <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
    <OutputClaim ClaimTypeReferenceId="displayName" Required="true" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
    <OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
    <OutputClaim ClaimTypeReferenceId="newUser" />
    <OutputClaim ClaimTypeReferenceId="objectId" />
    <OutputClaim ClaimTypeReferenceId="sub" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExists" />
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SSOSession-AzureActiveDirectory" />
</TechnicalProfile>

在 AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExists 验证技术配置文件注册本地帐户之前， CreateEmailFromVerifiedEmail 声明转换会将 verified_email 声明复制到电子邮件声明:

Before the local account is registered by the AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExists validation technical profile, the CreateEmailFromVerifiedEmail claims transformation copies the verified_email claim to the email claim:

<ClaimsTransformation Id="CreateEmailFromVerifiedEmail" TransformationMethod="FormatStringClaim">
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" TransformationClaimType="inputClaim" />
  </InputClaims>
  <InputParameters>
    <InputParameter Id="stringFormat" DataType="string" Value="{0}" />
  </InputParameters>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="email" TransformationClaimType="outputClaim" />
  </OutputClaims>
</ClaimsTransformation>

要针对本地帐户保存邀请代码，您必须:

To save the invitation code against the local account, you must:

• 将"extension_InvitationCode"声明添加到声明架构中
• 将其添加为邀请政策
的输入声明
• 将其作为输入声明添加到 LocalAccount-Registration-VerifiedEmail 技术资料
• 将其添加为 AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExist 技术资料
的永久声明

• Add the "extension_InvitationCode" claim to the claims schema
• Add it as an input claim to the Invitation policy
• Add it as an input claim to the LocalAccount-Registration-VerifiedEmail technical profile
• Add it as a persisted claim to the AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExist technical profile

这篇关于Azure AD B2C会在SignUp策略中预先填充自定义属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！