Правильное использование групп Azure AD для управления разрешениями

Question

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

Теперь вопрос заключается в том, как правильно управлять группами в Azure AD. Когда пользователи назначаются в группу, они становятся членами этой группы, и любые группы, в которые эта группа вложена. Похоже, это означает, что вложение моей группы должно быть противоположным древовидной структуре, которую я хотел бы. Примерно так:

Администратор -> член -> Группа с наибольшим доступом -> член -> группа с меньшим доступом -> член -> группа с наименьшим доступом.

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

Я здесь далеко от базы или это разумный способ управления правами доступа с группами AD?

Answer 1

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

1. Являются ли группы специфичными для вашего приложения или более общего назначения?Членство в группах и вложенные группы обычно используются для логической / интуитивной организации пользователей и групп, а не для разработки разрешений для конкретного приложения

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

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

   Пример 1: ваше приложение является приложением для ведения блогов, а группы, которые вы создаете в Azure AD, являются Viewer, Участник и админ.(Admin> Contributor> Viewer) Пример 2. У вас есть предприятие, использующее Azure AD, и группы логически организовывают пользователей, скажем, с отделом маркетинга, персонала, инженерии и т. Д.

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

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

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

   На мой взгляд, вы можете смотреть как на плоскую, так и на другую.Тед групп ... если это имеет смысл с точки зрения организации пользователей и групп, а не только прав доступа.Другой вымышленный пример: Marketing Группа может иметь группу участников, такую ​​как Marketing Content Approvers, потому что это подмножество маркетологов.

2. Учитывайте Роли приложения .

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

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

3. Управление группами (как вы спрашивали об этом в комментариях)

   Взгляните на Сценарии управления группами самообслуживания (делегированные v / s самообслуживания), а также динамические группы для правил динамического членства, основанных на атрибутах (хотя требуется лицензия Premium).

Answer 2

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

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

Пусть мы назовем три группы A, B, C, их разрешение A> B> C. Очевидно, что если вы добавите A к B, разрешения A и B не будут затронуты. Но если вы добавите B к A, члены A или B оба будут иметь самое большое разрешение, это не то, что вы хотите. То же самое с B и C. Вот почему он обеспечивает правильные права доступа для пользователей, добавленных в каждую группу, как вы сказали.

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