Делегирование проверки подлинности внешнему поставщику удостоверений. Это может упростить разработку, свести к минимуму требование для администрирования пользователей и улучшить работу с приложением.
Контекст и проблема
Как правило, пользователи должны работать с несколькими приложениями, предоставленными и размещенными организациями, с которыми они сотрудничают. Этим пользователям может потребоваться использовать конкретные учетные данные (и при этом разные) для каждого приложения. Это может:
Привести к несвязной работе пользователей. Пользователи часто забывают учетные данные для входа, так как их много.
Привести к появлению уязвимостей безопасности. Когда пользователь уходит из компании, учетная запись должна быть немедленно удалена. В крупных организациях этот нюанс упускается.
Усложнить управление пользователями. Администраторы должны управлять учетными данными для всех пользователей и выполнять дополнительные задачи, например запоминать пароль.
Обычно пользователи предпочитают использовать одинаковые учетные данные для всех приложений.
Решение
Реализуйте механизм аутентификации, который может использовать федеративное удостоверение. Отделите аутентификацию пользователей от кода приложения и делегируйте аутентификацию доверенному поставщику удостоверений. Это может упростить разработку и позволить пользователям проходить аутентификацию с использованием различных поставщиков удостоверений, а также свести к минимуму административные издержки. Кроме того, это позволяет четко отделить аутентификацию от авторизации.
Доверенные поставщики удостоверений включают корпоративные каталоги, локальные службы федерации и другие службы токенов безопасности (STS), предоставляемые деловыми партнерами или социальными поставщиками удостоверений, которые могут аутентифицировать пользователей с такими учетными записями, как Microsoft, Google, Yahoo! или Facebook.
На рисунке показан шаблон федеративного удостоверения. Клиентскому приложению нужен доступ к службе, которая запрашивает аутентификацию. Ее выполняет поставщик удостоверений, который работает со службой токенов безопасности. Поставщик удостоверений издает маркеры безопасности, предоставляющие сведения об аутентифицированном пользователе. Эти сведения, называемые утверждениями, включают удостоверение пользователя, а также могут включать другие сведения, такие как членство в роли и более детализированные права доступа.
Эта модель часто называется управлением доступом на основе утверждений. Приложения и службы разрешают получать доступ к функциям и возможностям на основе утверждений, содержащихся в токене. Служба, которая требует аутентификации, должна доверять поставщику удостоверений. Клиентское приложение обращается к поставщику удостоверений, который выполняет аутентификацию. Если аутентификация успешна, поставщик удостоверений возвращает токен, содержащий утверждения, идентифицирующие пользователя в службе маркеров безопасности (обратите внимание, что поставщик удостоверений и служба маркеров безопасности могут быть одной службой). Перед возвращением клиенту служба маркеров безопасности может преобразовывать и дополнять утверждения в маркере на основе стандартных правил. Затем клиентское приложение может передать этот маркер службе как доказательство своей подлинности.
В цепочке доверия могут быть дополнительные службы маркеров безопасности. Например, в описанном далее сценарии отношения доверия существуют между локальной службой токенов безопасности и другой службой, которая отвечает за доступ поставщика удостоверений для аутентификации пользователя. Этот подход часто встречается в корпоративных сценариях при наличии локальной службы токенов безопасности и каталога.
Федеративная аутентификация обеспечивает решение на основе стандартов для доверия идентификаторам в различных доменах. Кроме того, она может поддерживать единый вход. Этот тип проверки подлинности становится все более распространенным для всех типов приложений, особенно облачных приложений, так как он поддерживает единый вход, не требуя прямого сетевого подключения к поставщикам удостоверений. Пользователю не нужно вводить учетные данные для каждого приложения. Это повышает безопасность, так как она предотвращает создание учетных данных, необходимых для доступа ко многим разным приложениям, а также скрывает учетные данные пользователя от всех, кроме исходного поставщика удостоверений. Приложения видят только содержащиеся в маркере сведения об удостоверении, прошедшем аутентификацию.
Федеративные удостоверения также имеют важное преимущество. Оно заключается в том, что именно поставщик удостоверений управляет удостоверениями и учетными данными. Приложению или службе не нужно управлять ими. Кроме того, в корпоративных сценариях каталог организации не должен знать о пользователе, если он доверяет поставщику удостоверений. При этом сокращаются все административные расходы на управление удостоверениями пользователей в каталоге.
Проблемы и рекомендации
При разработке приложения, которое реализует федеративную аутентификацию, необходимо учитывать следующее:
Аутентификация может быть единой точкой отказа. При развертывании приложения в нескольких центрах обработки данных убедитесь, что механизм управления удостоверениями развертывается в одном центре, чтобы поддержать доступность и стабильность приложения.
Инструменты аутентификации позволяют настроить управление доступом на основе утверждений ролей, содержащихся в маркере проверки подлинности. Это часто называется управлением доступом на основе ролей (RBAC) и позволяет более эффективно контролировать доступ к компонентам и ресурсам.
В отличие от каталогов организации аутентификация на основе утверждений, использующая поставщиков удостоверений из социальных сетей, обычно не предоставляет никаких сведений о прошедших аутентификацию пользователях, кроме адреса электронной почты и, может быть, имени. Некоторые поставщики удостоверений из социальных сетей, например из учетной записи Майкрософт, указывают лишь уникальный идентификатор. Обычно приложение должно содержать некоторые сведения о зарегистрированных пользователях и сопоставлять их с идентификатором в утверждениях токена. Это делается путем регистрации после первого доступа к приложению, а затем сведения вставляются в токен в виде дополнительных утверждений после каждой аутентификации.
Если для службы stS настроено несколько поставщиков удостоверений, служба STS должна определить, на какой поставщик удостоверений следует перенаправить пользователя для проверки подлинности. Этот процесс называется обнаружением домашней области. Служба STS может выполнять это автоматически на основе адреса электронной почты или имени пользователя, который предоставляет пользователь, поддомен приложения, к которому обращается пользователь, IP-адрес пользователя область или содержимого файла cookie, хранящегося в браузере пользователя. Например, если пользователь ввел адрес электронной почты в домене корпорации Майкрософт user@live.com, служба токенов безопасности перенаправит его на страницу входа в учетную запись Майкрософт. В следующий раз служба токенов безопасности может использовать файл cookie, чтобы указать, что последний вход был совершен через учетную запись Майкрософт. Если при автоматическом обнаружении домашняя область не определяется, служба токенов безопасности откроет страницу обнаружения домашней области со списком доверенных поставщиков удостоверений, и пользователь должен выбрать одного из них.
Когда следует использовать этот шаблон
Шаблон полезен в следующих случаях:
Единый вход в корпоративное приложение. В этом случае необходимо выполнить аутентификацию сотрудников для корпоративных приложений, размещенных в облаке за пределами периметра безопасности организации. При этом не нужно входить в систему каждый раз при использовании приложения. Взаимодействие с пользователем будет таким же, как при использовании локальных приложений, в которых они проходили аутентификацию после входа в систему в корпоративной сети и получали доступ ко всем соответствующим приложениям без необходимости повторного входа.
Федеративная идентификация с несколькими участниками. В этом случае необходимо выполнить аутентификацию для корпоративных сотрудников и деловых партнеров, не имеющих учетных записей в каталоге организации. Такое часто встречается в бизнес-приложениях, приложениях, которые интегрируются со службами сторонних производителей, а также при слиянии компаний с различными ИТ-системами или при обмене ресурсами.
Федеративная идентификация в приложениях SaaS. В этом случае независимые поставщики программного обеспечения предоставляют готовые к использованию службы нескольким клиентам или арендаторам. Каждый арендатор выполняет аутентификацию с помощью подходящего поставщика удостоверений. Например, бизнес-пользователи будут использовать свои корпоративные учетные данные, а потребители и клиенты арендатора будут использовать свои учетные данные удостоверений из социальных сетей.
Этот шаблон неприменим в следующих случаях:
Один поставщик удостоверений может выполнить аутентификацию для всех пользователей приложения, и не нужно проводить аутентификацию с использованием другого поставщика удостоверений. Такое часто встречается в бизнес-приложениях, которые используют корпоративный каталог (доступный в приложении) для аутентификации с помощью VPN или (в сценарии размещения в облаке) через подключение к виртуальной сети между локальным каталогом и приложением.
Приложение изначально было создано с другим механизмом аутентификации, возможно, с помощью пользовательских хранилищ, или же у него нет возможности для обработки стандартов согласования, используемых технологиями на основе утверждений. Модернизация управления доступом и аутентификации на основе утверждений для имеющихся приложений может быть сложной и, возможно, невыгодной.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон федеративных удостоверений можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:
| Принцип | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя. | Разгрузка управления пользователями и аутентификации перемещает надежность для этих компонентов в поставщик удостоверений, который обычно имеет высокий уровень SLO. Кроме того, во время аварийного восстановления рабочей нагрузки компоненты проверки подлинности, скорее всего, не нужно решать в рамках плана восстановления рабочей нагрузки. - Критически важные потоки RE:02 - Аварийное восстановление RE:09 |
| Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки. | Внедрив управление пользователями и проверку подлинности, вы можете получить новые возможности для обнаружения и предотвращения угроз на основе удостоверений, не требуя реализации этих возможностей в рабочей нагрузке. И внешние поставщики удостоверений используют современные протоколы проверки подлинности взаимодействия. - Жизненный цикл разработки SE:02 Secured - SE:10 Мониторинг и обнаружение угроз |
| Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода. | При разгрузке управления пользователями и проверки подлинности вы можете выделить ресурсы приложения другим приоритетам. - PE:03 Выбор служб |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Пример
Организация размещает мультитенантное программное обеспечение как услуга (SaaS) в Microsoft Azure. Приложение включает веб-сайт, с помощью которого клиенты могут настраивать приложения для пользователей. Приложение позволяет клиентам получать доступ к веб-сайту с помощью федеративного удостоверения, создаваемого службы федерации Active Directory (AD FS) (AD FS), когда пользователь проходит проверку подлинности в собственной организации Active Directory.
На рисунке показано, как клиенты проходят проверку подлинности с помощью собственного поставщика удостоверений (шаг 1), в этом случае AD FS. После успешной проверки подлинности клиента AD FS выдает маркер. Клиентский браузер перенаправит этот маркер поставщику федерации приложения SaaS, который доверяет маркерам, выданным AD FS клиента, чтобы вернуть маркер, действительный для поставщика федерации SaaS (шаг 2). При необходимости перед возвратом нового токена в клиентский браузер федеративный поставщик SaaS выполняет преобразование утверждений в токене в утверждения, которые распознает приложение (шаг 3). Приложение доверяет токенам, выданным федеративным поставщиком SaaS, и использует утверждения в токене для применения правил авторизации (шаг 4).
Клиентам не нужно запоминать отдельные учетные данные для доступа к приложению, а администратор компании клиента может настроить в собственном списке пользователей, которые могут получить доступ к приложению.
Следующие шаги
- Microsoft Entra ID
- Доменные службы Active Directory
- Active Directory Federation Services (Службы федерации Active Directory)
- Мультитенантные приложения Azure