6

Для использования с Azure API Management я пытаюсь добавить Приложения в Azure Active Directory (AAD) программным способом, в моем случае с помощью Graph API.Добавление приложений программно в Azure AD с использованием Client Credentials Flow

Мой сценарий таков: для того чтобы защитить веб-API, с которым я хочу работать с API управления Azure, я хочу использовать возможности OAuth AAD для выполнения тяжелой работы по аутентификации и выдачи токенов JWT, а затем просто использовать validate-jwt, чтобы проверить, все ли в Azure API Management. Это имеет то преимущество, что я могу более или менее опускать аутентификацию в моей бэкэнд-службе.

Это прекрасно работает, пока я создал приложение в Azure AD для используемого веб-приложения, но это нужно сделать вручную с Azure Portal; Azure APIm не делает это автоматически.

Теперь я пытаюсь сделать это автоматически: я хотел делегировать подписку на API в APIm на другое веб-приложение, которое я пишу, и оттуда я хочу использовать API-интерфейс Graph для создания Приложение в Azure AD и предоставить разрешения для применения API.

Первое, что я пытался сделать, это иметь третье приложение (мое приложение-приложение), чтобы иметь полные разрешения приложений для приложения Windows Azure Active Directory в Azure AD; это позволяет моему приложению обращаться к AAD с использованием API-интерфейса Graph REST. Мне удается получить маркер доступа с использованием гранта client_credentials (от login.microsoft.com), но этот знак не позволяет мне делать POST на https://graph.windows.net/(my AAD ID)/applications?api-version=1.5:

{ 
     "odata.error": { 
      "code": "Authorization_RequestDenied", 
      "message": { 
       "lang": "en", 
       "value": "Insufficient privileges to complete the operation." 
      } 
     } 
    } 

Я нашел (https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes), что даже если я грант Directory.ReadWrite.All разрешения, приложение (приложение только) не сможет создать или обновить приложение:

Примечание: в частности исключает создание или обновление для лиц, не перечисленных выше. Это включает в себя: Application, Oauth2PermissionGrant, AppRoleAssignment, устройство, ServicePrincipal, TenantDetail, домены и т.д.

Следующая вещь, которую я попытался был владелец ресурса Пароль Грант (grant_type=password), передавая свои полномочия дополнительно, так что Я могу олицетворять себя в Graph API. Теперь мой POST до конечной точки applications преуспевает.

Мой нижний вопрос: могу ли я предоставить достаточные разрешения для моего приложения, чтобы я мог добавлять приложения программным образом с использованием потока учетных данных клиента, а не потока, действующего от имени пользователя? И если да, то как это делается?

+0

я нашел еще одно обсуждения, которое, скорее всего, сводится к точно такой же проблеме, у меня есть: https://social.technet.microsoft.com/Forums/en-US/82ab8a7d- e17b-4e4a-9615-2bdf43f1866a/graph-api-call-returns-lack-privileges-to-complete-the-operation? forum = WindowsAzureAD Кроме того, я также нашел страницу, на которой обсуждаются разрешения API Графа: https : //msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes – donmartin

+0

Предоставляют ли они решение вашей проблемы? – juvchan

+0

Нет, к сожалению, нет. Олицетворение администратора - единственное «решение», которое я нашел до сих пор. – donmartin

ответ

3

Извините, Дон. В настоящее время у нас нет каких-либо областей разрешений для потока учетных данных клиента (только для приложений), которые могут использоваться для создания приложений или служб или для создания любых разрешений на предоставление полномочий oauth2 (или любых других объектов, упомянутых выше в Каталоге. ReadWrite.All). Мы работаем над дополнительными разрешениями только для приложений, которые позволят вам осветить этот сценарий, но у меня нет ETA, который я могу вам дать.

Эта операция должна быть возможным, если вы используете приложение + пользователь (код потока) и предоставить АРР, разрешение Directory.AccessAsUser.All - до тех пор, пока существует пользователь, использующий приложение и что они являются арендатор админ.Не уверен, что это приемлемое решение для вас (и, я думаю, это похоже на то, что вы используете с потоком паролей, хотя я бы рекомендовал использовать здесь поток кода).

UPDATE: Есть несколько новых приложений, которые мы только что добавили для AAD Graph. Application.ReadWrite.OwnedBy (который позволяет приложению создавать/владеть другим приложением - но только обновлять созданные приложения - он не сможет касаться каких-либо других приложений, которыми он не владеет) И Application.ReadWrite.All (который позволяет приложению создавать/управлять ВСЕМИ приложениями у арендатора). Похоже, первое было бы уместным. Вы, , должны см. Это отображаются на Лазурном портале для ресурса AAD Graph. Однако в настоящее время они не документируются AFAIK.

Надеется, что это помогает,

+0

Да, это было бы своего рода приемлемым обходным решением. В то же время мы также придумали следующую идею (не проверенную), которая идет в одном направлении, но не требует, чтобы пользователь, имеющий роль потребителя API, был администратором AD: мы можем «запускать» управляющий веб-сайт приложение с предоставлением разрешения авторизации с использованием учетных данных администратора AD (чтобы нам не нужно было их хранить в приложении), а затем обновить токен в приложении, чтобы сохранить олицетворение этого администратора внутри приложения, не требуя ручного вмешательства. Но у этого и вида листья плохой вкус. – donmartin

+0

Значит ли клиентские полномочия в целом работают? – Gobliins

+0

Нет. Это не так. Предоставлен пароль владельца ресурса. – donmartin

Смежные вопросы