#azure #azure-active-directory
#azure #azure-active-directory
Вопрос:
Я ищу наилучший подход, позволяющий приложению получать доступ к Graph API через учетную запись службы.
Идея состоит в том, чтобы предоставить делегированные разрешения Graph API для этого приложения, которые затем будут дополнительно ограничены доступом учетной записи службы, используемой в приложении. Проблема в том, что для учетной записи службы не должно требоваться никакого взаимодействия.
Например: Я хочу, чтобы разработчик создавал приложения любого типа для доступа к Graph API, но управлял только ресурсами, к которым его учетной записи службы предоставлен доступ. Например, я не хочу, чтобы он мог управлять всеми группами AAD, а только группами AAD, владельцем которых является его учетная запись службы.
Есть какие-нибудь рекомендации, которые помогут мне начать работу с демонстрацией? Я искал учебные пособия и статьи, но, похоже, ни одна из них не соответствует моим требованиям.
Ответ №1:
На данный момент я не думаю, что вы можете это сделать. При проверке подлинности учетных данных клиента (идентификатор клиента секрет / сертификат) применяются разрешения приложения. Делегированные разрешения применяются только при участии пользователя. Таким образом, единственный способ в настоящее время ограничить область действия — выполнять вызовы от имени пользователя.
Конечно, вы все еще можете в основном автоматизировать это. Один из способов — заставить разработчика аутентифицироваться в своей учетной записи один раз. Затем ваше приложение должно получить токен обновления для этого пользователя, который затем оно может использовать для получения новых токенов доступа, необходимых для выполнения вызовов от имени пользователя в любое удобное для него время.
Теперь, конечно, единственная проблема с токенами обновления заключается в том, что они могут устареть или быть отозваны. Разработчику пришлось бы авторизовать приложение снова. Если для бизнеса критически важно, чтобы такого рода ситуация не возникала, тогда вы должны использовать разрешения приложения (которые являются общеорганизационными, для всех групп и т.д.).
Комментарии:
1. Привет @juunas, это имеет смысл. Но как бы вы увидели это на практике? Какой поток OAuth вы бы порекомендовали? Целью, конечно, является создание критически важных для бизнеса приложений, чтобы действительно избегать обновления токенов, которые больше не могут запрашивать новый токен доступа. Какие меры можно предпринять, чтобы токены обновления не могли запрашивать новые токены доступа?
2. Если я правильно помню, сброс пароля — это одна из вещей, которая делает недействительными все токены обновления для этого пользователя.
3. Кроме того, я бы предложил использовать токен обновления ежедневно и заменять старый токен обновления новым возвращаемым токеном обновления. Это предотвращает устаревание.
4. спасибо, я посмотрю, как я могу решить это программно. Что касается потоков OAuth 2.0: если мои пользователи проходят аутентификацию через WS-Федерацию (SSO), мешает ли это мне использовать конечную точку v2, поскольку она не поддерживает WS-федерацию, или это только для приложения?
5. Хм, я не уверен. Вы имеете в виду, что они проходят аутентификацию с помощью WS-Fed для других приложений? В этом случае это не имеет значения. Каждое приложение может выбрать, какой протокол и конечную точку оно хочет использовать.
Ответ №2:
Возможно, вы захотите взглянуть на Получение доступа без участия пользователя.
Некоторые приложения вызывают Microsoft Graph со своим собственным идентификатором, а не от имени пользователя. Во многих случаях это фоновые службы или демоны, которые запускаются на сервере без присутствия пользователя, вошедшего в систему.
…
Этапы аутентификации и авторизации
Основные шаги, необходимые для настройки службы и получения токена от конечной точки Azure AD версии 0, который ваша служба может использовать для вызова Microsoft Graph под своим собственным идентификатором, следующие:
- Зарегистрируйте свое приложение.
- Настройте разрешения для Microsoft Graph в своем приложении.
- Получите согласие администратора.
- Получите токен доступа.
- Используйте токен доступа для вызова Microsoft Graph.
Критическим моментом является настройка разрешений. Вероятно, необходимо изучить ссылку на разрешения, чтобы посмотреть, обеспечивает ли она необходимую вам степень детализации.
2. Настройте разрешения для Microsoft Graph
Для приложений, которые вызывают Microsoft Graph под своим собственным идентификатором, Microsoft Graph предоставляет разрешения приложений. … Вы предварительно настраиваете разрешения приложения, необходимые вашему приложению, при регистрации вашего приложения.
Комментарии:
1. Привет @ ‘Джеймс Вуд’, это уже было более или менее понятно для меня. Проблема в том, что мы не хотим раздавать разрешения приложениям, поскольку для них нет области видимости. Разработчик должен был бы убедиться, что определение области выполняется программно, и мы должны были бы доверять этому…
Ответ №3:
Просто для справки, даже если это вопрос многолетней давности. Теперь есть токен ID, который будет предоставлять области на основе ролей приложения. У каждого разработчика может быть своя область действия, и на основе этого вы можете контролировать, какой разработчик может получить доступ к какому ресурсу. Это означает, что вам в основном пришлось бы написать прокси, который отфильтровывал бы разработчика X, пытающегося подключиться к ресурсу Y, на основе утверждений в токене ID.
После определения ролей вы можете назначить конкретного пользователя роли, перейдя в Корпоративные приложения -> Ваше имя приложения -> Пользователи и группы -> Добавить пользователя / группу
Затем просто назначьте пользователю роль. Также убедитесь, что вы установили флажок ID Token в конфигурации приложений.
Для получения идентификационного токена используйте гибридный поток, который объясняется здесь