Azure Active Directory B2C自定义邀请策略-在步骤之间传递自定义声明 [英] Azure Active Directory B2C Custom Invite Policy - Passing Custom Claims Between Steps

查看:67
本文介绍了Azure Active Directory B2C自定义邀请策略-在步骤之间传递自定义声明的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I have implemented an invite policy (invite users to the site by sending them an email link) via this example 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中提取声明.电子邮件和自定义声明

In the first step, I extract the claims from the JWT. An email and a custom claim,

<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" DefaultValue="1" />
          </OutputClaims>

        </TechnicalProfile>
      </TechnicalProfiles>

(请注意,我为自定义声明设置了默认值1)

(Note that I set a default value of 1 to my custom claim)

然后,我有了将用户写入目录的技术资料

Then, I have the technical profile that writes the user to the directory

<TechnicalProfile Id="LocalAccountSignUpWithReadOnlyEmail">
          <DisplayName>Email signup</DisplayName>
          <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <Metadata>
            <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
            <Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
            <Item Key="language.button_continue">Create</Item>
            <!-- Sample: Remove sign-up email verification -->
            <Item Key="EnforceEmailVerification">False</Item>
          </Metadata>
          <InputClaimsTransformations>
            <InputClaimsTransformation ReferenceId="CopyEmailAddress" />
          </InputClaimsTransformations>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="ReadOnlyEmail" />
            <InputClaim ClaimTypeReferenceId="extension_DBId" DefaultValue="2" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="ReadOnlyEmail" Required="true" />
            <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
            <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
            <OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" />
            <OutputClaim ClaimTypeReferenceId="newUser" />
          </OutputClaims>
          <ValidationTechnicalProfiles>
          <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail-Custom" />

          </ValidationTechnicalProfiles>
           <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" /> 
        </TechnicalProfile>  

(请注意,这里我为自定义声明设置了默认值2)

(Note that here I set a default value of 2 to my custom claim)

AAD-UserWriteUsingLogonEmail-Custom是对内置(在TrustFrameworkBase.xml中)AAD-UserWriteUsingLogonEmail配置文件的修改,我对其进行了修改,以将我的自定义声明extension_DBId作为持久声明包括在内:

AAD-UserWriteUsingLogonEmail-Custom is a modification of the built-in (inside TrustFrameworkBase.xml) AAD-UserWriteUsingLogonEmail profile, I've modified it to include my custom claim extension_DBId as a persisted claim:

<PersistedClaim ClaimTypeReferenceId="extension_DBId" DefaultValue="3" />

这是问题所在

我生成带有任意extension_DBId(不是1,2或3)的JWT
但是,当我使用它运行策略时,在输出声明中,我得到extension_DBId = 2

I generate a JWT with some arbitrary extension_DBId (Not 1,2 or 3)
But when I run the policy with it, in the output claims, I get extension_DBId=2

这表示第三编排步骤(LocalAccountSignUpWithReadOnlyEmail)没有从第一编排步骤(IdTokenHint_ExtractClaims)收到extension_DBId声明.

Which indicates that the third orchestration step (LocalAccountSignUpWithReadOnlyEmail) didn't receive the extension_DBId claim from the first orchestration step (IdTokenHint_ExtractClaims).

IdTokenHint_ExtractClaims配置文件为什么不将extension_DBId声明转移到LocalAccountSignUpWithReadOnlyEmail配置文件?

Why doesn't the IdTokenHint_ExtractClaims profile transfer the extension_DBId claim to the LocalAccountSignUpWithReadOnlyEmail profile?

我试图删除第二步(SelfAsserted-Unsolicited),但仍然无法正常工作.

I tried to remove the second step (SelfAsserted-Unsolicited), Still didn't work.

那会是什么?

推荐答案

要使用户旅途从输入JWT接收传入的索赔,必须将<InputClaim />添加到依赖方<TechnicalProfile />:

For a user journey to receive an incoming claim from the input JWT, you must add an <InputClaim /> to the relying party <TechnicalProfile />:

<RelyingParty>
  <TechnicalProfile Id="PolicyProfile">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="email" />
      <InputClaim ClaimTypeReferenceId="extension_DBId" />
    </InputClaims>
  </TechnicalProfile>
</RelyingParty>

如果内部声明的声明类型(例如extension_DBId)与输入的JWT的声明类型(例如DBId)不同,则可以将 PartnerClaimType 属性添加到 InputClaim 元素:

If the claim type of the internal claim (e.g. extension_DBId) is different to that of the input JWT (e.g. DBId), then you can add the PartnerClaimType attribute to the InputClaim element:

<InputClaim ClaimTypeReferenceId="extension_DBId" PartnerClaimType="DBId" />

这篇关于Azure Active Directory B2C自定义邀请策略-在步骤之间传递自定义声明的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