Поделиться через


Настройка Облака проверки подлинности Trusona с помощью Azure Active Directory B2C

В этом примере руководства вы узнаете, как интегрировать проверку подлинности Azure AD B2C с Облаком Trusona Authentication Cloud. Это облачная служба, которая позволяет пользователям проходить проверку подлинности с помощью интерфейса tap-and-go без необходимости в любом мобильном приложении для проверки подлинности.

Преимущества интеграции Trusona Authentication Cloud с Azure AD B2C:

  • Предоставление надежной проверки подлинности с помощью лучшего взаимодействия с пользователем

    • Счастливые пользователи, которые тратят больше в Интернете
    • Снижение и отказы, увеличение доходов
    • Более высокое хранение, время существования (LTV)
  • Снижение затрат на выполнение бизнеса

    • Сокращение отработки учетных записей и общий доступ к учетной записи
    • Снижение мошенничества и уменьшение количества действий по анализу мошенничества вручную
    • Сокращение расходов на аутсорсинг ручной проверки
  • Устранение паролей

    • Больше нет сброса пароля
    • Сокращение жалоб на центр обработки вызовов
    • Быстрые, простые, без проблем имена входа с помощью секретных ключей

Необходимые компоненты

Для начала работы необходимы перечисленные ниже компоненты и данные.

Описание сценария

Стандарт веб-проверки подлинности — WebAuthn реализует современные операционные системы и браузеры для поддержки проверки подлинности с помощью печати пальцев, Windows hello или внешних устройств FIDO, таких как USB, Bluetooth и OTP.

В этом сценарии Trusona выступает в качестве поставщика удостоверений (IdP) для Azure AD B2C, чтобы включить проверку подлинности без пароля. Это решение включает следующие компоненты:

  • Объединенная политика входа и регистрации Azure AD B2C.
  • Trusona Authentication Cloud добавлен в Azure AD B2C в качестве поставщика удостоверений.

Screenshot shows Trusona architecture diagram.

Шаги Description
1. Пользователь пытается войти в веб-приложение через браузер.
2. Веб-приложение перенаправляется в политику регистрации и входа в Azure AD B2C.
3. Azure AD B2C перенаправляет пользователя для проверки подлинности в поставщик удостоверений Trusona Authentication Cloud OpenID Подключение (OIDC).
4. Пользователь отображает веб-страницу входа, которая запрашивает имя пользователя— обычно адрес электронной почты.
5. Пользователь вводит свой адрес электронной почты и нажимает кнопку "Продолжить ". Если учетная запись пользователя не найдена в облаке Trusona Authentication Cloud, то ответ отправляется в браузер, который инициирует процесс регистрации WebAuthn на устройстве. В противном случае ответ отправляется в браузер, который начинает процесс проверки подлинности WebAuthn.
6. Пользователю предлагается выбрать учетные данные для использования. Ключ доступа связан с доменом веб-приложения или аппаратным ключом безопасности. После выбора учетных данных ОС запросит пользователя использовать биография метрию, секретный код или ПИН-код для подтверждения удостоверения. Это разблокирует среду безопасного анклава или доверенного выполнения, которая создает утверждение проверки подлинности, подписанное закрытым ключом, связанным с выбранными учетными данными.
7. Утверждение проверки подлинности возвращается в облачную службу Trusona для проверки.
8. После проверки Облако проверки подлинности Trusona Authentication Cloud (IdP) создает маркер идентификатора OIDC, а затем перенаправит его в Azure AD B2C (поставщик услуг). Azure AD B2C проверяет подпись маркера и издателя по значениям в документе обнаружения OpenID Trusona. Эти сведения были настроены во время установки поставщика удостоверений. После проверки Azure AD B2C выдает id_token OIDC (в зависимости от область) и перенаправляет пользователя обратно в приложение, инициирующее маркер.
9. Веб-приложение (или библиотеки разработчиков, которые он использует для реализации проверки подлинности), извлекает маркер и проверяет подлинность маркера Azure AD B2C. Если это так, он извлекает утверждения и передает их в веб-приложение для использования.
10. При проверке пользователь получает или запрещает доступ.

