Настройка Asignio с помощью Azure Active Directory B2C для многофакторной проверки подлинности

Это важно

Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".

Узнайте, как интегрировать проверку подлинности Microsoft Entra ID (Azure AD B2C) с Asignio. С помощью этой интеграции предоставьте клиентам возможность без пароля, обратимой биометрии и многофакторной проверки подлинности. Asignio использует патентованную подпись Asignio и динамическую проверку лица для проверки подлинности пользователей. Изменяемая биометрическая подпись помогает снизить проблемы, связанные с паролями, мошенничеством, фишингом и повторным использованием учетных данных, с помощью омниканальной аутентификации.

Перед тем как начать

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

  • Предопределенные потоки пользователей
  • Настраиваемые политики

Действия, описанные в этой статье, отличаются для каждого метода.

Подробнее:

Предпосылки

  • Подписка Azure.

  • Если у вас нет учетной записи, получите бесплатный аккаунт Azure.

  • Клиент Azure AD B2C, связанный с подпиской Azure

  • См. руководство. Создание клиента Azure Active Directory B2C

  • Идентификатор клиента Asignio и секрет клиента, выданный Asignio.

  • Эти маркеры получаются путем регистрации мобильных или веб-приложений в Asignio.

Для пользовательских политик

Полное руководство. Создание потоков пользователей и пользовательских политик в Azure AD B2C

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

Эта интеграция включает следующие компоненты:

  • Azure AD B2C — сервер авторизации, проверяющий учетные данные пользователя
  • Веб-приложения или мобильные приложения — для защиты с помощью Asignio MFA
  • Веб-приложение Asignio — сигнатурная биометрия на пользовательском сенсорном устройстве

На следующей схеме показана реализация.

Схема, показывающая архитектуру реализации.

  1. Пользователь открывает страницу входа Azure AD B2C на своем мобильном или веб-приложении, а затем входит или регистрируется.
  2. Azure AD B2C перенаправляет пользователя в Asignio с помощью запроса OpenID Connect (OIDC).
  3. Пользователь перенаправляется в веб-приложение Asignio для биометрического входа. Если пользователь не зарегистрировал свою подпись Asignio, он может использовать SMS One-Time-Password (OTP) для аутентификации. После проверки подлинности пользователь получает ссылку на регистрацию, чтобы создать подпись Asignio.
  4. Пользователь проходит проверку подлинности с помощью подписи Asignio и проверки лица, а также голосовой и лицевой проверки.
  5. Ответ на вызов отправляется в Asignio.
  6. Asignio возвращает ответ на запрос OIDC при входе в Azure AD B2C.
  7. Azure AD B2C отправляет запрос проверки подлинности в Asignio, чтобы подтвердить получение данных проверки подлинности.
  8. Пользователю предоставлен или запрещен доступ к приложению.

Настройка приложения с помощью Asignio

Настройка приложения с помощью Asignio осуществляется через сайт администрирования партнеров Asignio.

  1. Чтобы запросить доступ к вашей организации, перейдите на страницу asignio.com Администрирование партнеров Asignio .
  2. С помощью учетных данных войдите в Администрирование партнеров Asignio.
  3. Создайте запись для приложения Azure AD B2C с помощью клиента Azure AD B2C. При использовании Azure AD B2C с Asignio Azure AD B2C управляет подключенными приложениями. Приложения Asignio представляют приложения на портале Azure.
  4. На сайте администрирования партнеров Asignio создайте идентификатор клиента и секрет клиента.
  5. Запишите и сохраните идентификатор клиента и секрет клиента. Они понадобятся вам позже. Asignio не хранит секреты клиента.
  6. Введите универсальный код ресурса (URI перенаправления) на сайте, к который пользователь возвращается после проверки подлинности. Используйте следующий шаблон URI.

[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp].

  1. Отправьте логотип компании. Он появляется при аутентификации Asignio, когда пользователи входят в систему.

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

Зарегистрируйте приложения в управляемом клиенте, а затем они могут взаимодействовать с Azure AD B2C.

Дополнительные сведения: типы приложений, которые можно использовать в Active Directory B2C

В этом руководстве вы регистрируете веб-приложение Microsofthttps://jwt.ms, содержимое декодированного токена которого не покидает браузер.

Регистрация веб-приложения

Выполните действия, описанные в руководстве. Регистрация веб-приложения в статье Azure Active Directory B2C .

Настройка Asignio в качестве поставщика удостоверений в Azure AD B2C

