Dans l'annuaire actif B2C, existe-t-il un moyen de limiter l'inscription en fonction d'un pool d'adresses e-mail? Ou puis-je pré-enregistrer un compte, alors l'utilisateur doit choisir un mot de passe ou utiliser un compte google ou facebook?Azure enregistrement de limite de répertoire actif en fonction d'un pool d'adresses e-mail ou d'un compte pré-inscription
Il n'existe aucun mécanisme intégré dans Azure AD B2C pour limiter l'enregistrement à un ensemble spécifique d'utilisateurs/d'e-mails. Vous pouvez le demander via le Azure AD B2C feedback forum.
Cependant, vous pouvez mettre en œuvre vous-même par:
Ceci est similaire à Azure AD B2C - approval upon sign up?
Cela a été répondu, mais deux autres options,
dans une stratégie personnalisée, vous pouvez créer une connexion OIDC à un autre locataire Azure puis pas avoir un lien d'inscription, mais connectez-vous simplement
Ou vous pouvez avoir une politique d'inscription personnalisée qui vérifie l'adresse e-mail de l'utilisateur par rapport à une liste prédéfinie que vous pouvez garder en e voyage si vous ne voulez pas qu'ils continuent
Un exemple fonctionnel du flux d'invitation mentionné par @saca est here.
Dans le projet WingTipToysWebApplication, la classe de contrôleur UserController comporte deux méthodes d'action, Migrate et Activate.
La méthode Migrate crée le compte local avec un mot de passe aléatoire.
La méthode Activate exécute les étapes suivantes:
du lien de rachat est traitée par la méthode d'action Redeem de la classe contrôleur ActivationController dans le projet WingTipGamesWebApplication.
Cette action du contrôleur passe alors l'adresse e-mail et la valeur nonce, comme « verified_email » et les revendications « de » nonce, du lien de rachat à la politique d'activation qui est here.
Le Activation politique déclare ces affirmations comme entrée affirme:
<TrustFrameworkPolicy>
<RelyingParty>
<DefaultUserJourney ReferenceId="Activation" />
<TechnicalProfile Id="Activation">
<InputClaims>
<InputClaim ClaimTypeReferenceId="extension_Nonce" />
<InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" />
</InputClaims>
</TechnicalProfile>
</RelyingParty>
</TrustFrameworkPolicy>
La première étape d'orchestration de la Activation voyage utilisateur exécute la LocalAccount-activation profil technique:
<TechnicalProfile Id="LocalAccount-Activation">
<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.activation</Item>
<Item Key="IpAddressClaimReferenceId">IpAddress</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="TokenSigningKeyContainer" />
</CryptographicKeys>
<IncludeInSso>false</IncludeInSso>
<InputClaimsTransformations>
<InputClaimsTransformation ReferenceId="CreateEmailFromVerifiedEmail" />
</InputClaimsTransformations>
<InputClaims>
<InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="extension_VerifiedEmail" Required="true" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" />
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="strongAuthenticationPhoneNumber" />
<OutputClaim ClaimTypeReferenceId="sub" />
<OutputClaim ClaimTypeReferenceId="userPrincipalName" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="ClassicAccount-CheckNonce" />
<ValidationTechnicalProfile ReferenceId="AzureActiveDirectoryStore-ReadUserByEmail-ThrowIfNotExists" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
Ce profil technique valide l'adresse e-mail et la valeur de nonce en invoquant une API back-end (voir la méthode d'action CheckNonce de la classe contrôleur AccountController dans le projet WingTipIdentityWebApplication) qui est représenté par la ClassicAccount-CheckNonce profil technique:
<TechnicalProfile Id="ClassicAccount-CheckNonce">
<DisplayName>Classic Account Check Nonce</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">https://wingtipidentityb2c.azurewebsites.net/api/account/checknonce</Item>
<Item Key="AuthenticationType">Basic</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="SendClaimsIn">Form</Item>
</Metadata>
<CryptographicKeys>
<Key Id="BasicAuthenticationUsername" StorageReferenceId="ClassicAccountClientId" />
<Key Id="BasicAuthenticationPassword" StorageReferenceId="ClassicAccountClientSecret" />
</CryptographicKeys>
<InputClaims>
<InputClaim ClaimTypeReferenceId="extension_verifiedEmail" PartnerClaimType="userName" />
<InputClaim ClaimTypeReferenceId="extension_Nonce" PartnerClaimType="nonce" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SSOSession-Noop" />
</TechnicalProfile>
Ce backend API valide l'adresse e-mail et la valeur de nonce dans le enregistrement de base de données. Si l'adresse e-mail existe et que la valeur de nonce est valide pour cette adresse e-mail (c.-à-d. Non utilisée), le backend de l'API renvoie 200 OK et le nouvel utilisateur peut passer à l'étape Activation voyage (qui est de réinitialiser le mot de passe aléatoire du compte local). Si ce n'est pas le cas, il renvoie 409 Conflit avec un message d'erreur, qui est affiché par B2C à l'utilisateur final.