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


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

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

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

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

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

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

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

"aud": "e18c04b1-4868-4b93-93d1-8d71f17ab99b", 
"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": "cb7eda1b-d09a-40ae-b8bb-37836ebc6abd",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "833ced3d-cb2e-41ce-92f1-29e2af035ddc", 
"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 и утверждения в маркеры, выберите все группы, как показано в следующем примере экрана утверждения Регистрация приложений | Token configuration | Необязательный экран утверждений "Изменить группы утверждений | ".wids

Снимок экрана: экран

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

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

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

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

В следующем примере маркера для подключения OpenID или OAuth2 веб-токена JSON (JWT) нет groups утверждения, если пользователь является членом слишком много групп. Вместо этого есть _claim_names утверждение, содержащее groups элемент массива.

Снимок экрана: пример маркера с запросом.

В приведенном выше примере маркера видно, что groups утверждение должно быть сопоставлено с src1. В теории, вы будете искать _claim_sources утверждение, а затем найти src1 участника. Оттуда вы найдете запрос Graph, используемый для получения членства в группе. Однако в примере запроса Graph возникает проблема. Он переходит в Azure AD Graph (который майкрософт не рекомендуется), поэтому не используйте его.

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

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

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

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

Снимок экрана: экран

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

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

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

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

Снимок экрана: экран

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

"aud": "acaf6ce9-81f0-462a-a93d-a314070738d3",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "cb7eda1b-d09a-419e-b8bb-37836ebc6abd",
"preferred_username": "[email protected]",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "833ced3d-cb3e-41de-92f1-29e2af035ddc",

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

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

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

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

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

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

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

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