Шаг 1. Подключение с облаком Trusona Authentication Cloud

  1. Войдите на портал Trusona.

  2. На панели навигации слева выберите Параметры

  3. В меню Параметры выберите ползунок, чтобы включить OIDC.

  4. Выберите соответствующие входные данные и укажите URL-адресhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp перенаправления.

  5. Создайте секретный ключ и скопируйте ключ для использования в настройке Azure AD B2C.

    Примечание.

    1. Портал Trusona поддерживает самостоятельную регистрацию. После регистрации вы будете назначены учетной записи Trusona с правами только для чтения. После этого Trusona назначит вам правильную учетную запись и повышает ваши права на чтение и запись на основе политики контроля доступа вашей организации для пользователей портала.
    2. Начальное доменное имя идентификатора Microsoft Entra используется в качестве узла перенаправления клиента.

    Screenshot shows Trusona Authentication Cloud portal settings.

Шаг 2. Регистрация веб-приложения в Azure AD B2C

Прежде чем приложения смогут взаимодействовать с Azure AD B2C, они должны быть зарегистрированы в клиенте клиента. В этом руководстве показано, как зарегистрировать веб-приложение с помощью портал Azure. В целях тестирования (например, при выполнении задач этого руководства), вы регистрируете https://jwt.ms. Это веб-приложение Майкрософт, которое отображает декодированное содержимое маркера (содержимое маркера никогда не покидает браузер). Чтобы зарегистрировать веб-приложение в клиенте Azure AD B2C, используйте новый единый интерфейс регистрации приложений.

  1. Войдите на портал Azure.

  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.

  3. В портале Azure найдите и выберите Azure AD B2C.

  4. Щелкните Регистрация приложений и выберите Новая регистрация.

  5. Введите имя приложения. Например, jwt ms.

  6. В области Поддерживаемые типы учетных записей выберите Учетные записи в любом поставщике удостоверений или в организационном каталоге (для аутентификации пользователей с помощью потока пользователей).

  7. В поле URI перенаправления выберите Интернет и введите https://jwt.ms в текстовое поле URL.

    URI перенаправления — это конечная точка, в которую сервер авторизации, Azure AD B2C в этом случае отправляет пользователя. После завершения взаимодействия с пользователем маркер доступа или код авторизации отправляется после успешной авторизации. В рабочем приложении обычно это общедоступная конечная точка, в которой работает приложение, например https://contoso.com/auth-response. В целях тестирования, таких как этот учебник, можно задать для него значение https://jwt.ms, веб-приложение Майкрософт, которое отображает декодированное содержимое маркера (содержимое маркера никогда не покидает браузер). Во время разработки приложения можно добавить конечную точку, в которой приложение будет ожидать передачи данных локально, например https://localhost:5000. URI перенаправления в зарегистрированных приложениях можно добавлять и изменять в любое время.

    На URI перенаправления налагаются следующие ограничения.

    • URL-адрес ответа должен начинаться со схемы https, если вы не используете URL-адрес перенаправления localhost.
    • В URL-адресе ответа учитывается регистр. Его регистр должен соответствовать регистру URL-пути выполняющегося приложения. Например, если в состав пути приложения входит .../abc/response-oidc, не указывайте .../ABC/response-oidc в URL-адресе ответа. Так как веб-браузер обрабатывает пути с учетом регистра, файлы cookie, связанные с .../abc/response-oidc, могут быть исключены при перенаправлении на не совпадающий по регистру знаков URL-адрес .../ABC/response-oidc.
    • URL-адрес ответа может включать или не включать наклонную черту в конце в зависимости от того, ожидает ли ее приложение. Например, https://contoso.com/auth-response и https://contoso.com/auth-response/ можно рассматривать как несоответствующие URL-адреса в приложении.
  8. В разделе Разрешения установите флажок Предоставьте согласие администратора для разрешений openid и offline_access.

  9. Выберите Зарегистрировать.

Включение неявного предоставления разрешения для маркера идентификации

