Возможно, вы смешиваете две совершенно разные концепции.Ниже я приведу некоторые подробности относительно каждого из них, и затем вы сможете решить, действительно ли вам нужны групповые заявки для вашего приложения или нет.
Я предполагаю, что вы заинтересованы в заявке на роль, поэтому вам не нужно обновлять манифест приложения, чтобы включить "groupMembershipClaims": "SecurityGroup", но вы - лучший судья для требований вашего приложения.
Роли приложения
Вы можете определить роли приложения, отредактировав манифест приложения и добавив appRoles.Теперь вы можете назначать эти роли отдельным пользователям или даже группам Azure AD.
Назначение ролей отдельным пользователям
Вы можете назначать роли отдельным пользователям, перейдя в Enterprise.Приложения, а затем с помощью пользовательского интерфейса портала.Похоже, вы уже сделали это для своего приложения.Когда пользователь входит в ваше приложение, токен входящего доступа содержит утверждения о ролях для пользователя.например, "roles": ["MyAppCustomRole1"]
Назначение ролей группам Azure AD
Вы можете назначить роль приложения группе Azure AD (если у вас есть Azure AD Premium).Это может быть удобно, особенно когда имеешь дело с большим количеством пользователей.Таким образом, вам не нужно назначать appRole отдельным пользователям, но вы можете выполнять массовое назначение в силу членства в их группах.
Если это то, что вы хотите сделать, вам не нужно обновлять свойманифест приложения, включающий "groupMembershipClaims": "SecurityGroup"
Пример кода - Авторизация в веб-приложении с использованием ролей приложений Azure и утверждений о ролях
Документы Microsoft - Роли приложений
Групповые заявки
Вы можете включить групповые заявки в качестве маркера доступа для вашего приложения, отредактировав манифест вашего приложения.(это можно сделать непосредственно на портале Azure) и для свойства "groupMembershipClaims" установить значение "All" или "SecurityGroup", если необходимо.
После обновления манифеста приложения, как уже упоминалось, вы можете получить идентификаторы группы как часть утверждений.,Вот быстрый пример для декодированного токена JWT.Обратите внимание, что это совершенно другое утверждение по сравнению с утверждением о ролях, объясненным ранее.
Пример кода - Авторизация в веб-приложении с использованием групп и утверждений Azure AD
Groups v / s Roles
Следует понимать, что группы Azure AD и их членство полностью отделены от любого отдельного приложения.
Срок службы группы AD Azure также может отличаться, т. Е. Группа может продолжать существовать в течение длительного времени после удаления приложения или более не нужна.
Роли приложения, с другой стороны, очень тесно связаны с одним конкретным приложением.
Для некоторых приложений стратегия авторизации заключается в проверке членства пользователя в группе вместо конкретной роли приложения.Я также видел случаи, когда приложения принимают решения об авторизации на основе комбинации определенной роли приложения и групп, к которым принадлежит пользователь.
С другой стороны, чтобы гарантировать, что размер токена не будетпревышая ограничения размера заголовка HTTP, Azure AD ограничивает число идентификаторов объектов, включаемых в утверждение групп.Если пользователь является участником большего числа групп, чем предел превышения (150 для токенов SAML, 200 для токенов JWT), то Azure AD не отправляет утверждение группы в токене.Вместо этого он включает избыточное требование в токене, указывающее приложению запросить Graph API для получения членства в группе пользователя.
Другие связанные сообщения SO: