简体   繁体   English

如何在 Azure B2C 基于请求的输入查询参数的自定义策略的用户旅程中跳过一步

[英]How to Skip a step in user journey of Azure B2C Custom policy based on an input query parameter of the request

I have an input claim as below <InputClaim ClaimTypeReferenceId="isAccessFlow" PartnerClaimType="access_flow" DefaultValue="{OAUTH-KV:access_flow}"/>我有如下输入声明<InputClaim ClaimTypeReferenceId="isAccessFlow" PartnerClaimType="access_flow" DefaultValue="{OAUTH-KV:access_flow}"/>

under <TechnicalProfile Id="Google-OAUTH"><TechnicalProfile Id="Google-OAUTH">

Based on this value i want to skip the MFA orchesration step in user journey.To do that i need to get the value form output claim.基于这个值,我想跳过用户旅程中的 MFA 编排步骤。为此,我需要从 output 声明中获取值。 So how can i pass the value from input claim into output claim or how can i directly use input claim in userjourney to stop the step.那么如何将输入声明中的值传递给 output 声明,或者我如何直接在 userjourney 中使用输入声明来停止该步骤。

My user journey orchestration step are below我的用户旅程编排步骤如下

        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signinandsignupwithpassword">
          <ClaimsProviderSelections>
          <ClaimsProviderSelection TargetClaimsExchangeId="AD" />
          <ClaimsProviderSelection TargetClaimsExchangeId="ADFSExchange" />
          <ClaimsProviderSelection TargetClaimsExchangeId="MicrosoftExchange" />
           <ClaimsProviderSelection TargetClaimsExchangeId="GoogleExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
          <ClaimsExchange Id="ADFSExchange" TechnicalProfileReferenceId="ADFS-SAML2" />
          <ClaimsExchange Id="MicrosoftExchange" TechnicalProfileReferenceId="MSA-OIDC" />
          <ClaimsExchange Id="AD" TechnicalProfileReferenceId="OIDC-AD" />
            <ClaimsExchange Id="GoogleExchange" TechnicalProfileReferenceId="Google-OAUTH" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- For social IDP authentication, attempt to find the user account in the directory. -->
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). 
          This can only happen when authentication happened using a social IDP. If local account was created or authentication done
          using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent 
          in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>socialIdpAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect 
             from the user. So, in that case, create the user in the directory if one does not already exist 
             (verified using objectId which would be set from the last step if account was created in the directory. -->
        <OrchestrationStep Order="6" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>
   <!-- Phone verification: If MFA is not required, the next three steps (#5-#7) should be removed.
             This step checks whether there's a phone number on record,  for the user. If found, then the user is challenged to verify it. -->
        <OrchestrationStep Order="7" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>isActiveMFASession</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
              <Value>requiresMFA</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
           <!--  <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>isAccessFlow</Value>
               <Value>true</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition> -->
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="PhoneFactor-Verify" TechnicalProfileReferenceId="PhoneFactor-InputOrVerify" />
          </ClaimsExchanges>
        </OrchestrationStep>

The commented part in orchestration step 6 is what i am trying to achieve but failing I'm new to custom policies, so please correct me if i am doing it a wrong way.编排步骤 6 中的注释部分是我想要实现的,但失败了我是自定义策略的新手,所以如果我做错了,请纠正我。

Found the solution myself.自己找到了解决方案。 We can also use the claim resolver in Output claim as below <OutputClaim ClaimTypeReferenceId="isAccessFlow" DefaultValue="{OAUTH-KV:access_flow}" AlwaysUseDefaultValue="true"/>我们还可以在 Output 声明中使用声明解析器,如下所示<OutputClaim ClaimTypeReferenceId="isAccessFlow" DefaultValue="{OAUTH-KV:access_flow}" AlwaysUseDefaultValue="true"/>

Settings:设置:

  • The IncludeClaimResolvingInClaimsHandling metadata must be set to true. IncludeClaimResolvingInClaimsHandling元数据必须设置为 true。
  • The input or output claims attribute AlwaysUseDefaultValue must be set to true.输入或 output 声明属性AlwaysUseDefaultValue必须设置为 true。

These setting i missed earlier and had to struggle.我之前错过了这些设置,不得不挣扎。 After adding these the below precondition works as expected.添加这些后,以下前提条件按预期工作。

           <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>isAccessFlow</Value>
               <Value>true</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 Azure自定义策略B2C - 业务流程步骤 - Azure Custom Policy B2C - Orchestration step 仅在 Azure B2C 中自定义登录部分用户旅程 - Only customize sign in part of User Journey in Azure B2C azure B2c无缝用户迁移自定义策略错误 - azure B2c Seamless user migration custom policy error 在 Azure AD B2C 中使用自定义策略在注册期间验证和验证用户输入数据 - Validate and Verify the user input data during registration using custom policy in Azure AD B2C Azure B2C手机之旅 - Azure B2C Mobile Journey 如何在Azure B2c中使用IdentityServer3或4作为自定义策略 - How to use IdentityServer3 or 4 in Azure B2c as custom policy 如何编写在添加新用户时触发的 Azure B2C 自定义策略 - How to write an Azure B2C custom policy that triggers when a new user is added Azure AD B2C 自定义策略绕过或跳过特定电话号码编排流程 - Azure AD B2C Custom Policy Bypass or skip specific phone Number Orchestration flow Azure 自定义策略 B2C 如何读取 Azure AD 用户的员工 ID 并使用此值填充文本框 - Azure Custom Policy B2C How I can read the employeeid of an user of Azure AD and populate a textbox with this value Azure B2C 自定义策略,在 Output 声明中添加自定义用户属性 - Azure B2C Custom Policy , Add Custom User Attribute in Output Claims
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM