Выбор решения по управлению удостоверениями

  • Статья

Большинство веб-приложений поддерживают проверку подлинности, чтобы гарантировать, что пользователи являются пользователями, которые они утверждают. Пользователь может быть человеком или другим приложением. Управление доступом гарантирует, что пользователи смогут просматривать и изменять информацию, которую они авторизованы для просмотра и изменения. Например, у конечного пользователя нет доступа к административному разделу веб-сайта. Identity Решения по управлению создаются для обработки требований к задачам проверки подлинности и авторизации. Дополнительные сведения об управлении удостоверениями см. в статье "Что такое управление удостоверениями и доступом?". Многие решения по управлению удостоверениями для веб-приложений .NET доступны, каждый из которых имеет различные возможности и требования для использования или установки. В этой статье приводятся рекомендации по выбору подходящего решения.

Базовое управление удостоверениями с помощью ASP.NET Core Identity

ASP.NET Core поставляется со встроенным поставщиком проверки подлинности: ASP.NET Core Identity. Поставщик включает API, пользовательский интерфейс и конфигурацию серверной базы данных для поддержки управления удостоверениями пользователей, хранения учетных данных пользователя и предоставления или отзыва разрешений. К другим функциям, которые она поддерживает, относятся:

В большинстве случаев это может быть единственным поставщиком.

Чтобы получить дополнительные сведения, обратитесь к разделу

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

Определение необходимости сервера OIDC

Для веб-приложений требуется способ запоминать прошлые действия, так как веб-сайт по умолчанию является без отслеживания состояния. В противном случае пользователи будут вынуждены вводить свои учетные данные при каждом переходе на новую страницу. Общее решение для запоминания состояния — это cookieмеханизм на основе браузера для хранения данных. Веб-сервер отправляет начальный cookie, затем браузер сохраняет его и отправляет его обратно с каждым запросом. Это делается автоматически, не требуя от разработчика написания кода. Cookies легко использовать и встроены в браузер, но предназначены для использования в одном веб-сайте или веб-домене. Решение по умолчанию, встроенное в ASP.NET Core, использует cookieпроверку подлинности на основе.

Маркеры — это контейнеры с метаданными, которые явно передаются через заголовки или текст HTTP-запросов. Основным преимуществом токенов является cookieто, что они не привязаны к конкретному приложению или домену. Вместо этого маркеры обычно подписываются асимметричной криптографией. Например, серверы OIDC выдают маркеры с информацией об удостоверении с помощью JSформата ON Web Token (JWT), который включает подпись. Асимметричная криптография использует сочетание закрытого ключа, известного только подписывательу, и открытый ключ, который может знать каждый. Маркеры также могут быть зашифрованы.

Подписанный маркер нельзя изменить из-за закрытого ключа. Открытый ключ:

  • Позволяет проверить маркер, чтобы убедиться, что он не был изменен.
  • Гарантирует, что она была создана сущностью, владеющей закрытым ключом.

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

Распространенная причина, по которой требуется сервер OIDC, заключается в приложениях, предоставляющих веб-API, которые используются другими приложениями. Для предоставляемых веб-ИНТЕРФЕЙСов API, клиентские интерфейсы, такие как одностраничные приложения (SPA), мобильные клиенты и классические клиенты считаются частью одного приложения. Примеры SPA включают Angular, React и Blazor WebAssembly. Если приложения, отличные от веб-приложения или любого пользовательского интерфейса клиента, должны вызвать безопасный вызов API к приложению, скорее всего, вы захотите использовать маркеры. Если у вас есть только пользовательские интерфейсы клиента, ASP.NET Core Identity предоставляет возможность получения маркера во время проверки подлинности. Маркер проверки подлинности, выданный ASP.NET Core Identity:

  • Может использоваться мобильными и классическими клиентами. Cookieдля обеспечения безопасности и простоты предпочтительнее использовать маркеры.
  • Не подходит для управления доступом из сторонних приложений.

