正如我从文档中了解到的，Azure AD B2C 会在第一次登录时为来自社交登录（例如 GMail/Facebook）的每个用户创建一个新的本地帐户（请纠正我，如果我错了）。但是我想拦截这个并将用户链接到一个已经存在的（用户自己的）本地帐户，而无需通过自定义策略创建新的本地帐户。

我正在寻找一种方法来向emailsAzure AD B2C的自定义策略添加声明(电子邮件集合).此应用程序声明可直接从Azure门户获得,但我找不到在我需要创建的自定义策略中实现此方法的方法.

我想要实现的是为我的WebApp用户提供Azure AD B2C身份验证,为员工提供Azure AD身份验证作为自定义身份验证提供程序,这意味着我需要emails为本地帐户和Azure AD 添加两次声明.

我按照本指南制作自定义策略,因此我添加了一个新ClaimsProvider的TrustFrameworkExtensions.xml文件.

当我下载在Azure门户中创建的注册和登录策略时,我可以看到以下输出声明:

<OutputClaim ClaimTypeReferenceId="emails" />

我试图将该行添加到我的自定义策略中,但它不会返回emails声明.

有任何想法吗？

我正在尝试使用OAUTH-KV Claims Resolver提取作为声明foo传递给 AAD B2C 自定义策略authorize端点的名为foo.

在foo ClaimType被定义为

<ClaimType Id="foo">
  <DisplayName>Foo debug claim</DisplayName>
  <DataType>string</DataType>
  <UserInputType>TextBox</UserInputType>
</ClaimType>

和TechnicalProfile作为

<TechnicalProfile Id="LocalAccount-Register">
  <DisplayName>Register</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.prescribedfirm</Item>
    <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
    <Item Key="language.button_continue">Create</Item>
  </Metadata>
  <CryptographicKeys>
    <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
  </CryptographicKeys>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="foo" DefaultValue="{OAUTH-KV:foo}" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="foo" Required="true" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

但是，值foo显示为{OAUTH-KV:foo}而不是传递的实际值。

我相信我已按照文档中的说明进行操作。

我还需要做些什么来完成这项工作吗？

编辑

与索赔解析器相关的文档于 …

我创建了 Azure B2C 自定义策略来获取 ID/访问令牌中的声明并通过“authorization_code”授予获取刷新令牌。然后我通过 Azure AD Graph API 更新了用户声明之一，即（“displayName”）。接下来，我尝试通过“refresh_grant”针对相同的 Azure B2C 自定义策略使用上述刷新令牌来获取 ID/访问令牌中更新的声明（“displayName”），但我没有得到它。

我已经在 B2C 策略中尝试过“RefreshTokenUserJourneyId”作为 JWT 颁发者，但没有任何效果。

更新后，我应该如何通过刷新令牌授予来获取 ID/访问令牌中的最新用户声明。

需要帮助。

我已将 Azure AD B2C 设置为允许用户使用自定义策略从“常规”AAD 目录进行身份验证，如下所述https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-目录-b2c-setup-aad-自定义。在一种情况下，我希望用户进行注册（使用其 AAD 凭据进行身份验证，在 AAD B2C 目录中创建相应的对象，并将 objectidentifier 作为声明传递给我的应用程序），而不提供任何进一步的信息。从示例开始，我无法弄清楚如何完全跳过自我断言步骤。我尝试过的两种方法是

1) 删除SelfAsserted-Social ClaimsExchange，以及 2) 修改（实际上是复制到 TrustFrameworkExtensions、重命名和编辑）SelfAsserted-Social和AAD-UserReadUsingObjectId ClaimsExchanges，以便唯一的 OutputClaim 条目不需要用户提示。

在这两种方法中，从 UI 角度来看，注册似乎都有效，但不会在 B2C 目录中创建用户对象。使用 App Insights，在两种方法中AAD-UserReadUsingObjectId似乎都会生成Microsoft.Cpim.Common.PolicyException。

完整的用户旅程是

<UserJourney Id="SignUpAAD">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="KDEWEbAppTestExchange"   />
          </ClaimsProviderSelections>
        </OrchestrationStep>

        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="KDEWebAppTestExchange" TechnicalProfileReferenceId="KDEWebAppTestProfile" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="3" Type="ClaimsExchange">
           <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>

         <!-- prepare ground for searching for user …

我们有 Azure AD B2C 设置来使用身份体验框架，并且在登录/注册时进行 REST 调用以通过 Azure 函数获得额外的安全凭据声明。这工作正常。

当我们通过 Azure AD B2C 通过 Refresh_Token 请求访问/Id 令牌时，看起来我们获得了相同的令牌，并且它不会调用 REST API 来获取最新更新的令牌声明。是否可以更改此用户旅程？

是否有另一种解决方案无需再次登录即可刷新令牌以获取最新更新？

（我们可以在代码中解决这个问题，而不是使用令牌，但出于各种原因，我们想先探索一下）。

我们有一个使用自定义身份体验框架策略通过 Azure AD B2C 进行保护的 Web 应用程序，允许用户使用社交身份（Microsoft、Google、Facebook）或来自另一个联合 Azure AD 实例的身份或“本地身份”进行注册和登录。 ' 电子邮件/密码帐户。

所有社交帐户和联合 AD 均正常工作。使用电子邮件/密码注册和登录工作正常，但我们现在遇到错误。自从我们最后一次知道电子邮件/密码配置正常工作以来，我们没有故意对我们的电子邮件/密码配置进行任何更改，因此我们不确定这是如何发生的。

问题是：使用新电子邮件地址注册工作正常，并且在该过程完成后，用户正确登录，并且他们的帐户出现在目录中。但是，如果用户注销，则任何重新登录的尝试都会失败：

