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

Разработка стратегии делегированных разрешений

Эта статья поможет вам, как разработчику, реализовать оптимальный подход к управлению разрешениями в приложении и разработке с помощью принципов нулевого доверия. Как описано в разделе "Получение авторизации для доступа к ресурсам", делегированные разрешения используются с делегированным доступом, чтобы разрешить приложению действовать от имени пользователя, получая доступ только к тому, к чему может получить доступ пользователь. Чтобы получить доступ к любым данным, связанным с разрешением, используйте разрешения приложения с прямым доступом для предоставления возможности приложению. Только администраторы и владельцы субъектов-служб могут согласиться на разрешения приложения.

Модели разрешений и согласия относятся в основном к приложению. Процесс разрешения и согласия не имеет контроля над тем, что может сделать пользователь. Он определяет, какие действия разрешено выполнять приложение.

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

Схема Venn показывает эффективные разрешения в качестве пересечения разрешений приложений и возможностей пользователей.

Например, ваше приложение, пользователи которого работают с приложением, получает разрешение на обновление профиля каждого пользователя в учетной записи арендатора. Это не означает, что любой пользователь, на котором запущено приложение, может обновить профиль любого другого пользователя. Если администратор решит одобрить ваше приложение User.ReadWrite.All, то они считают, что ваше приложение выполняет правильные действия при обновлении профилей пользователей. Ваше приложение может записывать изменения и правильно защищать информацию. Администратор принимает решение о приложении, а не о пользователе.

Минимальный подход к привилегиям

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

Разработчик должен:

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

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

Оцените запрашиваемые разрешения с целью убедиться в том, что вы просите о предоставлении минимально возможного набора привилегий, необходимого для выполнения задания. Избегайте запроса более высоких разрешений привилегий. Вместо этого тщательно проработайте большое количество разрешений, предоставляемых API, таких как Microsoft Graph. Найдите и используйте минимальные разрешения для решения ваших потребностей. Если вы не пишете код для обновления профиля пользователя, вы не запрашиваете его для приложения. Если вы обращаетесь только к пользователям и группам, вы не запрашиваете доступ к другим сведениям в каталоге. Вы не запрашиваете разрешение на управление электронной почтой пользователя, если вы не пишете код, который обращается к электронной почте пользователя.

В разработке приложений нулевого доверия:

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

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

Если конструктор API требует согласия администратора для разрешения, это разрешение всегда требует согласия администратора. Администратор арендатора не может отменить это и требовать только согласия пользователя.

Когда дизайнер API определяет разрешения, требующие согласия пользователя, администратор арендатора может переопределить предложения согласия пользователя дизайнера API. Администраторы клиентов могут сделать это с главным переключателем в клиенте: все требует согласия администратора. Они могут отменить согласие пользователя более подробно с помощью разрешений и управления согласием. Например, пользователи могут разрешить пользователям предоставлять согласие на запросы согласия пользователей от проверенных издателей, но не от других издателей. В другом примере они могут разрешить User.Read войти в систему и прочитать их профиль, но требовать согласия администратора для приложений, которые запрашивают разрешение на доступ к почте или файлам.

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

Пример использования JavaScript MSAL

Для проверки подлинности в этом примере используется библиотека проверки подлинности Microsoft JavaScript (MSAL) для входа пользователя в одностраничное приложение (SPA), где выполняется все логика приложения из браузера.

Из связанной статьи «Быстрый старт» вы можете скачать и запустить пример кода. В нём показано, как одностраничное приложение JavaScript может аутентифицировать пользователей и вызывать Microsoft Graph, используя поток кода авторизации с методом проверки подлинности PKCE (Proof Key for Code Exchange). В примере кода показано, как получить маркер доступа для вызова API Microsoft Graph или любого веб-API.

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

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Затем вы используете нашу библиотеку MSAL. В MSAL JavaScript существует определенный API для входа. В браузере есть два API, использующих определенные возможности. Один из них — войти с помощью всплывающего окна; Другой — войти с помощью интерфейса перенаправления браузера.

Как показано в следующем примере кода, всплывающее окно входа обрабатывает проверку подлинности, которую пользователь должен выполнить путем вызова signIn функции.

function signIn() {

    /**
     * You can pass a custom request object. This overrides the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

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

Как показано в следующем примере кода, приложение пытается получить авторизацию путем вызова AcquireTokenSilent. Если Microsoft Entra ID может выдавать токен без взаимодействия с пользователем, то AcquireTokenSilent возвращает токен, который приложение должно использовать для доступа к Microsoft Graph от имени пользователя.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

Однако часто идентификатор Microsoft Entra не может выдавать маркер без взаимодействия с пользователем (например, пользователь изменил пароль или не предоставил согласие). AcquireTokenSilent отправляет сообщение об ошибке обратно в приложение, требующее взаимодействия с пользователем. Когда ваше приложение получает сообщение об ошибке, вы возвращаетесь к вызову AcquireTokenPopup.

На этом этапе Microsoft Entra ID взаимодействует с пользователем, чтобы идентифицировать его и предоставить приложению разрешение на выполнение действий от его имени (например, выполнить MFA, указать свой пароль, дать согласие). Затем ваше приложение получает токен, необходимый для продолжения.

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

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

  • Last updated on