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

Руководство по настройке TypingDNA с Azure Active Directory B2C

  • Статья

В этом пошаговом руководстве объясняется, как интегрировать приложения для электронных платежей в Azure Active Directory B2C (Azure AD B2C) с приложением TypingDNA. С помощью приложения TypingDNA, клиенты Azure AD B2C могут соблюдать требования транзакций PSD2 (директивы служб оплаты 2), используя динамику нажатия клавиш и надежную проверку подлинности клиента. Дополнительные сведения о TypingDNA см. здесь.

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

Примечание.

Этот пример политики основан на начальном пакете SocialAndLocalAccountsWithMfa.

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

Снимок экрана: схема архитектуры TypingDNA

Регистрация

  1. На страницах Azure AD B2C используется библиотека JavaScript TypingDNA для записи шаблона ввода пользователя. Например, имя пользователя и пароль записываются для первоначальной регистрации, а затем при каждом входе в систему для проверки.

  2. Когда пользователь отправляет данные со страницы, библиотека TypingDNA вычисляет характеристики ввода пользователя. После этого сведения вставляются в скрытое текстовое поле, предоставленное Azure AD B2C. Это поле скрыто с помощью CSS.

    Пример содержит HTML-файлы с изменениями JavaScript и CSS, на которые ссылаются определения содержимого api.selfasserted.tdnasignin и api.selfasserted.tdnasignup. Сведения о размещении HTML-файлов см. в разделе "Размещение содержимого страницы" этой статьи.

  3. Теперь у Azure AD B2C есть шаблон ввода в контейнере утверждений, когда пользователь отправляет свои учетные данные. Он должен вызвать ваш API для передачи этих данных в конечную точку REST API TypingDNA. Этот API включен в пример (typingDNA-API-Interface).

  4. Затем API среднего уровня передает данные шаблона ввода в REST API TypingDNA. При регистрации вызывается конечная точка проверки пользователя, чтобы подтвердить, что пользователь не существовал, а затем вызывается конечная точка сохранения шаблона, чтобы сохранить первый шаблон ввода пользователя.

Примечание.

При каждом вызове конечной точки REST API отправляется UserId. Это должно быть хэшированное значение. Azure AD B2C использует преобразование утверждений HashObjectIdWithEmail для хэширования сообщения электронной почты с использованием случайных данных и секрета.

Вызовы REST API моделируются с помощью validationTechnicalProfiles в LocalAccountSignUpWithLogonEmail-TDNA:


<ValidationTechnicalProfiles>

    <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail-TDNA" />
    <ValidationTechnicalProfile ReferenceId="REST-TDNA-CheckUser" ContinueOnError="true"/>

    <ValidationTechnicalProfile ReferenceId="REST-TDNA-SaveUser"/>

</ValidationTechnicalProfiles>

Вход

При последующем входе пользовательский шаблон ввода будет вычисляться точно так же, как при регистрации с помощью пользовательского HTML-кода. После размещения профиля ввода в контейнере утверждений Azure AD B2C вызывает API, чтобы вызвать конечную точку REST API TypingDNA. Для подтверждения существования пользователя вызывается конечная точка проверки пользователя. Затем вызывается конечная точка проверки шаблона, которая возвращает значение net_score. Значение net_score показывает, насколько шаблон ввода похож на первоначальный шаблон в момент регистрации.

Этот шаблон ввода моделируется с помощью validationTechnicalProfiles в SelfAsserted-LocalAccountSignin-Email-TDNA:


<ValidationTechnicalProfiles>

    <ValidationTechnicalProfile ReferenceId="login-NonInteractive"/>

    <ValidationTechnicalProfile ReferenceId="REST-TDNA-CheckUser" ContinueOnError="false"/>

    <ValidationTechnicalProfile ReferenceId="REST-TDNA-VerifyUser"/>

    <ValidationTechnicalProfile ReferenceId="REST-TDNA-SaveUser">

        <Preconditions>

            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">

            <Value>saveTypingPattern</Value>

            <Value>False</Value>

            <Action>SkipThisValidationTechnicalProfile</Action>

            </Precondition>

        </Preconditions>

    </ValidationTechnicalProfile>

