Azure AD B2CはSignUpポリシーのカスタム属性を事前に設定します

Question

Azure AD B2CはWebアプリケーション（ASP.Net MVC）から呼び出されたときにSignUpポリシーのカスタム属性を事前に設定できますか？

カスタムSignUp属性を作成することはできますが、カスタム属性を設定するために値を渡す方法については、ドキュメントで仕様を見つけることができませんでした。これがボックスからサポートされていない場合は、回避策が見つかったのでしょうか？

私たちはアズールADのB2Cで次のシナリオを解決するためのオプションを探る：登録ユーザーは、別の人を誘う誰かが同様のシナリオに直面し、有益な解決策を見つけた場合にはここで

は、コンテキストのためのいくつかの詳細を読みます。アプリケーションのログインページに特別な招待コード（guid）とともにクエリーパラメータとしてURLを持つ招待メールを送信し、リンクをクリックしてサインアップページにリダイレクトすることで、アプリケーションにサインインすることができます。招待された人がアカウントを作成した後、招待を送信したユーザーに新しく作成したユーザーを関連付けるためにコードを使用する必要があります。

現在のところ、これはASP.Netでデフォルトのアイデンティティプロバイダ（AspNet ...テーブルを使用してデータベースにユーザデータを格納する）を使用して実装されています。ローカルアイデンティティプロバイダをAzure AD B2Cに置き換えると、Azure AD B2C Signupページへの往復中にコンテキストが失われています。ユーザーは電子メールのリンクをクリックしてSIgnUpページに移動しますが、招待コードは事前入力されていません。

Answer 1

招待フローの作業サンプルはhereです。 WingTipGamesWebApplicationプロジェクトで

、InvitationControllerコントローラクラスは、二つの動作方法、CreateとRedeemを有しています。

Createアクションメソッドは、招待されたユーザーの電子メールアドレスに署名済みの利用リンクを送信します。この償還リンクには、このメールアドレスが含まれています。招待コードを含むこともできます。

Redeemアクションメソッドは、引き換えリンクを処理します。これは、verified_emailとしてWingtip Gamesアプリケーションのクライアントシークレット（WingTipGamesWebApplicationプロジェクトのStartupクラスのCreateSelfIssuedTokenメソッドを参照してください）、への交換リンクから署名されたJWTで請求されます。ポリシー招待状を渡すこともできます。

招待状のポリシーはhereにあります。

招待ポリシーは、入力クレームとして verified_email項宣言：読み取り専用フィールドとして宣言され

<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項タイプ、（それができないようにします

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

：）エンドユーザによって修正すること、 verified_email入力項にマッピングされます

招待状ユーザー旅行はhereにあります。

が

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

LocalAccount-登録-VerifiedEmail技術的なプロファイルが持つローカルアカウントを登録します。

は

招待ユーザーの旅の第二のオーケストレーションのステップは、LocalAccount-登録-VerifiedEmail技術的なプロファイルを実行します確認済みのメールアドレス：

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

ローカルアカウントに対する招待コード、あなたは次の条件を満たす必要があります。

• 請求スキーマ
• に「extension_InvitationCode」の主張を追加招待ポリシー
• への入力クレームが入力主張としてそれを追加して、それを追加します。 LocalAccount-登録-VerifiedEmail技術的なプロファイルへ
• AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExist技術的なプロファイルに永続主張としてそれを追加