除了通常根据所用电子邮件当前是否不存在创建帐户之外,我还想知道如何检查 Azure Active Directory 中是否不存在另一个声明值。< /p>
例如,对于我们的应用程序,任何创建帐户的人都必须提供组织名称。注册后,他们就是组织组的所有者。
在创建帐户之前,我想检查组织名称是否与任何其他帐户相关联(如果所有者想要将人员添加到他们的组织,我们将通过邀请进行注册)。如果它不存在,则创建该帐户。否则,我想抛出错误并阻止创建帐户。
在浏览 Azure B2C 技术概要文档后,我认为修改 AAD-UserWriteUsingLogonEmail
是我最好的猜测。
到目前为止我已经尝试了两种方法。第一种方法是包括组织名称的输入声明。但是,这只会冻结测试流程:
<TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
<Metadata>
<Item Key="Operation">Write</Item>
<Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
</Metadata>
<IncludeInSso>false</IncludeInSso>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
<InputClaim ClaimTypeReferenceId="extension_organizationName" Required="true" />
</InputClaims>
<PersistedClaims>
<!-- Required claims -->
<PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
<PersistedClaim ClaimTypeReferenceId="newPassword" PartnerClaimType="password"/>
<PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />
<PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration" />
<!-- Optional claims. -->
<PersistedClaim ClaimTypeReferenceId="givenName" />
<PersistedClaim ClaimTypeReferenceId="surname" />
<PersistedClaim ClaimTypeReferenceId="extension_organizationName" />
</PersistedClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
<OutputClaim ClaimTypeReferenceId="userPrincipalName" />
<OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
</OutputClaims>
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
<UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>
第二种方法与此类似,但使用 <InputClaimsTransformations>
来检查组织名称是否存在通过 DoesClaimExist 操作。使用此方法时,出现以下错误:
无法验证所提供的信息。
由于我是创建自定义策略的新手,是在正确的轨道上修改 AAD-UserWriteUsingLogonEmail
配置文件还是需要完全不同的方法?
编辑:
在按照 Barbara 的链接进行操作后,我能够进行验证。但是,我在尝试阻止使用已与另一个帐户关联的组织的帐户时仍然遇到问题。似乎使用 <InputClaimsTransformations>
并没有真正做任何事情。
答案 0 :(得分:0)
错误消息 Unable to validate the information provided.
表明您没有正确配置自定义政策以使用自定义声明。
因此,您必须遵循文档:
请按照步骤操作,然后重试。