Этап B2C- оркестровки пользовательской политики Azure

#azure #azure-ad-b2c #orchestration

#azure #azure-ad-b2c #согласование

Вопрос:

Я хотел знать, как мы можем написать политику, чтобы показывать пользователю кнопку регистрации, которая может перенаправить его на другой экран для регистрации, используя адрес электронной почты. Я написал пользовательскую политику, которая работает с пользователем с учетной записью в Active directory. Для этого первый шаг оркестровки позволяет пользователю войти в систему с помощью электронной почты. Шаг возвращается с сообщением, если пользователь не найден.

После этого я пытаюсь написать второй шаг оркестровки, который должен выполняться, только если пользователь не был найден на предыдущем шаге оркестровки.

 <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
                <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
  

Шаг не выполняется даже после того, как я получаю сообщение о том, что пользователь не найден. Как я могу заставить это работать. Я бы предпочел, чтобы пользователю была показана кнопка регистрации на том же экране.

Есть идеи?

Обновление: у меня такое ощущение, что альтернативный поток невозможности найти пользователя должен обрабатываться в TechnicalProfile, а не на этапе оркестровки.

Ответ №1:

Вы пытаетесь отобразить экран входа, на котором есть ссылка «Регистрация», позволяющая пользователю зарегистрироваться с помощью SerlfAssertedAttributeProvider? Если да, то вот как это делается в стартовом пакете LocalAccounts (скопировано из TrustFrameworkBase.xml ):

     <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
      <ClaimsProviderSelections>
        <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
      </ClaimsProviderSelections>
      <ClaimsExchanges>
        <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <OrchestrationStep Order="2" Type="ClaimsExchange">
      <Preconditions>
        <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
          <Value>objectId</Value>
          <Action>SkipThisOrchestrationStep</Action>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
      </ClaimsExchanges>
    </OrchestrationStep>
  

Комментарии:

1. Спасибо за ваш ответ. Я уже просматривал ссылки, которые вы предоставили, перед публикацией здесь. Я написал свое решение для пользовательской политики, используя <ValidationTechnicalProfiles>

2. Пока вы не предоставите более подробную информацию, помочь невозможно. Например, как выглядит ваш UJ, какие профили проверки используются и т.д. Каково ожидаемое поведение и что является фактическим, то есть Разница между тем, что вы хотите, и тем, что вы получаете. Тогда проще предложить ответ.