Настроить утверждения группы и роли приложения в токенах

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

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

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

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

• Группы, которые определяются атрибутом идентификатора объекта (OID) Microsoft Entra.
• Группы, определяемые атрибутами sAMAccountName или GroupSID для групп и пользователей, синхронизированных с Active Directory.

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

"aud": "00001111-aaaa-2222-bbbb-3333cccc4444", 
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0", 
"iat": 1669657224, "nbf": 1669657224, "exp": 1669661124, 
"groups": [ 
   "0760b6cf-170e-4a14-91b3-4b78e0739963", 
   "3b2b0c93-acd8-4208-8eba-7a48db1cd4c0" 
 ],
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

Массив groups утверждений состоит из идентификаторов групп, в которые входит этот пользователь. Массив wids содержит идентификаторы ролей Microsoft Entra, назначенных этому пользователю. Здесь показано, cf1c38e5-3621-4004-a7cb-879624dced7c, что назначенные роли этого пользователя включают разработчика приложений и стандартного участника, как указано в 3b2b0c93-acd8-4208-8eba-7a48db1cd4c0.

Ваше приложение может принимать решения о авторизации на основе наличия или отсутствия этих утверждений и их значений. См. встроенные роли Microsoft Entra для списка значений утверждения wids.

Чтобы добавить утверждения groups и wids в ваши маркеры, выберите Все группы, как показано в следующем примере экрана Регистрации приложений, | , Необязательные утверждения, | .

Переборы групп

При запросе всех групп в маркере, как показано в примере, нельзя полагаться на маркер, имеющий groups утверждение в маркере. Существуют ограничения размера токенов и groups утверждений, чтобы они не стали слишком большими. Если пользователь является членом слишком большого количества групп, ваше приложение должно получить членство в группе пользователя из Microsoft Graph. Ограничения для групп в претензии groups.

• 200 групп для веб-токенов JSON (JWT).
• 150 групп для токенов языка разметки утверждений безопасности (SAML).
• Шесть групп при использовании неявного потока (например, с помощью ASP.NET Core, получающего идентификационные токены через неявную часть гибридного потока).
  • Неявный поток больше не рекомендуется для одностраничных веб-приложений.
  • Неявный поток можно использовать в веб-приложениях только для токена идентификации, а никогда для токена доступа, в гибридном потоке OAuth2.

Если вы используете OpenID Connect или OAuth2, в токене может быть до 200 групп. Если вы используете SAML, у вас может быть только 150 групп, так как токены SAML больше, чем токены OAuth2 и OpenID Connect. Если вы используете неявный поток, ограничение составляет шесть, так как эти ответы отображаются в URL-адресе. Во всех этих случаях вместо groups утверждения отображается указание (известное как перебор по группам), указывающее, что пользователь является членом слишком большого количества групп, чтобы поместиться в токен.

Неявное указание перебора потока выполняется с помощью hasgroups вместо groups.

Чтобы обеспечить правильную авторизацию с помощью членства в группах, убедитесь, что приложение проверяет наличие groups утверждения. При наличии используйте это утверждение для определения членства в группе пользователя. Если нет утверждения groups, проверьте, существует ли утверждение hasgroups или утверждение _claim_names с элементом groups массива. Если какое-либо из этих утверждений присутствует, пользователь является членом слишком большого количества групп для маркера. В этом случае приложение должно использовать Microsoft Graph для определения членства в группе для пользователя. Просмотрите список членства пользователя (прямой и транзитивной), чтобы найти все группы, как прямые, так и транзитивные, из которых пользователь является членом.

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

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

При выборе Группы, назначенные приложению, группа включается в groups утверждение, если выполняются следующие условия:

• Группа прикреплена к приложению для предприятий
• пользователь является прямым членом группы

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

Группы и роли приложения

Другим способом избежать проблемы превышения лимита группы является для приложения определение ролей приложения, позволяющих пользователям и группам быть типами участников. Как показано в следующем примере на экране Регистрации приложений | Роли приложений | Создать роль приложения, выберите Пользователи/Группы для разрешенных типов участников.

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

"aud": "11112222-bbbb-3333-cccc-4444dddd5555",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"preferred_username": "[email protected]",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "ccccdddd-2222-eeee-3333-ffff4444aaaa",

Помните, что ваше приложение должно обрабатывать следующие условия:

• roles отсутствие претензии
• пользователь не имеет назначения ролей
• несколько значений в утверждении roles , если у пользователя несколько назначений ролей

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

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

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

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

При определении ролей приложений для приложения необходимо реализовать логику авторизации для этих ролей. Сведения о том, как реализовать логику авторизации в приложениях, см. в статье "Реализация управления доступом на основе ролей в приложениях".

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

• Настройка токенов описывает информацию, которую можно получить в Microsoft Entra токенах. В нем объясняется, как настроить маркеры для повышения гибкости и контроля при увеличении безопасности приложений Zero Trust с минимальными привилегиями.
• В статье "Настройка утверждений группы для приложений с помощью Microsoft Entra ID" показывается, как Microsoft Entra ID может предоставлять сведения о членстве пользователя в группах в токенах для использования в приложениях.
• Рекомендации по безопасности для свойств приложения описывают URI перенаправления, маркеры доступа (используемые для неявных потоков), сертификаты и секреты, URI идентификатора приложения и владение приложением.
• Области применения платформы идентификации Майкрософт, разрешения и согласие объясняют основные концепции доступа и авторизации, что помогает создавать более безопасные и надежные приложения.
• Используйте лучшие практики разработки удостоверений и управления доступом в модели Zero Trust в жизненном цикле разработки приложений для создания безопасных приложений.