Для выполнения следующих инструкций используйте клиент Microsoft Entra с подпиской Azure.

  1. Войдите в портал Azure в качестве по крайней мере администратора политики B2C IEF клиента Azure AD B2C.
  2. На панели инструментов портала Azure выберите каталоги и подписки.
  3. Параметры портала | Каталоги + подписки в списке имен каталогов найдите каталог Microsoft Entra.
  4. Выберите Переключиться.
  5. В левом верхнем углу портала Azure выберите все службы.
  6. Найдите и выберите Azure AD B2C.
  7. В портале Azure найдите и выберите Azure AD B2C.
  8. В меню слева выберите поставщики удостоверений.
  9. Выберите новый поставщик OpenID Connect.
  10. Выберите тип >OpenID Connect.
  11. В поле "Имя" введите вход Asignio или имя, выбранное вами.
  12. Введите https://authorization.asignio.com/.well-known/openid-configuration.
  13. Для идентификатора клиента введите созданный идентификатор клиента.
  14. В поле "Секрет клиента" введите созданный секрет клиента.
  15. Для Scope используйте openid email profile.
  16. Для типа ответа используйте код.
  17. Для режима ответа используйте запрос.
  18. Для указания домена используйте https://asignio.com.
  19. Нажмите ОК.
  20. Выберите "Сопоставить утверждения этого поставщика удостоверений".
  21. Для идентификатора пользователя используйте sub.
  22. Для отображаемого имени используйте имя.
  23. Для заданного имени используйте given_name.
  24. Для фамилии используйте family_name.
  25. Для Email используйте электронную почту.
  26. Нажмите кнопку "Сохранить".

Создание политики потока пользователя

  1. В клиенте Azure AD B2C в разделе "Политики" выберите потоки пользователей.
  2. Выберите новый поток пользователя.
  3. Выберите "Регистрация и вход в тип потока пользователя".
  4. Выберите рекомендуемую версию.
  5. Нажмите кнопку "Создать".
  6. Введите имя потока пользователя, например AsignioSignupSignin.
  7. В разделе "Поставщики удостоверений" для локальных учетных записей выберите "Нет". Это действие отключает проверку подлинности электронной почты и пароля.
  8. Для пользовательских поставщиков удостоверений выберите созданного поставщика удостоверений Asignio.
  9. Нажмите кнопку "Создать".

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

  1. В клиенте Azure AD B2C выберите потоки пользователей.
  2. Выберите созданный поток пользователя.
  3. Для приложения выберите зарегистрированное веб-приложение. URL-адрес ответа .https://jwt.ms
  4. Выберите Запустить пользовательский сценарий.
  5. Браузер перенаправляется на страницу входа Asignio.
  6. Появится экран входа.
  7. Внизу выберите аутентификацию Asignio.

Если у вас есть подпись Asignio, выполните запрос на проверку подлинности. В противном случае укажите номер телефона устройства для проверки подлинности через SMS OTP. Используйте ссылку для регистрации подписи Asignio.

  1. Браузер перенаправляется в https://jwt.ms. Отображается содержимое токена, возвращаемое Azure AD B2C.

Создайте ключ политики Asignio

  1. Сохраните созданный секрет клиента в клиенте Azure AD B2C.
  2. Войдите на портал Azure.
  3. На панели инструментов портала выберите каталоги и подписки.
  4. Параметры портала | Каталоги + подписки в списке имен каталогов найдите каталог Azure AD B2C.
  5. Выберите Переключиться.
  6. В левом верхнем углу портала Azure выберите все службы.
  7. Найдите и выберите Azure AD B2C.
  8. На странице "Обзор" выберите Identity Experience Framework.
  9. Выберите Ключи политики.
  10. Нажмите кнопку "Добавить".
  11. В разделе "Параметры" выберите "Вручную".
  12. Введите имя для ключа политики. Префикс B2C_1A_ добавляется к имени ключа.
  13. Секрет, введите секрет клиента, который вы указали.
  14. Для назначения ключа выберите Подпись.
  15. Нажмите кнопку "Создать".

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

Подсказка

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

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

Добавить Asignio в качестве поставщика утверждений

Получите начальные пакеты настраиваемой политики из GitHub, а затем обновите XML-файлы в начальном пакете LocalAccounts с именем клиента Azure AD B2C:

  1. Скачайте zip active-directory-b2c-custom-policy-starterpack или клонируйте репозиторий:

        git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack

  2. В файлах в каталоге LocalAccounts замените строку yourtenant именем клиента Azure AD B2C.

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

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

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

     <ClaimsProvider>
   <Domain>contoso.com</Domain>
   <DisplayName>Asignio</DisplayName>
   <TechnicalProfiles>
     <TechnicalProfile Id="Asignio-Oauth2">
       <DisplayName>Asignio</DisplayName>
       <Description>Login with your Asignio account</Description>
       <Protocol Name="OAuth2" />
       <Metadata>
         <Item Key="ProviderName">authorization.asignio.com</Item>
         <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>
         <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>
         <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>
         <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>
         <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
         <Item Key="HttpBinding">POST</Item>
         <Item Key="scope">openid profile email</Item>
         <Item Key="UsePolicyInRedirectUri">0</Item>
         <!-- Update the Client ID below to the Asignio Application ID -->
         <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
         <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>


         <!-- trying to add additional claim-->
         <!--Insert b2c-extensions-app application ID here, for example: 00001111-aaaa-2222-bbbb-3333cccc4444-->
         <Item Key="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
         <!--Insert b2c-extensions-app application ObjectId here, for example: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb-->
         <Item Key="aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"></Item>
         <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
         <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/00001111-aaaa-2222-bbbb-3333cccc4444</Item>-->
         <!-- The commented key below 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>
         <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
       </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://authorization.asignio.com" />
         <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
         <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
         <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
         <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
         <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
       </OutputClaims>
       <OutputClaimsTransformations>
         <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
         <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
         <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
         <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
       </OutputClaimsTransformations>
       <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
     </TechnicalProfile>
   </TechnicalProfiles>
 </ClaimsProvider>

  6. Задайте client_id с указанным идентификатором приложения Asignio.

  7. Обновите раздел client_secret с помощью созданного ключа политики. Например, B2C_1A_AsignioSecret:

    <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />

  8. Сохраните изменения.

