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

Проверка подлинности пользователей для нулевого доверия

Эта статья поможет вам, как разработчику, узнать рекомендации по проверке подлинности пользователей приложений в разработке приложений Zero Trust. Всегда повышайте безопасность приложений с помощью принципов нулевого доверия наименьших привилегий и явным образом проверяйте их.

Идентификационные токены в аутентификации пользователя

Если пользователю требуется пройти проверку подлинности в приложении, а не собирать имя пользователя и пароль, приложение может запросить маркер удостоверения (идентификатора). Проверка подлинности пользователей с помощью платформы удостоверений Майкрософт позволяет избежать рисков безопасности, возникающих при сохранении учетных данных пользователя в приложении. При запросе токенов идентификатора, если злоумышленник взламывает или компрометирует ваше приложение, ваше приложение не содержит имена пользователей и соответствующие пароли.

Токен идентификатора платформы удостоверений Microsoft является частью стандарта OpenID Connect (OIDC), указывающего токены идентификатора в виде JSON веб-токенов (JWT). Длинная строка JWT состоит из трех компонентов:

  1. Утверждения заголовка. Утверждения, присутствующие в заголовке токенов идентификаторов, включают typ (утверждение типа), alg (алгоритм подписания токена) и kid (цифровой отпечаток открытого ключа для проверки подписи токена).
  2. Утверждения полезной нагрузки. Полезные данные или текст (средняя часть веб-токена JSON) содержит ряд пар атрибутов имени. Стандарт требует наличия утверждения с iss именем издателя, которое направляется в приложение, которому был выдан токен (aud, или требование аудитории).
  3. Подпись. Идентификатор Microsoft Entra создает подпись токена, которую приложения могут использовать для проверки того, что токен не изменен, и вы можете доверять безопасности этого токена.

В следующем примере токена идентификатора отображаются сведения о пользователе и подтверждается проверка для доступа к приложению.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[Signature]

Токены идентификации в управлении доступом

Чтобы получить идентификатор приложения (клиента), зарегистрируйте приложение на платформе удостоверений Майкрософт. При получении токена с параметром аудитории (aud), который соответствует идентификатору клиента вашего приложения, данный пользователь в токене прошел аутентификацию в вашем приложении. ИТ-администраторы могут разрешить всем пользователям в клиенте использовать приложение. Они могут разрешить группе, членом которой является пользователь, использовать ваше приложение.

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

Эти сведения о утверждениях важны при проверке подлинности пользователя:

  • Веб-токен JSON действителен до истечения срока его действия. Утверждение exp (срок действия) сообщает вам, когда срок действия маркера истекает. Если текущее время до времени утверждения exp , маркер действителен.
  • Не считайте, что пользователь прошел проверку подлинности до времени, указанного в утверждении nbf (не раньше времени). Временные параметры nbf и exp маркера определяют его допустимое время жизни. Когда срок действия почти истекает, убедитесь, что вы получите новый токен идентификатора.
  • ( sub утверждение субъекта) — это уникальный идентификатор для пользователя приложения. У того же пользователя есть другое sub требование для других приложений. Если вы хотите сохранить данные для связывания с пользователем и запретить злоумышленнику сделать это сопоставление, используйте утверждение субъекта. Так как он не раскрывает идентификацию пользователя в Microsoft Entra, это наиболее конфиденциальный способ ассоциировать данные с пользователем. Утверждение sub неизменяемо.
  • Если вы хотите предоставить общий доступ к данным в нескольких приложениях, используйте сочетание утверждений идентификатора клиента () и идентификатора объекта (tidoid), уникальных для пользователя. Объединенный идентификатор клиента и идентификатор объекта являются неизменяемыми.
  • Независимо от того, что происходит с личностью человека, suboidи tid утверждения остаются неизменяемыми. Что-либо в информации о пользователе может измениться, и вы по-прежнему можете идентифицировать пользователя, используя в качестве ключа данные на основе темы или совмещенных утверждений tid и oid.

Проверка подлинности с помощью OIDC

Чтобы продемонстрировать проверку подлинности пользователей, давайте рассмотрим приложения, использующие OIDC для проверки подлинности пользователя. Те же принципы применяются к приложениям, используюющим язык разметки утверждений безопасности (SAML) или WS-Federation.

Приложение аутентифицирует пользователя, когда приложение запрашивает токен идентификатора из платформы удостоверений Microsoft. Рабочие нагрузки (приложения, которые не имеют пользователей и выполняются как службы, фоновые процессы, демоны) пропускают этот шаг.

Сначала вы всегда должны тихо запрашивать этот токен. Чтобы в фоновом режиме получить токен в библиотеках проверки подлинности Майкрософт (MSAL), ваше приложение может начать с метода AcquireTokenSilent. Если приложение может пройти проверку подлинности, не беспокоя пользователя, оно получает запрошенный токен идентификатора.