Если вы регистрируете это приложение и настраиваете его в приложении https://jwt.ms/ для тестирования пользовательского потока или настраиваемой политики, необходимо включить поток неявного предоставления разрешения в регистрации приложения:

  1. В меню слева в разделе Управлениевыберите Проверка подлинности.

  2. В разделе "Неявное предоставление и гибридные потоки" выберите маркеры идентификатора (используемые для неявных и гибридных потоков) проверка поля.

  3. Выберите Сохранить.

Шаг 3. Настройка облака Trusona Authentication в качестве поставщика удостоверений в Azure AD B2C

  1. Войдите на портал Azure с правами глобального администратора клиента Azure AD B2C.

  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.

  3. Выберите Все службы в левом верхнем углу окна портала Azure, найдите службу Azure AD B2C и выберите ее.

  4. Перейдите в раздел Информационная панель>Azure Active Directory B2C>Поставщики удостоверений.

  5. Выберите Поставщики удостоверений.

  6. Выберите Добавить.

Настройка поставщика удостоверений

  1. Выберите Тип поставщика удостоверений>OpenID Connect (предварительная версия).

  2. Заполните форму для настройки поставщика удостоверений:

    Свойство Значение
    URL-адрес метаданных https://authcloud.trusona.net/.well-known/openid-configuration
    ИД клиента доступно на облачном портале Trusona Authentication Cloud
    Секрет клиента доступно на облачном портале Trusona Authentication Cloud
    Область действия OpenID, профиль, адрес электронной почты
    Тип ответа кодом
    Режим ответа form_post
  3. Нажмите ОК.

  4. Выберите Сопоставление утверждений для этого поставщика удостоверений.

  5. Заполните форму для сопоставления поставщика удостоверений:

    Свойство Значение
    UserID дочерний объект
    Отображаемое имя псевдоним
    Имя given_name
    Surname family_name
    Режим ответа эл. почта
  6. Нажмите кнопку "ОК ", чтобы завершить настройку нового поставщика OIDC.

Шаг 4. Создание политики потока пользователей

Теперь вы увидите Trusona как новый поставщик удостоверений OpenID Подключение, указанный в поставщиках удостоверений B2C.

  1. В клиенте Azure AD B2C, в разделе Политики выберите Потоки пользователей.

  2. Выберите Создать поток пользователя.

  3. Выберите Регистрация и вход, выберите версию и нажмите кнопку Cоздать.

  4. Введите Имя для политики.

  5. В разделе "Поставщики удостоверений" выберите только что созданный поставщик удостоверений Trusona Authentication Cloud-Identity.

    Примечание.

    Поскольку Trusona в принципе подразумевает многофакторность, лучше оставить многофакторную проверку подлинности отключенной.

  6. Выберите Создать.

  7. В разделе Атрибуты пользователя и утверждения нажмите Показать еще. В форме выберите по меньшей мере один атрибут, указанный во время установки поставщика удостоверений в предыдущем разделе.

  8. Нажмите ОК.

Шаг 5. Тестирование потока пользователя

  1. Выберите созданную политику.

  2. Нажмите Выполнить поток пользователя и выберите параметры:

    a. Приложение: выберите зарегистрированное приложение, например jwt ms.

    b. URL-адрес ответа: выберите URL-адрес перенаправления, например https://jwt.ms.

  3. Выберите Выполнить поток пользователя. Вы должны быть перенаправлены в облако Trusona Authentication Cloud. Пользователь отображает веб-страницу входа, которая запрашивает имя пользователя— обычно адрес электронной почты. Если учетная запись пользователя не найдена в Trusona Authentication Cloud, то ответ отправляется в браузер, который инициирует процесс регистрации WebAuthn на устройстве. В противном случае ответ отправляется в браузер, который начинает процесс проверки подлинности WebAuthn. Пользователю предлагается выбрать учетные данные для использования. Ключ доступа связан с доменом веб-приложения или аппаратным ключом безопасности. После выбора учетных данных ОС запросит пользователя использовать биография метрию, секретный код или ПИН-код для подтверждения удостоверения. Это разблокирует среду безопасного анклава или доверенного выполнения, которая создает утверждение проверки подлинности, подписанное закрытым ключом, связанным с выбранными учетными данными. Azure AD B2C проверяет ответ проверки подлинности Trusona и выдает токен OIDC. Он перенаправляет пользователя обратно в инициирующее приложение, например, которое отображает содержимое маркера, https://jwt.msвозвращаемого Azure AD B2C.

