Назначение разрешений приложений пользователям/группам и другим участникам в Entra ID
У меня есть две пары «приложение и принципал» в Entra ID. Одно из моих приложений предоставляет несколько ролей: некоторые предназначены для пользователей и групп, а другие предназначены только для приложений.
Когда я назначаю пользователей и группы, я имею полный контроль над этим, если я владею субъектом-службой, который предоставляет роли:
Однако, когда я хочу предоставить разрешение другому субъекту-службе, мне нужен глобальный администратор (или меньше?), чтобы утвердить это разрешение:
Такое поведение является препятствием для всех, кто работает с разрешениями приложений. Почему я, владелец как приложений, так и субъектов служб, участвующих в выдаче разрешения, не решаю, можно ли это одобрить или нет? Это означает, что любой может запросить роли для моих API, а затем кто-то одобрит это без моего ведома. Если бы у меня было приложение, раскрывающее эту роль, я бы предположил, что я буду тем, кто его одобрит.
Я понимаю, что это настройка арендатора, и у меня нет к ней доступа в клиенте, откуда взяты снимки экрана. Однако у меня есть собственный арендатор, где я могу экспериментировать, но я совершенно не уверен, что ищу.
Меня главным образом интересует, как мне по этому поводу рассуждать.
Есть ли способы улучшить этот рабочий процесс для разработчиков?
Какие настройки мне нужны?
Почему это так работает для директоров? Я предполагаю, что для этого есть веская причина, просто я ее не понимаю.
Ответы 1
Обратите внимание: для предоставления согласия администратора на разрешения API, добавленные в приложение Microsoft Entra ID, требуется роль администратора привилегированной роли, администратора облачного приложения или администратора приложения. Обратитесь сюда MsDoc
- Если вы являетесь владельцем субъекта-службы, у вас есть возможность назначать роли непосредственно пользователям и группам, не требуя дополнительного утверждения.
- Это связано с тем, что роли пользователей обычно не требуют повышенных разрешений или широких областей доступа и, следовательно, не представляют значительного риска для безопасности. Этот уровень контроля прост и позволяет эффективно и результативно управлять ролями пользователей.
- Но чтобы предоставить согласие администратора, вам потребуется любая повышенная роль, как уже упоминалось.
Если вы хотите, чтобы пользователи отправляли запрос на одобрение, попробуйте сделать следующее:
Перейдите на Портал Azure -> Корпоративные приложения -> Согласие и разрешения -> Установить, что пользователи могут запрашивать согласие администратора для приложений, на которые они не могут дать согласие, как ДА и добавьте пользователя, который может утвердить запрос.
Я создал приложение Microsoft Entra ID и добавил роль приложения:
В качестве примера для авторизации пользователей использовалась указанная ниже конечная точка.
https://login.microsoftonline.com/TenantID/oauth2/v2.0/authorize?
&client_id=ClientID
&response_type=code
&redirect_uri=redirectURL
&response_mode=query
&scope=scope
&state=12345
Когда я попытался войти в систему, пользователь получил экран «Требуется одобрение», как показано ниже:
Рецензент должен иметь как минимум роль администратора облака, чтобы одобрить запрос:
Перейдите в «Корпоративные приложения» -> «Активность» -> «Выберите запросы на согласие администратора» -> вкладка «Мои ожидающие».
Нажмите «Просмотреть разрешения и согласие» и утвердите запрос.
Теперь я вошел в систему под тем же пользователем, и пользователь может успешно войти в систему:
- Разрешения приложения часто предоставляют широкий доступ к API и данным внутри клиента.
- Следовательно, для разрешений приложений необходимо согласие администратора, чтобы гарантировать наличие процесса проверки и утверждения запрашиваемого доступа.
- Это помогает гарантировать, что доступ необходим и уместен, и что только авторизованные приложения/пользователи имеют доступ к запрошенным ресурсам.
Ссылка:
Но все равно требуется согласие администратора
Так что, по сути, это мера безопасности, не имеющая обходных путей. Я просто нахожу это немного странным, потому что человек, рассматривающий запрос, не обязательно знает, к чему приведет его одобрение. Специально для ролей, созданных разработчиками приложения.
Да, ты прав. Вы также можете назначить роль администратора облака для утверждения запросов, если это возможно в вашей среде.
> Разрешения приложения часто предоставляют широкий доступ к API и данным внутри клиента. Я понимаю, будут ли это разрешения графа или что-то еще, не предоставляемое одноарендным приложением. Но моя роль с таким же успехом может быть применима к приложениям, пользователям и группам.