Добавить пользовательский сценарий

Провайдер удостоверений отсутствует на страницах входа.

  1. Если у вас есть настраиваемый путь пользователя, продолжайте к настройке политики проверяющей стороны, в противном случае скопируйте шаблон пути пользователя.
  2. В начальном пакете откройте LocalAccounts/TrustFrameworkBase.xml.
  3. Найдите и скопируйте содержимое элемента UserJourney , который включает Id=SignUpOrSignIn.
  4. Откройте LocalAccounts/TrustFrameworkExtensions.xml.
  5. Найдите элемент UserJourneys . Если его нет, добавьте его.
  6. Вставьте содержимое элемента UserJourney в качестве дочернего элемента UserJourneys.]
  7. Переименуйте путь пользователя ID. Например: Id=AsignioSUSI.

Дополнительные сведения: пути взаимодействия пользователей

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

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

  1. Найдите элемент шага оркестрации, который включает в себя Type=CombinedSignInAndSignUp или Type=ClaimsProviderSelection в процессе работы пользователя. Обычно это первый шаг оркестрации. Элемент ClaimsProviderSelections содержит список поставщиков удостоверений, через которых пользователи входят в систему. Порядок элементов определяет порядок кнопок входа.
  2. Добавьте XML-элемент ClaimsProviderSelection .
  3. Задайте для параметра TargetClaimsExchangeId понятное имя.
  4. Добавьте элемент ClaimsExchange .
  5. Установите идентификатор в значение целевого идентификатора обмена заявками.
  6. Обновите значение TechnicalProfileReferenceId на идентификатор технического профиля, который вы создали.

Следующий XML-код демонстрирует оркестрацию взаимодействия пользователей с поставщиком удостоверений.

    <UserJourney Id="AsignioSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />
            <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="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />
            <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 (i.e. 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>

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

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

  1. В доверяющей стороне найдите элемент DefaultUserJourney.
  2. Обновите ReferenceId, чтобы он соответствовал идентификатору пути пользователя, где вы добавили провайдера идентификации.

В следующем примере для AsignioSUSI пути пользователя для параметра ReferenceId задано значение AsignioSUSI:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="AsignioSUSI" />
        <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>

Отправка настраиваемой политики

  1. Войдите на портал Azure.
  2. На панели инструментов портала выберите каталоги и подписки.
  3. Параметры портала | Каталоги + подписки в списке имен каталогов найдите каталог Azure AD B2C.
  4. Выберите Переключиться.
  5. В портале Azure найдите и выберите Azure AD B2C.
  6. В разделе "Политики" выберите Identity Experience Framework.
  7. Выберите "Отправить настраиваемую политику".
  8. Отправьте два файла политики, которые вы изменили в следующем порядке:
  • Политика расширения — например TrustFrameworkExtensions.xml
  • Политика проверяющей стороны, например SignUpOrSignin.xml

Проверка настраиваемой политики

  1. В клиенте Azure AD B2C и в разделе "Политики" выберите "Платформа взаимодействия с удостоверениями".
  2. В разделе "Пользовательские политики" выберите AsignioSUSI.
  3. Для приложения выберите зарегистрированное веб-приложение. URL-адрес ответа .https://jwt.ms
  4. Выберите Запустить немедленно.
  5. Браузер перенаправляется на страницу входа Asignio.
  6. Появится экран входа.
  7. Внизу выберите аутентификацию Asignio.

Если у вас есть подпись Asignio, вам будет предложено пройти проверку подлинности с помощью подписи Asignio. В противном случае укажите номер телефона устройства для проверки подлинности через SMS OTP. Используйте ссылку для регистрации подписи Asignio.

  1. Браузер перенаправляется в https://jwt.ms. Отображается содержимое токена, возвращаемое Azure AD B2C.

Дальнейшие шаги

  • Last updated on