Как мой клиент должен авторизовать мое серверное приложение для доступа к своим ресурсам Azure?

Мы создали приложение, которое считывает информацию об облачных ресурсах клиента и дает им представление. В настоящее время он реализован для AWS.

В AWS мой клиент создает роль IAM с политикой доверия и внешним идентификатором и делится этой информацией со мной. Затем я «Принимаю на себя роль» в их аккаунте. Каков эквивалентный подход в Azure?

Я вижу такие понятия, как «Приложение», «Основной сервис» и т. д., но все, что я читал, похоже, сосредоточено на SSO и разрешении корпоративным пользователям «доступа к внешним приложениям», а не авторизации самих приложений на стороне сервера.

Я должен создать «приложение» и добавить его? Создать пользователя и попросить его пригласить? Извините, я новичок в Azure, и большая часть документации до сих пор рассматривает меня как ИТ-администратора, пытающегося добавить Jira на портал IdP.


azure azure-security
person steven-landers    schedule 13.12.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Ручной вариант требует от них создания регистрации приложения, которая создает субъект-службу, а затем предоставляет роли RBAC этому субъекту-службе. Затем они могут дать вам идентификатор арендатора, идентификатор клиента и секрет. Вместо секрета вы также можете создать сертификат и дать им открытый ключ. Они могут добавить его в качестве учетных данных в приложение.

Существуют инструменты командной строки, которые они могут использовать для создания SP и приложения https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest#az-ad-sp-create-for-rbac

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

person juunas    schedule 13.12.2019
comment
Спасибо! Если мое приложение не взаимодействует с пользователем (например, запускается ежедневно автоматически), справедливо ли будет сказать, что учетные данные RBAC — лучший подход? - person steven-landers; 13.12.2019
comment
Я бы сказал, что будет легче. Хотя интерактивность потребуется только один раз, срок действия токенов обновления может и действительно истечь. В этих случаях вам нужно, чтобы они снова взаимодействовали, чтобы получить новые токены. Эта проблема не существует с первым подходом, когда они регистрируют приложение. Хотя секрет/сертификат, конечно, может истечь. Это также больше ручной работы. - person juunas; 13.12.2019