Azure Диспетчер ресурсов от имени Azure AD Multitenant App - PullRequest
Новая
       52

Azure Диспетчер ресурсов от имени Azure AD Multitenant App

1 голос
/ 08 апреля 2020

Общий обзор того, чего я пытаюсь достичь

Я пытаюсь создать многопользовательское веб-приложение Azure AD, которое позволяет мне управлять ресурсами в подписках / клиентах клиентов с помощью Azure Resource Manager ( ARM) API. Я довольно новичок в Azure нашей эры Multitenancy.

Идеальный поток управления 

1. A customer browses the Applications (ideal an admin of the customer tenant)
2. Will be granted with Azure AD authorize flow 
3. Accepts everything and grants admin consent for the AD App in their tenant
4. Unclear: The AD App will be granted contributer access on a subscription or resource
5. My Web App will be able to use the AD App credentials to manage the customer resources using the ARM APIs

Задача

Шаги 1-3, 5 : Ясно, и я знаю, как это построить.
Шаг 4 : Я не уверен, как построить это так, чтобы этот шаг происходил автоматически.

Решения, которые я рассмотрел

В худшем случае клиент AD Admin должен вручную предоставить приложению AD доступ к подписке или ресурсу с использованием портала Azure.

1 Ответ

2 голосов
/ 08 апреля 2020

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

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

Для этого вам потребуется идентификатор объекта субъекта службы для вашего приложения, созданного в целевом клиенте. Вы можете получить его, приобретя токен только для приложения, например, для Azure Management API из конечной точки токена этого клиента после того, как пользователь вошел в систему. Токен будет содержать утверждение oid, которое является идентификатором объекта для участника службы.

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

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

...