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

  • Статья

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

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

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

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

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

Параметры RBAC

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

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

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

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

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

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

Когда идентификатор Microsoft Entra выдает маркер доступа для прошедшего проверку подлинности пользователя или приложения, он включает имена ролей, назначенных сущности (пользователю или приложению) в утверждении маркера 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. Приложения должны получать роли, если сведения о роли хранятся в пользовательском хранилище данных. Обычно получение ролей выполняется с помощью точек расширяемости, определенных в ПО промежуточного слоя платформы, которая используется для разработки приложения. За надлежащую защиту пользовательского хранилища данных отвечают разработчики.

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

Выбор метода

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

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

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

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

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