Azure-аутентификация для утилиты управления

Question

Я разрабатываю инструмент, похожий на облачный проводник Visual Studio, который выполняет ограниченный набор задач управления и развертывания внутри подписки Azure пользователя.

Я отбрасываю несколько вещей, связанных с аутентификацией против Azure и как приложение представляет себя для Azure.

Большая часть документации об аутентификации с Azure связана с веб-приложениями, которые позволяют пользователям проходить аутентификацию против Azure Active Directory. Это не мой сценарий. Хотя мне приложение обязательно аутентифицирует пользователей от Azure AD (как и все пользователи Azure), мои пользователи являются администраторами, а не «пользователями».

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

... однако я также понимаю, что сертификаты управления почти устарели и заменены Принципами обслуживания, что само по себе имеет смысл с точки зрения безопасности (поскольку это обеспечивает более грамотную защиту на основе ролей), однако недостатком является то, что есть много ручных шагов и обручей для перехода, чтобы обеспечить использование Принципов обслуживания с помощью программного обеспечения для администрирования - в частности, вам необходимо предварительно зарегистрировать свое приложение на Azure Portal.

Мне это не нравится, потому что это значительно увеличивает пользовательское трение с помощью программного обеспечения, которое я пишу. Я хочу, чтобы мое программное обеспечение вел себя как облачный проводник Visual Studio или Azure PowerShell, поскольку вам не нужно предварительно регистрировать что-либо: 1. просто запустите программу на рабочем столе; 2. Вы получите приглашение войти в систему с учетными данными учетной записи администратора Azure. 3. мое программное обеспечение отображает содержимое ваших подписки и позволяет выполнять ваши задачи управления.

До сих пор я на самом деле есть что-то, что делает это - я выполнить следующие шаги:

1. Использование Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext для проверки подлинности против https://login.microsoftonline.com/common (с использованием AcquireTokenAsync, который представляет WebView для входа в систему). Я использую clientId: "1950a258-227b-4e31-a9cf-717495945fc2", который является клиентом Azure PowerShell.
2. Используйте маркер с шага 1, чтобы перечислять Арендаторов и Подписки в учетной записи пользователя.
3. Пользователю предлагается выбрать арендатора, а затем подписку из списка загруженный на шаге 2.
4. Отправить новый запрос аутентификации https://login.microsoft.com/{tenantId} (где {tenantId} извлекается из шага 3), опять же, используя тот же clientId.

Однако я не люблю олицетворять Azure PowerShell - Microsoft может отменить этот clientId.

... но как я могу зарегистрировать clientId, который может использоваться для входа в систему на этапе 1 (когда нет tenantId или контекста подписки, таким образом, нет Azure AD, который содержит Принципов обслуживания)?

Answer 1

Мне это не нравится, потому что это значительно увеличивает пользовательское трение с помощью программного обеспечения, которое я пишу. Я хочу, чтобы мое программное обеспечение вел себя как облачный проводник Visual Studio или Azure PowerShell, поскольку вам не нужно предварительно регистрировать что-либо: 1. просто запустите программу на рабочем столе; 2. Вы получите приглашение войти в систему с учетными данными учетной записи администратора Azure. 3.мое программное обеспечение перечисляет содержимое ваших подписей и позволяет выполнять ваши задачи управления.

На самом деле, Visual Studio Cloud Explorer также зарегистрировал приложение в Azure AD и использовал Service Management REST для управления подпиской Azure. И вы можете передать запрос с помощью Fiddler при добавлении учетной записи в облачный проводник.

... но как я могу зарегистрировать clientId, который можно использовать для входа на шаге 1 (когда нет контекста tenantId или подписки, таким образом, нет Azure AD, который содержит Принципов обслуживания)?

Нам необходимо разработать multi-tenant application, который позволяет пользователям из разных арендаторов использовать приложение. После этого мы можем использовать конечную точку Common вместо конкретного идентификатора арендатора, зарегистрированного в приложении. Затем пользователи войдут в систему со своей учетной записью, которая связывается с подпиской Azure и получает токен доступа для Service REST. Наконец, приложение может управлять ресурсом Azure с помощью токена доступа. Например, мы можем использовать REST ниже список Azure Sbuscriptions:

Get:https://management.core.windows.net/subscriptions 
Authorization: Bearer {token} 
x-ms-version: 2013-08-01 

И более подробно о запросах управления аутентификации службы, вы можете обратиться here.