</ValidationTechnicalProfiles>

Если пользователь получает шаблон ввода с высоким значением net_score, его можно сохранить с помощью конечной точки сохранения шаблона ввода TypingDNA.

Ваш API должен вернуть утверждение saveTypingPattern, если вы хотите вызвать в Azure AD B2C (через API) конечную точку сохранения шаблона ввода TypingDNA.

Пример в репозитории содержит API (TypingDNA-API-Interface), настроенный с помощью следующих свойств.

  • Режим обучения. Если у пользователя менее двух сохраненных шаблонов, всегда запрашивается многофакторная проверка подлинности.

  • Если у пользователя от 2 до 5 сохраненных шаблонов, и значение net_score меньше 50, запрашивается многофакторная проверка подлинности.

  • Если у пользователя более 5 сохраненных шаблонов, и значение net_score меньше 65, запрашивается многофакторная проверка подлинности.

Эти пороговые значения следует скорректировать в зависимости от варианта использования.

  • После того, как ваш API оценит net_score, он должен вернуть логическое утверждение службе B2C (promptMFA).

  • Утверждение promptMFA используется в предварительном условии для условного выполнения многофакторной проверки подлинности Microsoft Entra.


<OrchestrationStep Order="3" Type="ClaimsExchange">

    <Preconditions>

        <Precondition Type="ClaimsExist" ExecuteActionsIf="true">

            <Value>isActiveMFASession</Value>

            <Action>SkipThisOrchestrationStep</Action>

        </Precondition>

        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">

            <Value>promptMFA</Value>

            <Value>False</Value>

            <Action>SkipThisOrchestrationStep</Action>

        </Precondition>

    </Preconditions>

    <ClaimsExchanges>

        <ClaimsExchange Id="PhoneFactor-Verify" TechnicalProfileReferenceId="PhoneFactor-InputOrVerify" />

    </ClaimsExchanges>

</OrchestrationStep>

Подключение с помощью TypingDNA

  1. Зарегистрируйтесь в TypingDNA здесь.
  2. Войдите на панель мониторинга TypingDNA и получите ключ API и секрет API. Они потребуются позже для настройки интерфейса API.

Интеграция TypingDNA с Azure AD B2C

  1. Разместите TypingDNA-API-Interface у предпочитаемого поставщика услуг размещения.

  2. Замените все экземпляры apiKey и apiSecret в решении TypingDNA-API-Interface на учетные данные из панели мониторинга TypingDNA.

  3. Разместите HTML-файлы у предпочитаемого поставщика услуг, следуя требованиям CORS, указанные здесь.

  4. Замените элементы LoadURI для определений содержимого api.selfasserted.tdnasignup и api.selfasserted.tdnasignin в TrustFrameworkExtensions.xml файле на URI соответствующих размещенных HTML-файлов.

  5. Создайте ключ политики B2C в рамках платформы удостоверений в колонке Microsoft Entra в портал Azure. Используйте параметр Generate и присвойте этому ключу имя tdnaHashedId.

  6. Замените TenantId в файлах политики.

  7. Замените ServiceURLs во всех технических профилях REST API TypingDNA (REST-TDNA-VerifyUser, REST-TDNA-SaveUser, REST-TDNA-CheckUser) на конечную точку для TypingDNA-API-Interface API.

  8. Отправьте файлы политики в клиент.

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

  1. Откройте клиент B2C и выберите Identity Experience Framework.

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

  3. Выберите Выполнить поток пользователя.

    a. Приложение. Выберите зарегистрированное приложение (пример — JWT).

    b. URL-адрес ответа. Выберите URL-адрес перенаправления.

    c. Выберите Выполнить поток пользователя.

  4. Выполните поток регистрации и создайте учетную запись.

  5. Выйти

  6. Выполните поток входа.

  7. В результате JWT отобразятся результаты TypingDNA.

Активная версия

• В тестовой версии многофакторная проверка подлинности отключена, но можно узнать, была бы вызвана многофакторная проверка подлинности утверждением promptMFA после проверки подлинности.

• Зарегистрируйтесь здесь и войдите здесь.

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

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