Пользовательская политика Azure B2C - принятие решений по электронной почте для обмена претензиями

Мне нужен приведенный ниже поток для проверки подлинности с помощью настраиваемой политики Azure B2C.

  1. пользователь должен увидеть поле, в котором пользователь вводит свой адрес электронной почты
  2. на основе идентификатора электронной почты (доменного имени) мы решаем, что обмен утверждениями будет аутентифицировать пользователя.
  3. доступный поставщик утверждений - локальная учетная запись, войдите в систему с помощью клиента Azure B2B AD.

Для пункта 2 мы можем проанализировать домен с помощью Анализ преобразования претензий к домену.

Для пункта 3 я уже установил необходимый поставщик утверждений и убедился, что он работает, используя стандартный стартовый пакет «Подписывание с использованием локальных и социальных сетей».


azure azure-ad-b2c identity-experience-framework
person Foramkumar Parekh    schedule 12.08.2020    source источник
comment
Этот пример может помочь: github.com / azure-ad-b2c / samples / tree / master / policy /. Также эта статья: techcommunity.microsoft.com/t5/azure-developer-community-blog/. Ключевое слово - открытие домашнего царства.   -  person juunas    schedule 12.08.2020
comment
@juunas Ссылки были очень полезны для понимания HRD (Home Realm Discovery). Решение показывает использование SAML и ADFS, и мне нужно подключиться с помощью OpenID Connect. Так что решение не сильно помогло.   -  person Foramkumar Parekh    schedule 14.08.2020

Ответы (1)


arrow_upward
2
arrow_downward

Вы можете создать путешествие пользователя, подобное этому.

<OrchestrationSteps>
  <OrchestrationStep Order="1" Type="ClaimsExchange">
    <ClaimsExchanges>
      <ClaimsExchange Id="SelfAsserted-HRD" TechnicalProfileReferenceId="SelfAsserted-HRD" />
    </ClaimsExchanges>
  </OrchestrationStep>
  <OrchestrationStep Order="2" Type="ClaimsExchange">
    <Preconditions>
      <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
        <Value>domainName</Value>
        <Value>contoso.com</Value>
        <Action>SkipThisOrchestrationStep</Action>
      </Precondition>
    </Preconditions>
    <ClaimsExchanges>
      <ClaimsExchange Id="AAD-OIDC" TechnicalProfileReferenceId="AAD-OIDC" />
    </ClaimsExchanges>
  </OrchestrationStep>
  <OrchestrationStep Order="3" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
    <Preconditions>
      <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
        <Value>domainName</Value>
        <Value>contoso.com</Value>
        <Action>SkipThisOrchestrationStep</Action>
      </Precondition>
    </Preconditions>
    <ClaimsProviderSelections>
      <ClaimsProviderSelection ValidationClaimsExchangeId="SelfAsserted-LocalAccountSignin-Email" />
    </ClaimsProviderSelections>
    <ClaimsExchanges>
      <ClaimsExchange Id="SelfAsserted-LocalAccountSignin-Email" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
    </ClaimsExchanges>
  </OrchestrationStep>
  ...
</OrchestrationSteps>

На первых этапах оркестрации выполняется технический профиль SelfAsserted-HRD, в котором можно ввести адрес электронной почты, а затем вызывается преобразование утверждений SetDomainName, которое анализирует сообщение электронной почты. домен.

<ClaimsProvider>
  <DisplayName>Self-Asserted</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SelfAsserted-HRD">
      <DisplayName>Self-Asserted HRD</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
      </Metadata>
      <IncludeInSso>false</IncludeInSso>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" Required="true" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="SetDomainName" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Если домен электронной почты совпадает с федеративным доменом, то на втором этапе оркестрации выполняется технический профиль AAD-OIDC, который перенаправляет внешнего поставщика удостоверений.

Если домен электронной почты не совпадает с федеративным доменом, то на третьем этапе оркестрации выполняется технический профиль SelfAsserted-LocalAccountSignin-Email, который показывает страницу регистрации или входа в локальную учетную запись.

person Chris Padgett    schedule 12.08.2020