Шаг 3. Создание ключа облачной политики Trusona Authentication

Сохраните секрет клиента, который был создан в арендаторе Azure AD B2C на шаге 1 ранее.

  1. Войдите на портал Azure.

  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.

  3. Выберите Все службы в левом верхнем углу окна портала Azure, а затем найдите и выберите Azure AD B2C.

  4. На странице "Обзор" выберите Identity Experience Framework.

  5. Выберите Ключи политики, а затем щелкните Добавить.

  6. Для пункта Параметры выберите Вручную.

  7. Введите имя ключа политики. Например, TrusonaTacClientSecret. Префикс B2C_1A_ будет автоматически добавлен к имени ключа.

  8. В поле Секрет введите ранее записанный секрет клиента.

  9. Для параметра Использование ключа выберите Signature.

  10. Выберите Создать.

Шаг 4. Настройка облака Trusona Authentication в качестве поставщика удостоверений

Совет

На этом этапе должна быть настроена политика Azure AD B2C. Если это не так, выполните инструкции по настройке арендатора Azure AD B2C и настройке политик.

Чтобы пользователи могли войти в систему с помощью Trusona Authentication Cloud, необходимо определить Trusona в качестве поставщика утверждений, с которым Azure AD B2C может взаимодействовать через конечную точку. Конечная точка предоставляет набор утверждений, которые используются Azure AD B2C для проверки подлинности конкретного пользователя с помощью секретного ключа или аппаратного ключа безопасности, доступного на своем устройстве, подтверждения удостоверения пользователя.

Чтобы добавить Trusona в качестве поставщика утверждений, выполните следующие действия.

  1. Скачайте начальные пакеты настраиваемых политик из GitHub, а затем обновите XML-файлы в начальном пакете LocalAccounts, указав имя своего арендатора Azure AD B2C:

    1. Скачайте ZIP-файл или клонируйте репозиторий:

          git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
      
    2. Во всех файлах в каталоге LocalAccounts замените строку yourtenant именем своего клиента Azure AD B2C. Например, если имя вашего клиента B2C — contoso, все экземпляры yourtenant.onmicrosoft.com должны иметь вид contoso.onmicrosoft.com.

  2. Откройте LocalAccounts/TrustFrameworkExtensions.xml.

  3. Найдите элемент ClaimsProviders. Если он не существует, добавьте его в корневой элемент TrustFrameworkPolicy.

  4. Добавьте новый ClaimsProvider , аналогичный приведенному ниже:

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</Item>
        <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
        <!-- trying to add additional claim-->
        <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
        <!-- The commented key specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to sign in. -->
        <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>

      </Metadata>
      <CryptographicKeys>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </CryptographicKeys>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>
  1. Задайте client_id с идентификатором облачного приложения Trusona Authentication, который вы ранее записали на шаге 1.

  2. Обновите раздел client_secret с именем ключа политики, созданного на шаге 3. Например, B2C_1A_TrusonaTacClientSecret:

    <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
    
  3. Сохраните изменения.

Шаг 5. Добавление пути взаимодействия пользователя

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

  1. Откройте файл LocalAccounts/TrustFrameworkBase.xml из стартового пакета.

  2. Найдите и скопируйте все содержимое элемента UserJourney, в котором присутствует запись Id=SignUpOrSignIn.

  3. Откройте LocalAccounts/TrustFrameworkExtensions.xml и найдите элемент UserJourneys. Если элемент не существует, добавьте его.

  4. Вставьте все скопированное содержимое элемента UserJourney в качестве дочернего элемента в элемент UserJourneys.

  5. Переименуйте Id пути взаимодействия пользователя. Например, Id=TrusonaTacSUSI.

