[英]Azure Active Directory B2C Custom Invite Policy - Passing Custom Claims Between Steps
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 我已经通过此示例实现了邀请政策(通过向他们发送电子邮件链接邀请用户访问该网站) https://github.com/azure-ad-b2c/samples/tree/master/policies/invite
I have this user journey 我有这个用户的旅程
<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>
In the first step, I extract the claims from the JWT. 在第一步中,我从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>
(Note that I set a default value of 1
to my custom claim) (请注意,我将自定义声明的默认值设置为
1
)
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>
(Note that here I set a default value of 2
to my custom claim) (注意,我在这里为我的自定义声明设置了默认值
2
)
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: AAD-UserWriteUsingLogonEmail-Custom
是对内置(在TrustFrameworkBase.xml
内部) AAD-UserWriteUsingLogonEmail
配置文件的修改,我已将其修改为包含我的自定义声明extension_DBId
作为持久声明:
<PersistedClaim ClaimTypeReferenceId="extension_DBId" DefaultValue="3" />
Here is the problem, 这是问题所在,
I generate a JWT with some arbitrary extension_DBId
(Not 1,2 or 3) 我生成一个带有一些任意
extension_DBId
(不是1,2或3)的JWT
But when I run the policy with it, in the output claims, I get extension_DBId
= 2
但是当我用它运行策略时,在输出声明中,我得到
extension_DBId
= 2
Which indicates that the third orchestration step ( LocalAccountSignUpWithReadOnlyEmail
) didn't receive the extension_DBId
claim from the first orchestration step ( IdTokenHint_ExtractClaims
). 这表示第三个业务流程步骤(
LocalAccountSignUpWithReadOnlyEmail
)未从第一个业务流程步骤( IdTokenHint_ExtractClaims
)收到extension_DBId
声明。
Why doesn't the IdTokenHint_ExtractClaims
profile transfer the extension_DBId
claim to the LocalAccountSignUpWithReadOnlyEmail
profile? 为什么
IdTokenHint_ExtractClaims
配置文件没有将extension_DBId
声明转移到LocalAccountSignUpWithReadOnlyEmail
配置文件?
I tried to remove the second step ( SelfAsserted-Unsolicited
), Still didn't work. 我试图删除第二步(
SelfAsserted-Unsolicited
),仍然无法正常工作。
What could it be? 会是什么呢?
For a user journey to receive an incoming claim from the input JWT, you must add an <InputClaim />
to the relying party <TechnicalProfile />
: 对于从输入JWT接收传入声明的用户旅程,您必须向依赖方
<TechnicalProfile />
添加<InputClaim />
<TechnicalProfile />
:
<RelyingParty>
<TechnicalProfile Id="PolicyProfile">
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" />
<InputClaim ClaimTypeReferenceId="extension_DBId" />
</InputClaims>
</TechnicalProfile>
</RelyingParty>
If the claim type of the internal claim (eg extension_DBId
) is different to that of the input JWT (eg DBId
), then you can add the PartnerClaimType attribute to the InputClaim element: 如果内部声明的声明类型(例如
extension_DBId
)与输入JWT的声明类型(例如DBId
)不同,则可以将PartnerClaimType属性添加到InputClaim元素:
<InputClaim ClaimTypeReferenceId="extension_DBId" PartnerClaimType="DBId" />
@ChrisPadgett pointed out that I have to add my custom claim(s) ( extension_DBId
) to the InputClaims in relying party policy @ChrisPadgett指出我必须在依赖方策略中将我的自定义声明(
extension_DBId
)添加到InputClaims
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpInvitation" />
<UserJourneyBehaviors>
<ContentDefinitionParameters>
<Parameter Name="ui_locales">{Culture:RFC5646}</Parameter>
</ContentDefinitionParameters>
<ScriptExecution>Allow</ScriptExecution>
</UserJourneyBehaviors>
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
<InputClaim ClaimTypeReferenceId="DBId" /> <!-- This was added -->
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="emails" />
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="extension_DBId" />
<OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
(I then have a claim transformation that converts DBId
to extension_DBId
) (然后我有一个声明转换,将
DBId
转换为extension_DBId
)
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.