Azure AD B2C pré-remplit un attribut personnalisé dans la stratégie d'inscription

Question

Azure AD B2C prend-il en charge le pré-remplissage d'un attribut personnalisé dans la stratégie d'inscription lorsqu'il est appelé à partir de l'application Web (ASP.Net MVC)?

Nous pouvons créer un attribut SignUp personnalisé, mais nous n'avons pas été en mesure de trouver une spécification dans la documentation sur la façon de transmettre la valeur pour remplir l'attribut personnalisé. Si ce n'est pas pris en charge hors de la boîte, quelqu'un a trouvé une solution de contournement?

Voici quelques détails pour le contexte dans le cas où quelqu'un a fait face à un scénario similaire et trouvé une solution utile:

Nous explorons les options pour résoudre le scénario suivant avec B2C Azure AD: un utilisateur enregistré invite une autre personne Pour vous inscrire à l'application en envoyant un email d'invitation qui a l'URL à la page de connexion de l'application avec un code d'invitation spécial (guid) comme un paramètre de requête, il peut cliquer sur le lien et être redirigé vers la page d'inscription. Une fois que la personne invitée crée un compte, nous devons utiliser le code pour associer l'utilisateur nouvellement créé à l'utilisateur qui a envoyé l'invitation.

Actuellement, cela est implémenté dans ASP.Net en utilisant le fournisseur d'identité par défaut (en stockant les données utilisateur dans la base de données avec des tables AspNet ...). En remplaçant le fournisseur d'identité local par Azure AD B2C, nous perdons le contexte lors de l'aller-retour vers la page d'inscription Azure AD B2C. L'utilisateur clique sur le lien de l'email et accède à la page SIgnUp mais le code d'invitation n'est pas pré-rempli.

Answer 1

Un exemple de flux d'invitation est here.

Dans le projet WingTipGamesWebApplication, la classe de contrôleur InvitationController comporte deux méthodes d'action, Create et Redeem.

La méthode d'action Create envoie un lien d'échange signé à l'adresse électronique de l'utilisateur invité. Ce lien de rachat contient cette adresse email. Il pourrait également contenir le code d'invitation.

La méthode d'action Redeem gère le lien d'échange. Il passe l'adresse e-mail comme verified_email dans un JWT signé avec le secret client de l'application Wingtip Games (voir la méthode CreateSelfIssuedToken dans la classe Startup dans le projet WingTipGamesWebApplication), du lien de rachat à l'invitation politique. Il pourrait également passer le code d'invitation.

La règle Invitation peut être consultée au .

Le Invitation politique déclare le verified_email demande comme une demande d'entrée:

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

Le extension_verifiedEmail type de réclamation, qui est déclarée comme un champ de lecture seule (de sorte qu'il ne peut pas être modifiés par l'utilisateur final), est mis en correspondance avec le verified_email revendication d'entrée:

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

Le Invitation le parcours utilisateur peut être trouvé dans here.

La deuxième étape d'orchestration de la Invitation voyage de l'utilisateur exécute le LocalAccount-Enregistrement-VerifiedEmail profil technique:

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

Le profil technique LocalAccount-inscription-VerifiedEmail enregistre le compte local avec le adresse e-mail vérifiée:

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

Pour enregistrer la code d'invitation sur le compte local, vous devez:

• Ajouter le « extension_InvitationCode » demande au schéma de revendications
• Ajouter comme une demande d'entrée à l'Invitation politique
• Ajouter comme une demande d'entrée au LocalAccount-inscription-VerifiedEmail profil technique
• Ajouter comme une réclamation à la persistante AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExist profil technique