Шаг 6. Добавление поставщика удостоверений в путешествие пользователя

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

  1. В пути взаимодействия пользователя найдите элемент шага оркестрации, включающий Type=CombinedSignInAndSignUp или Type=ClaimsProviderSelection. Обычно это первый шаг оркестрации. Элемент ClaimsProviderSelections содержит список поставщиков удостоверений, которые пользователь может использовать для входа. Порядок элементов управляет порядком кнопок входа, представленных пользователем. Добавьте XML-элемент ClaimsProviderSelection. Присвойте значению TargetClaimsExchangeId понятное имя, например TrusonaTacExchange.

  2. На следующем шаге оркестрации добавьте элемент ClaimsExchange. В качестве идентификатора укажите целевое значение идентификатора обмена запросами. Обновите значение параметра TechnicalProfileReferenceId, указав идентификатор технического профиля, созданного при добавлении поставщика утверждений, например TrusonaTAC-OpenIdConnect.

В следующем коде XML показаны этапы оркестрации пути взаимодействия пользователя с поставщиком удостоверений:

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <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="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <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 (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>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

См. дополнительные сведения о путях взаимодействия пользователя.

Шаг 7. Настройка политики проверяющей стороны

Политика проверяющей стороны, например SignUpSignIn.xml, указывает путь пользователя, который выполняет Azure AD B2C. Найдите элемент DefaultUserJourney для проверяющей стороны. Обновите ReferenceId в соответствии с идентификатором пути взаимодействия пользователя, в который добавлен поставщик удостоверений.

В следующем примере в качестве значения параметра ReferenceId пути взаимодействия пользователя Trusona Authentication Cloud задано TrusonaTacSUSI:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" />
            <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

Шаг 8. Отправка настраиваемой политики

  1. Войдите на портал Azure.

  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.

  3. На портале Azure найдите и выберите Azure AD B2C.

  4. В разделе "Политики" выберите Identity Experience Framework.

  5. Выберите Отправить пользовательскую политику, а затем отправьте два измененных файла политики в следующем порядке: политика расширения, например TrustFrameworkExtensions.xml, а затем политика проверяющей стороны, например SignUpOrSignin.xml.

Шаг 9. Проверка настраиваемой политики

  1. В клиенте Azure AD B2C в разделе "Политики" выберите Identity Experience Framework.

  2. В разделе "Пользовательские политики" выберите TrusonaTacSUSI.

  3. В поле Приложение выберите веб-приложение, которое было зарегистрировано ранее при выполнении предварительных требований в этой статье. например jwt ms. В поле URL-адрес ответа должно содержаться значение https://jwt.ms.

  4. Выберите Запустить сейчас. Браузер должен быть перенаправлен на страницу входа Trusona Authentication Cloud.

  5. Отображается экран входа; В нижней части экрана должна быть кнопка, чтобы использовать облачную проверку подлинности Trusona Authentication Cloud .

  6. Вы должны быть перенаправлены в облако Trusona Authentication Cloud. Пользователь отображает веб-страницу входа, которая запрашивает имя пользователя— обычно адрес электронной почты. Если учетная запись пользователя не найдена в облаке Trusona Authentication Cloud, то ответ отправляется в браузер, который инициирует процесс регистрации WebAuthn на устройстве. В противном случае ответ отправляется в браузер, который начинает процесс проверки подлинности WebAuthn. Пользователю предлагается выбрать учетные данные для использования. Ключ доступа связан с доменом веб-приложения или аппаратным ключом безопасности. После выбора учетных данных ОС запросит пользователя использовать биография метрию, секретный код или ПИН-код для подтверждения удостоверения. Это разблокирует среду безопасного анклава или доверенного выполнения, которая создает утверждение проверки подлинности, подписанное закрытым ключом, связанным с выбранными учетными данными.

  7. Если вход выполнен успешно, в браузере откроется страница https://jwt.ms с содержимым маркера, возвращенного Azure AD B2C.

Следующие шаги

Дополнительные сведения см. в следующих статьях: