Azure active directory limit registration according to an email address pool or pre register account

Question

In azure active-directory B2C, is there a way to limit registration according to an email address pool? Or can i pre register account, then user would have to choose passwor

Answer 1

There is no built-in mechanism in Azure AD B2C to limit registration to a specific set of users / emails. You can request this via the Azure AD B2C feedback forum.

However, you can implement this yourself by:

1. Having a custom attribute to determine whether a user is "approved" or not. You would let users sign up by themselves and you would create an experience or flow that queries the Azure AD Graph for users that haven't been "approved" and then either approve them or delete them.
2. Building an invitation flow. When you invite a user, you'd create the user through the Azure AD Graph. You would then direct your users to the Password Reset policy as their "account verification" flow. This only works for local accounts as you can't pre-create users backed by social-accounts.

This is similar to Azure AD B2C - approval upon sign up?

Answer 2

This has been answered but a couple of other options,

in a custom policy you can create an OIDC connection to another Azure tenant and then not have a sign up link but just sign in

Or you could have a custom sign up policy that checks the user's email address against a predefined list you can keep in storage and then end the journey if you dont want them to continue

Answer 3

A working sample of the invitation flow that was mentioned by @saca is here.

In the WingTipToysWebApplication project, the UserController controller class has two action methods, Migrate and Activate.

The Migrate method creates the local account with a random password.

The Activate method executes the following steps:

• It sets a custom attribute called ActivationStatus of the local account to "Pending".
• It sends a signed redemption link to the email address for the local account. This redemption link contains this email address and a nonce value. This nonce value ensures the redemption link can only be used once.
• It saves the email address and the nonce value in a database record.

The redemption link is handled by the Redeem action method of the ActivationController controller class in the WingTipGamesWebApplication project.

This controller action then passes the email address and the nonce value, as the "verified_email" and "nonce" claims, from the redemption link to the Activation policy which is here.

The Activation policy declares these claims as input claims:

<TrustFrameworkPolicy>
  <RelyingParty>
    <DefaultUserJourney ReferenceId="Activation" />
    <TechnicalProfile Id="Activation">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="extension_Nonce" />
        <InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" />
      </InputClaims>
    </TechnicalProfile>
  </RelyingParty>
</TrustFrameworkPolicy>

The first orchestration step of the Activation user journey executes the LocalAccount-Activation technical profile:

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

This technical profile validates the email address and the nonce value by invoking an API backend (see the CheckNonce action method of the AccountController controller class in the WingTipIdentityWebApplication project) which is represented by the ClassicAccount-CheckNonce technical profile:

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

This API backend validates the email address and the nonce value in the database record. If the email address does exist and the nonce value is valid for this email address (i.e. it hasn't been used), then the API backend returns 200 OK and the new user can continue to the second orchestration step of the Activation user journey (which is to reset the random password of the local account). If not, then it returns 409 Conflict with an error message, which is displayed by B2C to the end user.