Взаимодействие с согласием для приложений в идентификаторе Microsoft Entra
Из этой статьи вы узнаете о пользовательском интерфейсе согласия приложения Microsoft Entra. Вы можете интеллектуально управлять приложениями для вашей организации и (или) разрабатывать приложения с более простым интерфейсом предоставления согласия.
Согласие — это процесс предоставления пользователем разрешения приложению получать доступ к защищенным ресурсам от имени пользователя. Администратор или пользователь могут получать запрос на разрешение доступа к рабочим или личным данным.
Фактический пользовательский интерфейс предоставления согласия отличается в зависимости от политик, заданных в клиенте пользователя, области полномочий пользователя (или роли) и типа разрешений, запрошенных клиентским приложением. Это означает, что разработчики приложений и администраторы клиентов имеют определенный уровень контроля над процедурой получения согласия. Администраторы имеют гибкие возможности настройки и отключения политик клиента или приложения для управления процедурой предоставления согласия в своих клиентах. Разработчики приложений могут жестко указывать, какие разрешения будут запрошены и хотят ли они выполнить процесс предоставления согласия пользователя или администратора.
- Процесс предоставления согласия пользователем. Разработчик приложения направляет пользователей к конечной точке авторизации с целью зафиксировать согласие только для текущего пользователя.
- Процесс предоставления согласия администратором. Разработчик приложения направляет пользователей к конечной точке авторизации администратора с целью зафиксировать согласие для всего клиента. Для правильной работы процесса предоставления согласия администратора разработчик приложений должен перечислить все разрешения в свойстве
RequiredResourceAccess
манифеста приложения. Дополнительные сведения см. в статье Манифест приложения Azure Active Directory.
Запрос на согласие разработан таким образом, чтобы убедиться, что пользователи имели всю необходимую информацию для определения того, достаточно ли они доверяют клиентскому приложению для доступа к защищенным ресурсам от их имени. Общие сведения о стандартных блоках помогают пользователям предоставлять согласие принимать более обоснованные решения и помогает разработчикам создавать лучшие возможности для пользователей.
Следующие схема и таблица содержат сведения о стандартных блоках запросов на согласие.
# | Компонент | Характер использования |
---|---|---|
1 | Идентификатор пользователя | Этот идентификатор представляет пользователя, у которого клиентское приложение запрашивает доступ к защищенным ресурсам от имени пользователя. |
2 | Заголовок | Заголовок изменяется в зависимости от того, выполняется ли процесс предоставления согласия пользователя или администратора. В потоке согласия пользователя заголовок — "Запрошенные разрешения", а в потоке согласия администратора заголовок имеет другую строку "Принять для вашей организации". |
3 | Логотип приложения | Изображение должно помочь пользователям убедиться, что это именно то приложение, которому они хотят предоставить доступ. Это изображение предоставляется разработчиками приложения, и владелец этого изображение не проверяется. |
4 | Название приложения | Это значение должно проинформировать пользователей о том, какое приложение запрашивает доступ к данным пользователей. Обратите внимание, что это имя предоставляется разработчиками приложения, и владелец этого имени не проверяется. |
5 | Имя и проверка издателя | Синий значок "Проверено" означает, что издатель приложения подтвердил удостоверение с помощью учетной записи Microsoft Partner Network и завершил процесс проверки. Если издатель приложения проверен, отображается имя издателя. Если приложение не проверено, вместо имени издателя отображается значение Unverified. Дополнительные сведения приведены в статье Проверка издателя. При выборе имени издателя отображаются дополнительные сведения о приложении, такие как имя издателя, домен издателя, дата создания, сведения о сертификации и URL-адреса ответа. |
6 | Сертификация Microsoft 365 | Логотип сертификации Microsoft 365 означает, что приложение было проверено на основе элементов управления, предусмотренных ведущими отраслевыми системами стандартов, и что для защиты данных клиентов применяются надежные методы обеспечения безопасности и соответствия требованиям. Дополнительные сведения приведены в статье Сертификация Microsoft 365. |
7 | Publisher Information (Сведения об издателе) | Отображает, опубликовано ли приложение корпорацией Майкрософт. |
8 | Разрешения | Этот список содержит разрешения, которые запрашивает клиентское приложение. Пользователям всегда следует проверять типы запрашиваемых разрешений, чтобы понять, к каким данным будет иметь доступ клиентское приложение от имени пользователей, если они предоставят свое согласие. Разработчик приложений лучше всего запрашивать доступ к разрешениям с минимальными привилегиями. |
9 | Описание разрешения | Это значение задается службой, предоставляющей разрешения. Чтобы просмотреть описание разрешений, необходимо открыть значок шеврона рядом с разрешением. |
10 | https://myapps.microsoft.com |
Ссылка, где пользователи могут просмотреть и удалить все приложения сторонних производителей, которые в настоящее время имеют доступ к данным пользователя. |
11 | Сообщите об этом здесь | С помощью этой ссылки можно сообщить о подозрительном приложении, если вы не доверяете ему, считаете, что оно олицетворяет другое приложение, будет неверно использовать ваши данные, или по какой-либо другой причине. |
В следующем разделе описаны распространенные сценарии и ожидаемый интерфейс согласия для каждого из них.
В этом сценарии согласия пользователь обращается к приложению, которому требуется набор разрешений, который находится в пределах области полномочий пользователя. Пользователь направляется в поток согласия пользователя.
Администраторы видят другой элемент управления традиционным запросом на согласие, который позволит предоставить согласие от имени всего клиента. Элемент управления по умолчанию отключен, поэтому только если администраторы явно установите флажок, будет предоставлено согласие от имени всего клиента. Флажок будет отображаться только для роли администратора привилегированных ролей, поэтому администратор облака и администратор приложений не увидят этот флажок.
Пользователи видят традиционный запрос на согласие.
В этом сценарии согласия пользователь обращается к приложению, которому требуется по крайней мере одно разрешение, которое находится за пределами области полномочий пользователя.
Администраторы видят другой элемент управления в традиционном запросе на согласие, который позволит им согласие от имени всего клиента.
Пользователям, которые не являются администратором, запрещено предоставлять согласие приложению, и им будет предложено попросить администратора получить доступ к приложению. Если рабочий процесс согласия администратора включен в клиенте пользователя, пользователи могут отправить запрос на утверждение администратора из запроса на согласие. Дополнительные сведения о рабочем процессе согласия администратора см . в рабочем процессе согласия администратора.
В этом сценарии согласия пользователь переходит к потоку согласия администратора или направляется к ней.
Пользователи администратора видят запрос на согласие администратора. Заголовок и описание разрешений в этом подтверждении изменятся. В изменениях отразится тот факт, что принятие этого запроса предоставит приложению доступ к запрашиваемым данным от имени всего клиента.
Пользователям запрещено предоставлять согласие приложению, и им будет предложено попросить администратора получить доступ к приложению.
В этом сценарии администратор предоставляет все разрешения, запрашиваемые приложением, которые могут включать делегированные разрешения от имени всех пользователей в клиенте. Администратор предоставляет согласие через страницу разрешений API регистрации приложения в Центре администрирования Microsoft Entra.
Все пользователи этого клиента не увидят диалоговое окно согласия, если приложение не требует новых разрешений. Сведения о том, какие роли администратора могут предоставить делегированные разрешения, см. в разделе "Разрешения роли администратора" в идентификаторе Microsoft Entra.
Маңызды
Для одностраничных приложений (SPA), использующих MSAL.js, сейчас требуется предоставление явного разрешения с помощью кнопки Предоставить разрешения. В противном случае происходит сбой приложения при запросе маркера доступа.
В этом разделе описываются распространенные проблемы с взаимодействием с согласием и возможные советы по устранению неполадок.
Ошибка 403
- Это делегированный сценарий? Какие разрешения есть у пользователя?
- Добавлены ли необходимые разрешения для использования конечной точки?
- Проверьте маркер, чтобы узнать, есть ли необходимые утверждения для вызова конечной точки.
- На какие разрешения было предоставлено согласие? Кто предоставил согласие?
Пользователь не может предоставить согласие
- Проверьте, отключен ли администратор клиента согласие пользователя для вашей организации
- Убедитесь, что запрашиваемые разрешения являются разрешениями, ограниченными администратором.
Пользователь по-прежнему заблокирован даже после предоставления согласия администратора.
- Проверьте, настроены ли статические разрешения как супермножество разрешений, запрашиваемых динамически.
- Проверьте, требуется ли назначение пользователя для приложения.
Инструкции по устранению неполадок см. в статье Непредвиденная ошибка при предоставлении согласия для приложения.
- Получите пошаговые сведения о том, как платформа согласия Microsoft Entra реализует согласие.
- Получите более подробные сведения об использовании инфраструктуры согласия в мультитенантном приложении, чтобы реализовать согласие пользователя и администратора, с поддержкой нескольких дополнительных шаблонов многоуровневого приложения.
- Узнайте, как настроить домен издателя приложения.