Другая причина, по которой требуется сервер OIDC, заключается в предоставлении общего доступа к входам с другими приложениями. Обычно называется единым входом, эта функция позволяет пользователям:

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

Сервер OIDC обычно предпочтительнее предоставлять безопасное и масштабируемое решение для единого входа.

Для приложений, которые не совместно используют имена входа с другими приложениями, самый простой способ быстро защитить приложение — использовать встроенный поставщик ASP.NET Core Identity . В противном случае требуется сервер OIDC, предоставляемый сторонним решением для управления удостоверениями. Серверы OIDC доступны как:

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

Некоторые решения являются бесплатными и открытый код, а другие коммерчески лицензированы. Сведения о доступных вариантах см . в решениях по управлению удостоверениями. Возможно, ваша организация уже использует поставщика удостоверений. В этом случае может потребоваться использовать существующий поставщик, а не использовать другое решение. Все основные решения предоставляют документацию по настройке ASP.NET Core для использования своего продукта или службы.

Сценарии без подключения к сети

Многие решения, такие как идентификатор Microsoft Entra, основаны на облаке и требуют подключения к Интернету для работы. Если ваша среда не разрешает подключение к Интернету, вы не сможете использовать эту службу.

ASP.NET Core Identity хорошо работает в отключенных сценариях, таких как:

  • Приложение не может получить доступ к Интернету.
  • Приложение должно по-прежнему работать в локальной сети, даже если Интернет отключен.

Если для отключенного сценария требуется полный сервер OIDC, выберите один из следующих вариантов:

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

Определите, где хранятся данные пользователей, такие как входы

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

  • Отвечает за безопасное хранение данных.
  • хранит программное обеспечение в актуальном состоянии с последними исправлениями и выпусками системы безопасности.
  • Соответствует правилам конфиденциальности.

Другие предпочитают хранить данные на своих серверах из-за правил, соответствия, политики или других причин.

Если данные хранятся на серверах, скорее всего, потребуется выбрать устанавливаемое или контейнерное решение.

Identity сервер OIDC

Используйте следующую схему, чтобы решить, следует ли использовать систему ASP.NET Core Identity или сервер OIDC для проверки подлинности и авторизации:

Identity management decision flow

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

Компонент Самостоятельный узел (инфраструктура или контейнер) Облачное хранилище
Интеграция приложений Локальные решения, реализованные как библиотеки или платформы, часто могут быть интегрированы непосредственно в собственное приложение. Решения на основе контейнеров требуют передачи между веб-приложением и службой на основе контейнеров. Облачные решения обычно интегрируются в определенных точках в потоке входа и предоставляют конфигурацию для обновления пользовательского интерфейса в соответствии с темой, но уровень настройки ограничен.
Конфигурация Для самостоятельного размещения решений требуется настройка программного обеспечения для среды в дополнение к настройке способа управления удостоверениями. Решения на основе контейнеров обычно предоставляют веб-пользовательский интерфейс для настройки. Облачные решения обычно предоставляют веб-пользовательский интерфейс для настройки.
Настройка Решения для самостоятельного размещения обычно настраиваются с высокой степенью настройки, включая изменения на основе кода. Хотя контейнерные решения обеспечивают возможности расширяемости, они часто являются более ограниченными. Облачные службы разрешают настройку, но обычно это ограничивается изменениями на основе конфигурации.
Обслуживание Установленные продукты требуют выделенного ресурса, чтобы обеспечить своевременное применение всех исправлений безопасности и управление обновлениями. Процесс обновления и исправления для контейнеров обычно меньше трения и включает в себя просто установку предоставленного образа контейнера. Поставщик услуг поддерживает облачное решение, включая применение необходимых исправлений и обработку обновлений.
Хранилище учетных данных пользователя Вы несете ответственность за управление данными и обработку нарушений. Управление рисками, связанными с обработкой учетных данных пользователей, и соблюдение нормативных требований. делегируется поставщику услуг.

Дополнительные сведения о доступных вариантах см Identity . в решениях по управлению для ASP.NET Core.

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