Разница в аутентификации между использованием ключа приложения AAD и пароля участника-службы

Чтобы запускать приложения в Azure, мне нужно создать приложение в Azure AD и соответствующий субъект-службу. Затем мое приложение аутентифицируется по этой паре приложение / принципал. Для аутентификации я могу создать ключ приложения при регистрации приложения или создать пароль в субъекте-службе (среди других вариантов). В чем разница с практической точки зрения?

Например, этот код выполняется точно так же (снаружи), является ли ключ $ ключом приложения или паролем субъекта-службы:

    $key = ConvertTo-SecureString $authKeyOrPassword -AsPlainText -Force
    $cred = New-Object System.Management.Automation.PSCredential($appID, $key)
    Add-AzureRmAccount -Credential $cred -TenantId $tenantID -ServicePrincipal

Когда мне следует аутентифицироваться в приложении, а когда использовать участника-службы?


azure azure-active-directory service-principal azure-security azure-authentication
person jschmitter    schedule 10.10.2017    source источник

Ответы (1)


arrow_upward
14
arrow_downward

Во-первых, позвольте мне объяснить, почему в Azure AD есть и приложения, и субъекты-службы. Вот объяснение из статьи Витторио Берточчи из книги Mordent Authentication with Azure AD для веб-приложений.

Azure AD определяет новую сущность, приложение, которая предназначена для описания приложения как абстрактной сущности: шаблона, если хотите. Как разработчик вы работаете с приложениями. Во время развертывания данный объект Application можно использовать в качестве схемы для создания ServicePrincipal, представляющего конкретный экземпляр приложения в каталоге. Именно этот ServicePrincipal используется для определения того, что приложение на самом деле может делать в этом конкретном целевом каталоге, кто может его использовать, к каким ресурсам у него есть доступ и т. Д.

Потерпи еще немного, абстрактная часть почти закончена. Основной способ, с помощью которого Azure AD создает ServicePrincipal из приложения, - это согласие. Вот упрощенное описание процесса: предположим, что вы создаете объект Application в каталоге A, предоставляя все координаты протокола, которые мы уже обсуждали в предыдущих главах. Предположим, пользователь из клиента B переходит на страницы приложения и запускает процесс аутентификации. Azure AD аутентифицирует пользователя из B по его домашнему каталогу B. При этом он видит, что для приложения в B нет ServicePrincipal; следовательно, пользователю предлагается указать, хочет ли он разрешить этому приложению доступ к каталогу B (в каком качестве вы увидите позже). Если пользователь дает согласие, Azure AD использует объект Application в A в качестве схемы для создания ServicePrincipal в B. Наряду с этим B записывает, что текущий пользователь дал согласие на использование этого приложения (ожидайте подробностей об этом позже. ). После этого пользователь получает токен для доступа к приложению.

Если вы хотите узнать разницу между ключом приложения Azure AD и паролем принципа службы, вам следует знать взаимосвязь приложения и субъекта-службы. Я скопирую и вставлю сюда некоторые выдержки из этой страницы документация

  1. # P5 #
  2. # P6 #
  3. # P7 #

Пример диаграммы

введите описание изображения здесь

Резюме

Теперь мы можем узнать разницу между ключом приложения Azure AD и паролем принципа службы. Они принадлежат разным объектам. Пароль, который будет связан с субъектом службы. Это только для того, чтобы клиент приложения мог войти в Azure. Однако вы можете указать значение ключа приложения с идентификатором приложения, чтобы войти в систему как приложение со всеми клиентами.

Для получения дополнительных сведений об объектах субъектов-служб и приложений в Azure Active Directory см. этот документ.

person Wayne Yang    schedule 11.10.2017
comment
Спасибо! Итак, верны ли следующие выводы? 1) если я хочу заблокировать разрешения данного процесса, было бы лучше, если бы он аутентифицировался с помощью собственного субъекта-службы, а не с помощью ключа приложения? 2) Является ли основная цель ключа приложения средством для субъектов служб в других клиентах для аутентификации в приложении? Если это так, я думаю, что использование ключа приложения напрямую для аутентификации (как в моем примере кода выше) было бы неправильным. Если нет, то в чем его цель? - person jschmitter; 11.10.2017
comment
Привет, @jschmitter! По вашим дополнительным вопросам у меня есть следующие мнения: 1) Я думаю, что это для разных сцен, а не для разрешений. 2) Если вы хотите использовать принцип обслуживания, вы можете создать ключ для своего приложения или нет. Если вы хотите настроить свое приложение как клиентское приложение для доступа к WebAPI, вам понадобятся ключи приложения. - person Wayne Yang; 12.10.2017
comment
Этот документ также может быть вам полезен. docs.microsoft.com/en-us/azure/active-directory/develop/ - person Wayne Yang; 12.10.2017
comment
Привет, @ jschmitter! Если этот ответ был для вас полезен, отметьте его как ответ, чтобы помочь большему количеству людей. Спасибо! - person Wayne Yang; 13.10.2017
comment
Это помогает с фоновой информацией, но я до сих пор не понимаю, в каких сценариях я бы использовал какой вариант. - person jschmitter; 13.10.2017
comment
Привет @jschmitter Извините за непонятный ответ. Ключ предназначен только для доступа клиентского приложения к WebAPI. Если ваше приложение не является клиентским, ему не нужен ключ. Пример: когда вы регистрируете свое приложение как собственное приложение, у него не будет ключа. Принципу службы не требуется этот ключ для входа в Azure как приложение. - person Wayne Yang; 20.10.2017