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


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

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

Подготовка к работе

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

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

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

Дополнительные сведения:

Предварительные требования

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

Полное руководство. Создание потоков пользователей и настраиваемых политик в 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 (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

Для работы с этим руководством вы регистрируете https://jwt.msвеб-приложение Майкрософт с декодированного содержимого маркера, которое не покидает ваш браузер.

Регистрация веб-приложения и включение неявного предоставления маркера идентификатора

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

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

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

  1. Войдите в портал Azure в качестве глобального администратора клиента 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. В поле URL-адрес метаданных введите https://authorization.asignio.com/.well-known/openid-configuration.
  13. В поле Идентификатор клиента введите созданный идентификатор клиента.
  14. В поле Секрет клиента введите созданный секрет клиента.
  15. В поле Область используйте профиль электронной почты openid.
  16. В поле Тип ответа используйте код.
  17. В режиме ответа используйте запрос.
  18. Для указания домена используйте https://asignio.com.
  19. Нажмите кнопку ОК.
  20. Выберите Сопоставление утверждений для этого поставщика удостоверений.
  21. В качестве идентификатора пользователя используйте sub.
  22. В поле Отображаемое имя используйте имя.
  23. В поле Заданное имя используйте given_name.
  24. В разделе Фамилия используйте family_name.
  25. Для Email используйте электронную почту.
  26. Щелкните Сохранить.

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

  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, введите запрос на проверку подлинности. В противном случае укажите номер телефона устройства для проверки подлинности с помощью OTP SMS. Используйте ссылку для регистрации подписи 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. В пункте Параметры выберите Manual (Вручную).
  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 именем клиента B2C Azure AD.

  3. Откройте TrustFrameworkExtensions.xmlLocalAccounts/ .

  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">00000000-0000-0000-0000-000000000000</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="22222222-2222-2222-2222-222222222222"></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/11111111-1111-1111-1111-111111111111</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. Откройте TrustFrameworkExtensions.xmlLocalAccounts/ .
  5. Найдите элемент UserJourneys . Если его нет, добавьте его.
  6. Вставьте содержимое элемента UserJourney в качестве дочернего элемента элемента UserJourneys.]
  7. Переименуйте идентификатор пути взаимодействия пользователя. Например, 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 в соответствии с идентификатором пути взаимодействия пользователя, в который добавлен поставщик удостоверений.

В следующем примере в качестве значения параметра ReferenceId пути взаимодействия пользователя AsignioSUSI задано 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 и в разделе Политики выберите Identity Experience Framework.
  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.

Дальнейшие действия