Question

在azure活动目录B2C中，有没有办法根据电子邮件地址池限制注册？或者我可以预先注册帐户，然后用户必须选择密码或使用谷歌或Facebook帐户吗？

Answer 1

Azure AD B2C中没有内置机制来限制对特定用户/电子邮件集的注册。您可以通过Azure AD B2C feedback forum。

申请

但是，您可以通过以下方式自行实现：

拥有自定义属性以确定用户是否已获得批准＆＃34;或不。您可以让用户自行注册，然后您可以创建一个体验或流程，以便向尚未获得批准的用户查询Azure AD Graph。然后批准或删除它们。
构建邀请流。当您邀请用户时，您将通过Azure AD Graph创建用户。然后，您可以将用户引导至密码重置政策，作为他们的＆＃34;帐户验证＆＃34;流。 这仅适用于本地帐户，因为您无法预先创建由社交帐户支持的用户。

这类似于Azure AD B2C - approval upon sign up?

Answer 2

这已经得到了回答，但还有其他一些选择，

在自定义策略中，您可以创建与其他Azure租户的OIDC连接，然后没有注册链接，只需登录

或者您可以制定自定义注册政策，根据您可以保存的预定义列表检查用户的电子邮件地址，如果您不希望他们继续，则结束旅程

Answer 3

@saca提到的邀请流的工作样本是here。

在WingTipToysWebApplication项目中，UserController控制器类有两种操作方法，Migrate和Activate。

Migrate方法使用随机密码创建本地帐户。

Activate方法执行以下步骤：

它将本地帐户的名为 ActivationStatus 的自定义属性设置为“待处理”。
它会将签名的兑换链接发送到本地帐户的电子邮件地址。此兑换链接包含此电子邮件地址和nonce值。此nonce值确保兑换链接只能使用一次。
它将电子邮件地址和nonce值保存在数据库记录中。

兑换链接由Redeem项目中ActivationController控制器类的WingTipGamesWebApplication操作方法处理。

此控制器操作然后将电子邮件地址和随机数值（如“verified_email”和“nonce”声明）从兑换链接传递到<{>>激活策略here。

激活政策将这些声明声明为输入声明：

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

激活用户旅程的第一个编排步骤执行 LocalAccount-Activation 技术配置文件：

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

此技术配置文件通过调用API后端验证电子邮件地址和nonce值（请参阅CheckNonce项目中AccountController项目中WingTipIdentityWebApplication控制器类的<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>操作方法）通过 ClassicAccount-CheckNonce 技术资料：

{{1}}

此API后端验证数据库记录中的电子邮件地址和nonce值。如果电子邮件地址确实存在且nonce值对此电子邮件地址有效（即尚未使用），则API后端返回200 OK，新用户可以继续执行激活的第二个编排步骤用户旅程（即重置本地帐户的随机密码）。如果没有，则返回409 Conflict，并显示错误消息，该消息由B2C显示给最终用户。

Azure Active Directory限制根据电子邮件地址池或预注册帐户进行注册

3 个答案: