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

Управление доступом на основе ролей для разработчиков приложений

Управление доступом на основе ролей (RBAC) позволяет определенным пользователям или группам иметь определенные разрешения для доступа к ресурсам и управления ими. Приложение RBAC отличается от управления доступом на основе ролей Azure и управления доступом на основе ролей Microsoft Entra. Пользовательские роли Azure и встроенные роли являются частью Azure RBAC, которая используется для управления ресурсами Azure. Microsoft Entra RBAC используется для управления ресурсами Microsoft Entra. В этой статье описывается RBAC для конкретного приложения. Сведения о реализации RBAC для конкретного приложения см. в статье "Как добавить роли приложения в ваше приложение и получать их в маркере".

Определения ролей

RBAC — это популярный механизм для принудительной авторизации в приложениях. Если организация использует RBAC, разработчик приложений определяет роли, а не предоставляет разрешения отдельным пользователям или группам. Затем администратор может назначать роли разным пользователям и группам для управления доступом к содержимому и функциям.

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

Разработчик приложений сначала создает определение роли в разделе регистрации приложения в Центре администрирования Microsoft Entra. Определение роли включает значение, возвращаемое пользователям, которым назначена эта роль. Затем разработчик может использовать это значение для реализации логики приложения, чтобы определить, что эти пользователи могут или не могут сделать в приложении.

Параметры RBAC

При включении авторизации управления доступом на основе ролей в приложении следует применять следующие рекомендации.

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

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

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

Роли приложения

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

Когда Microsoft Entra ID выдает токен доступа для аутентифицированного пользователя или приложения, он включает имена ролей, которые вы назначили сущности (пользователю или приложению), в утверждении токена доступа roles. Приложение, например веб-API, получающее маркер доступа в запросе, может принимать решения об авторизации на основе значений в утверждении roles .

Группы

Разработчики также могут использовать группы Microsoft Entra для реализации RBAC в своих приложениях, где членство пользователя в определенных группах интерпретируется как их членство в роли. Если организация использует группы, маркер включает утверждение групп. Утверждение прав доступа указывает идентификаторы всех назначенных пользователю групп в арендаторе.

Это важно

При работе с группами разработчики должны учитывать концепцию права на превышение. По умолчанию, если пользователь является членом более установленного лимита (150 для токенов SAML, 200 для токенов JWT, 6 при использовании неявного потока), Microsoft Entra ID не выдает заявку о группах в токене. Вместо этого в маркере включено "превышение лимита," указывающее, что пользователь маркера должен обратиться к API Microsoft Graph для получения членства пользователя в группах. Дополнительные сведения о работе с требованиями превышения см. в разделе "Утверждения в маркерах доступа". Можно эмиттировать только группы, назначенные приложению, хотя назначение на основе групп требует редакции Microsoft Entra ID P1 или P2.

Пользовательское хранилище данных

Роли и группы приложений хранят сведения о назначениях пользователей в каталоге Microsoft Entra. Другим вариантом управления сведениями о роли пользователя, доступными для разработчиков, является сохранение информации за пределами каталога в пользовательском хранилище данных. Например, в базе данных SQL, Хранилище таблиц Azure или Azure Cosmos DB для работы с таблицами.

Использование пользовательского хранилища позволяет разработчикам дополнительно настраивать и управлять назначением ролей пользователям и способом их представления. Однако дополнительная гибкость также представляет большую ответственность. Например, в настоящее время нет механизма для включения этой информации в токены, возвращаемые Microsoft Entra ID. Приложения должны получать роли, если сведения о роли хранятся в пользовательском хранилище данных. Получение ролей обычно выполняется с помощью точек расширяемости, определенных в промежуточном ПО, доступного для платформы, используемой для разработки приложения. Разработчики отвечают за правильную защиту пользовательского хранилища данных.

Выбор подхода

Как правило, роли приложений являются рекомендуемым решением. Роли приложений предоставляют простую модель программирования и предназначены для реализации RBAC. Однако конкретные требования к приложениям могут указывать на то, что другой подход будет лучшим решением.

Разработчики могут использовать роли приложений для управления тем, может ли пользователь войти в приложение, или приложение может получить маркер доступа для веб-API. Роли приложений предпочтительнее групп Microsoft Entra разработчиками, когда они хотят описать и контролировать параметры авторизации в своих приложениях. Например, приложение, использующее группы для авторизации, сталкивается с проблемами при работе в следующем арендаторе, так как и идентификатор группы, и её имя могут отличаться. Приложение, использующее роли приложения, остается безопасным.

Хотя роли или группы приложений могут использоваться для авторизации, ключевые различия между ними могут повлиять на то, что является лучшим решением для данного сценария.

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

Дальнейшие шаги

  • Last updated on