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

• Выполните действия, описанные в статье , чтобы приступить к работе с настраиваемыми политиками в Azure AD B2C.

Шаг 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 в качестве поставщика удостоверений

Чтобы пользователи могли войти в систему с помощью 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.