（显示的电子邮件地址不是实际的。多个用户使用新旧电子邮件/密码组合重复出现错误。）

深入研究门户，发现根本错误如下：

70001 在名为 Y 的租户中找不到名为 X 的应用程序。如果该应用程序尚未由租户管理员安装或未经租户中任何用户同意，则可能会发生这种情况。您可能已将身份验证请求发送给了错误的租户。

此错误有时似乎与未能向门户中的应用程序授予权限有关。我们已尝试删除和恢复所有权限，并重新授予权限。这并没有解决问题。

有谁知道可能导致此问题的原因，特别是为什么注册/登录可以正常工作，但返回登录却不能？

更新：

只是为了确认我们在 AD 目录中配置了 IEF 和代理 IEF 应用程序：

我们login-NonInteractive在 TrustFrameworkExtensions.xml 中配置了技术配置文件：

连接 Application Insights 后（按照这些说明https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-troubleshoot-custom），我们就能够做到这一点更详细的错误：

AADSTS70001：在 weapageengine.onmicrosoft.com 目录中找不到标识符为“ProxyIdentityExperienceFrameworkAppID”的应用程序

在我们的任何自定义策略中出现的唯一位置“ProxyIdentityExperienceFrameworkAppID”显示在上面的 XML 片段中，但这根据此处的文档似乎是正确的： https: //github.com/Azure-Samples/active-directory-b2c-custom -policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38 - 除非我们也打算更新这些“DefaultValue”属性？

解决方案： 根据下面的答案，有必要使用相关应用程序 ID 更新元数据和默认值。值得注意的是，在 GitHub 示例https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38中，样板值的大小写不同，导致替换全部中缺少的一个：

是否可以创建自定义策略来重置已知电子邮件的密码？

我使用 Graph API 创建用户并将邀请电子邮件发送到指定的电子邮件地址。

我希望用户单击该电子邮件中的链接并为其帐户设置密码。

我可以使用此电子邮件声明创建签名令牌，并将其作为断言发送到我的自定义策略。因此政策将电子邮件作为输入声明。我在跟踪中看到它。

但是我无法绕过密码重置过程中的电子邮件验证步骤 - 当我删除它时，我收到 500 服务器错误，但没有其他详细信息。

我也尝试将用户的 objectId 作为输入声明发送，但这也无济于事。

有没有办法跳过电子邮件验证？

我有一个注册流程，它工作正常并且是多步骤的：

1. 联系方式
2. 确认
3. 密码

现在的流程是，完成所有步骤后，将创建一个新用户，如果用户名已经存在，那么在最后一步中我会收到一条错误消息，表明该用户已经存在。现在我需要改变这个流程。输入联系方式（电子邮件）后，我想检查该用户是否存在。如果它存在，那么我需要显示在第一步本身的最后一步中显示的错误消息，并阻止旅程移动到下一步。

为了实现这一目标，我所做的是：

创建了一个 TP，使用电子邮件读取用户详细信息，并将其作为第一步的验证技术配置文件：

<TechnicalProfile Id="AAD-CheckUserExist">
                    <Metadata>
                        <Item Key="Operation">Read</Item>                        
                        <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
                    </Metadata>
                    <IncludeInSso>false</IncludeInSso>
                    <InputClaims>                       
                        <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />                        
                    </InputClaims>
                    <OutputClaims>
                        <!-- Required claims -->
                        <OutputClaim ClaimTypeReferenceId="objectId" />
                        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
                        <!-- Optional claims -->
                        <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
                        <OutputClaim ClaimTypeReferenceId="displayName" />
                        <OutputClaim ClaimTypeReferenceId="accountEnabled" />
                        <OutputClaim ClaimTypeReferenceId="otherMails" />
                        <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress"/>
                        <OutputClaim ClaimTypeReferenceId="signInNames.phoneNumber"/>
                        <OutputClaim ClaimTypeReferenceId="givenName" />
                        <OutputClaim ClaimTypeReferenceId="surname" />
                    </OutputClaims>
                    <IncludeTechnicalProfile ReferenceId="AAD-Common" />
                </TechnicalProfile>

并添加<Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>到<Metadata>.

以下是验证配置文件部分：

<TechnicalProfile Id="AAD-CheckUserExist">
                    <Metadata>
                        <Item Key="Operation">Read</Item>                        
                        <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item> …

我已通过此示例实施了邀请策略（通过向用户发送电子邮件链接来邀请用户访问该站点）https://github.com/azure-ad-b2c/samples/tree/master/policies/invite

我有这个用户旅程

<UserJourney Id="SignUpInvitation">
      <OrchestrationSteps>

        <OrchestrationStep Order="1" Type="GetClaims" CpimIssuerTechnicalProfileReferenceId="IdTokenHint_ExtractClaims" />

        <OrchestrationStep Order="2" Type="ClaimsExchange">
         <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>email</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>        
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Unsolicited" TechnicalProfileReferenceId="SelfAsserted-Unsolicited"/>
          </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSignUpWithReadOnlyEmail" TechnicalProfileReferenceId="LocalAccountSignUpWithReadOnlyEmail"/>
          </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="5" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>

      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb"/>
    </UserJourney>

在第一步中，我从 JWT 中提取声明。一封电子邮件和一份自定义声明，

<TechnicalProfiles>
        <TechnicalProfile Id="IdTokenHint_ExtractClaims">
          <DisplayName> My ID Token Hint TechnicalProfile</DisplayName>
          <Protocol Name="None" />
          <Metadata>

            <Item Key="METADATA">https://mywebsite.com/internal/v1/invitation/.well-known/openid-configuration</Item>

          </Metadata>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="email" />  
            <OutputClaim ClaimTypeReferenceId="extension_DBId" …