Если платформа удостоверений Майкрософт не может завершить запрос без взаимодействия с пользователем, приложение должно вернуться к методу MSALAcquireTokenInteractive. Чтобы интерактивно получить токен, выполните запрос, открыв веб-интерфейс для адреса в домене https://login.microsoftonline.com.

На этом веб-интерфейсе пользователь ведет приватный диалог с платформой идентификации Майкрософт. Ваше приложение не имеет представления об этой беседе, а также не имеет никакого контроля над беседой. Платформа удостоверений Майкрософт может запрашивать идентификатор пользователя и пароль, многофакторную проверку подлинности (MFA), проверку подлинности без пароля или другое взаимодействие с проверкой подлинности, настроенное ИТ-администратором или пользователем.

Приложение получит маркер идентификатора после выполнения пользователем необходимых действий проверки подлинности. Когда ваше приложение получает токен, вы можете быть уверены, что платформа идентификации Microsoft аутентифицировала пользователя. Если ваше приложение не получает токен идентификатора, платформа идентификации Майкрософт не прошла проверку подлинности пользователя. Не разрешайте пользователям, не прошедшим проверку подлинности, продолжать работу в защищенных областях приложения.

Наилучшей практикой является создание сеанса для пользователя после получения токена ID от Microsoft Entra ID. В токене идентификации, который получает приложение, указание срока действия (exp) с меткой времени Unix. Эта метка времени указывает время истечения срока действия, в день или после которого приложение не должно принимать JWT для обработки. Используйте срок действия токена, чтобы определять срок действия сеансов пользователей. Утверждение exp играет важную роль в сохранении явно проверенного пользователя в рамках приложения с правильными привилегиями и в течение необходимого времени.

Поддержка Единого входа в систему (SSO)

Проверка подлинности единого входа позволяет пользователям входить с помощью одного набора учетных данных в несколько независимых программных систем. Единый вход позволяет разработчикам приложений не требовать входа пользователя в каждое приложение отдельно и многократно. В основе единого входа разработчики гарантируют, что все приложения на устройстве пользователя совместно используют веб-интерфейс, который проверяет подлинность пользователя. Артефакты на веб-поверхности (например, состояние сеанса и файлы cookie) после успешной аутентификации управляют SSO.

Как показано на следующей схеме, самый простой вариант использования общей веб-поверхности — это приложение, работающее в веб-браузере (например, Microsoft Edge, Google Chrome, Firefox, Safari). Вкладки браузера используют состояние единого входа.

Схема иллюстрирует сценарий общей веб-поверхности, в котором приложение работает в браузере.

Платформа удостоверений Майкрософт управляет состоянием единого входа в любом определенном браузере, если пользователь не открывает разные браузеры на одном устройстве. В Windows 10 и более поздних версиях платформа удостоверений Microsoft изначально поддерживает единый вход через браузер Microsoft Edge. Когда пользователь выполнил вход в Windows, настройки в Google Chrome (с помощью расширения учетных записей Windows 10) и в Mozilla Firefox v91+ (с помощью параметра браузера) позволяют каждому браузеру совместно использовать состояние единого входа в Windows.

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

Схема иллюстрирует сложный сценарий использования собственного приложения с встраиваемыми браузерами без единого входа.

Подход брокера проверки подлинности

Общей практикой является использование каждым собственным приложением встроенного WebView, что препятствует участию в едином входе. Для решения этого сценария идентификатор Microsoft Entra использует подход брокера проверки подлинности (auth broker) для родных приложений, как показано на следующей схеме.

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

С помощью брокера проверки подлинности приложения отправляют запросы проверки подлинности брокеру, а не непосредственно в платформа удостоверений Майкрософт. Таким образом, брокер становится общей платформой для всех процессов аутентификации на устройстве.

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

По проектированию базовые операционные системы (ОС) изолируют браузеры. Разработчикам требуется более тесное подключение к ОС, чтобы получить полный доступ к сведениям об устройстве. В Windows брокер проверки подлинности — это диспетчер веб-учетных записей Windows (WAM). На других устройствах брокер проверки подлинности — это приложение Microsoft Authenticator (для устройств под управлением iOS или Android) или приложение Корпоративный портал (для устройств под управлением Android). Приложения получают доступ к брокеру проверки подлинности с помощью MSAL. В Windows приложение может получить доступ к WAM без MSAL. Однако MSAL - это самый простой способ доступа к аутентификационному брокеру (особенно для приложений, которые не являются приложениями на платформе Universal Windows Platform).

Брокеры проверки подлинности работают в сочетании с идентификатором Microsoft Entra, чтобы использовать первичные маркеры обновления (PRT), которые снижают потребность пользователей в проверке подлинности несколько раз. PrTs может определить, находится ли пользователь на управляемом устройстве. Microsoft Entra ID требует брокеров проверки подлинности, так как он вводит маркеры проверки владения, более безопасный вариант по сравнению с маркерами носителя, которые распространены сегодня.

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

  • Last updated on