Azure Active Directory B2C Custom Invite Policy - Passing Custom Claims Between Steps

£可爱£侵袭症+ 提交于 2019-12-23 15:40:06

问题


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

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

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)

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

Here is the problem,

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

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

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

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

What could it be?


回答1:


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>

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



回答2:


@ChrisPadgett pointed out that I have to add my custom claim(s) (extension_DBId) to the InputClaims in relying party policy

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



来源:https://stackoverflow.com/questions/57027562/azure-active-directory-b2c-custom-invite-policy-passing-custom-claims-between

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!