Запрос пользователей из разных клиентов Azure - PullRequest
0 голосов
/ 21 марта 2019

У нас есть случай, когда у нас есть «клиенты». Каждый клиент - это отдельный клиент Azure, но мы сохраняем его идентификатор в базе данных. Таким образом, у нас есть приложение Angular, в котором мы хотим, чтобы все клиенты были похожими на выпадающий список, и на основе выбранного клиента запрашивать их пользователей-арендаторов, чтобы мы могли добавить его в нашу базу данных и предоставить им разрешения и прочее для всех других приложений. Согласно моим прочтениям, это не достижимо, enter image description here

Поскольку это разрешение будет использоваться от 3-4 парней, которые являются частью нашего арендатора.

Есть ли способ, которым мы можем этого достичь?

1 Ответ

2 голосов
/ 21 марта 2019

Вам нужно будет использовать User.Read.All Разрешения приложений и пройти аутентификацию с использованием Client Credentials . Затем вам нужно будет получить токен от каждого арендатора до вызова /v1.0/users.

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


Комментарий Рохита ниже - превосходный момент. Если ваше приложение является SPA, то есть авторизация полностью выполняется в браузере через Javascript, вы действительно ограничены OAuth Implicit Grant .

Чтобы использовать Client Credentials или Код авторизации предоставления, вам необходим какой-то внутренний API для обработки аутентификации и вызовов аутентифицированных API. Я бы сказал, что вы должны делать это в любом случае, если по какой-либо другой причине, кроме принуждения вашего пользователя к повторной аутентификации каждый час, это не очень удобно для пользователя.

Если вы не против, чтобы каждый пользователь в арендаторе проходил аутентификацию, вы можете использовать грант Авторизационного кода. Это немного сложнее в настройке, поскольку требует, чтобы вы отслеживали отдельные токены обновления для каждого пользователя. Ваш бэкэнд должен будет получить токен обновления, обменять его на набор новых токенов (access_token и refresh_token), сохранить новый токен обновления и затем вызвать API, используя новый токен доступа.

Поскольку между токеном и пользователем существует соотношение 1: 1, то в масштабе вы просматриваете множество токенов. Вам также понадобится множество рабочих процессов обслуживания для решения проблем, которые могут возникнуть (обновление ошибок токена, новые требования к области и т. Д.).

Это действительно сводится к глубине отношений между вашим приложением и арендатором. Если вы предоставляете безопасность и анализ для всей организации, тогда разумно запросить глобальный Mail.Read. Если вы предоставляете услугу только для части организации, может быть сложно заставить ИТ-персонал подписать такой широкий диапазон разрешений.

...