Политика сброса пароля Azure AD B2C без этапа проверки электронной почты

Можно ли создать собственную политику для сброса пароля для уже известного адреса электронной почты?

Я создаю пользователя с помощью Graph API и отправляю письмо с приглашением на указанный адрес электронной почты.

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

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

Но я не могу обойти этап проверки электронной почты в процессе сброса пароля - когда я удаляю его, я получаю ошибку сервера 500 без дополнительных деталей.

Я также пытался отправить objectId для пользователя в качестве входного утверждения, но это тоже не помогает.

Есть ли способ пропустить проверку адреса электронной почты?


person Klio    schedule 19.04.2018    source источник
comment
Не могли бы вы предоставить подробную информацию о том, как вы выполнили этот шаг: я могу создать подписанный токен с этим заявлением по электронной почте и отправить его как утверждение в мою настраиваемую политику. Таким образом, политика получает электронную почту в качестве входной заявки. Я вижу это по следу. Я пытаюсь создать письмо с приглашением со ссылкой для сброса пароля для мигрировавших пользователей, и мне кажется, что я не могу найти информацию о том, как передать адрес электронной почты в настраиваемую политику сброса пароля.   -  person Michael Schulz    schedule 05.11.2018
comment
Моей отправной точкой был этот пример - github.com/Azure-Samples/active-directory-b2c-advanced-policies/. Я отправил электронное письмо с подписанной ссылкой, и когда пользователь щелкнул по этой ссылке, я подтвердил, что она содержит электронную почту и подпись верна. Затем я перенаправился на настраиваемую политику.   -  person Klio    schedule 05.11.2018
comment
В настраиваемой политике я использовал утверждение клиента для отправки токена в B2C, пример можно найти здесь github.com/Azure-Samples/active-directory-b2c-advanced-policies/ в методе RedirectToIdentityProvider.   -  person Klio    schedule 05.11.2018


Ответы (1)


У вас есть следующие варианты, которые изменяют взаимодействие с пользователем:

  1. Отобразите адрес электронной почты как поле, доступное только для чтения, и удалите требование подтверждения адреса электронной почты.
  2. Удалите этап проверки электронной почты.

Отображать адрес электронной почты как поле, доступное только для чтения

1) Создайте readOnlyEmail тип претензии:

<ClaimType Id="readOnlyEmail">
  <DisplayName>Email Address</DisplayName>
  <DataType>string</DataType>
  <UserInputType>Readonly</UserInputType>
</ClaimType>

2) Создайте преобразование утверждений, которое копирует из утверждения email в утверждение readOnlyEmail:

<ClaimsTransformation Id="CopyFromEmailToReadOnlyEmail" TransformationMethod="FormatStringClaim">
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="email" TransformationClaimType="inputClaim" />
  </InputClaims>
  <InputParameters>
    <InputParameter Id="stringFormat" DataType="string" Value="{0}" />
  </InputParameters>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="readOnlyEmail" TransformationClaimType="outputClaim" />
  </OutputClaims>
</ClaimsTransformation>

3) Добавьте преобразование CopyFromEmailToReadOnlyEmail утверждений как преобразование входных утверждений в LocalAccountDiscoveryUsingEmailAddress технический профиль, а затем замените тип утверждения email на readOnlyemail в качестве входных и выходных утверждений для этого технического профиля:

<TechnicalProfile Id="LocalAccountDiscoveryUsingEmailAddress">
  <DisplayName>Reset password using email address</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.localaccountpasswordreset</Item>
  </Metadata>
  <CryptographicKeys>
    <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
  </CryptographicKeys>
  <IncludeInSso>false</IncludeInSso>
  <InputClaimsTransformations>
    <InputClaimsTransformation ReferenceId="CopyFromEmailToReadOnlyEmail" />
  </InputClaimsTransformations>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="readOnlyEmail" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="readOnlyEmail" Required="true" />
    <OutputClaim ClaimTypeReferenceId="objectId" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" />
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingEmailAddress" />
  </ValidationTechnicalProfiles>
</TechnicalProfile>

Удалите этап подтверждения адреса электронной почты

1) Измените первый шаг для PasswordReset путешествия с:

<OrchestrationStep Order="1" Type="ClaimsExchange">
  <ClaimsExchanges>
    <ClaimsExchange Id="PasswordResetUsingEmailAddressExchange" TechnicalProfileReferenceId="LocalAccountDiscoveryUsingEmailAddress" />
  </ClaimsExchanges>
</OrchestrationStep>

to:

<OrchestrationStep Order="1" Type="ClaimsExchange">
  <ClaimsExchanges>
    <ClaimsExchange Id="UserReadUsingEmailAddressExchange" TechnicalProfileReferenceId="AAD-UserReadUsingEmailAddress" />
  </ClaimsExchanges>
</OrchestrationStep>
person Chris Padgett    schedule 19.04.2018
comment
Спасибо, теперь не требуется отправлять проверочный код, но по-прежнему отображается страница для ввода адреса электронной почты. Могу ли я пропустить страницу с вводом адреса электронной почты? - person Klio; 20.04.2018
comment
Я хочу быть уверенным, что почта не изменилась, и это может быть, поэтому пользователь может изменить пароль другого пользователя. Это не то, что я хочу. - person Klio; 21.04.2018
comment
Привет, @Klio, я обновил приведенный выше ответ парой опций, которые зависят от того, хотите ли вы сохранить этап проверки электронной почты или нет. - person Chris Padgett; 21.04.2018
comment
Я как бы сам придумал вариант 1, но вариант 2 с полным удалением ступеней намного лучше! Спасибо, ценю вашу помощь! - person Klio; 21.04.2018
comment
@ChrisPadgett меня интересует вариант 2, но я получаю Claim type "email" is the input claim of technical profile "AAD-UserReadUsingEmailAddress" in step "1" of user journey "PasswordReset" but it is not an output claim in any of the previous steps.Claim type "email" is the output claim of the relying party's technical profile, but it is not an output claim in any of the steps of user journey "PasswordReset". Я использую github.com/Azure-Samples/ в качестве отправной точки для них. любая помощь приветствуется! - person ctoph; 12.07.2019
comment
Привет @ctoph. Вы должны передать email заявку в путешествие пользователя, так как вы не запрашиваете ее, обратитесь к этот образец политики, чтобы узнать, как это сделать. - person Chris Padgett; 17.07.2019