Автоматизация создания ключа веб-приложения Azure AD

Question

Мы создали набор сценариев Powershell для автоматизации процесса создания новых экземпляров нашего веб-приложения в нашей среде Azure. Одна часть этих скриптов использует Graph API для создания нескольких объектов Azure AD, а также соответствующих объектов в Auth0, которые мы используем для единого входа. До сих пор мы не добились успеха в программном создании нового ключа для приложения AAD. Мы пробовали ряд методов, и хотя мы видим, что у получающегося приложения есть ключ (и объект подключения в Auth0 имеет этот ключ в поле Client Secret), мы всегда получаем эту ошибку при попытке аутентификации :

к этому моменту мы уже получили доступ к приложению к единой регистрации и читать данные каталога в AAD. (Редактирование:. Мы делаем это вручную после provisioning_ticket_URL, который является частью объекта, возвращенного API вызова Auth0 создать объект Connection Этот URL побуждает нас к Azure учетных данных, а затем отображает эту страницу:

)

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

В теле приложения AAD, что мы создаем в вызове API, мы имеем этот раздел, который определяет ключ:

"passwordCredentials": 
    [ 
    { 
     "startDate": "2016-10-28T20:40:32Z", 
     "endDate": "2017-10-29T20:40:32Z", 
     "keyId": "(a GUID)", 
     "value": "(a Base64 string)" 
    } 
    ], 

Что касается тех ценностей, мы попытались создать их в довольно много разных способов, и он принимает значения в вызове API PUT, но все они все еще дают нам ту же ошибку, когда мы пытаемся войти в систему. В качестве примера мы попытались подключить значения из $ appKeyGUID и $ appKeyValue из этого:

$appKeyGUID = [guid]::NewGuid() 
$guidBytes = [System.Text.Encoding]::UTF8.GetBytes($appKeyGUID) 
$appKeyValue = [System.Convert]::ToBase64String($guidBytes); 

в ключID и значение, respe ctively. Я читал в другом месте, что значение должно составлять 44 символа, хотя этого не будет.

Но похоже, что сама ценность не может быть проблемой. Я попытался создать ключ через портал Azure, используя вызов GET API Graph API для извлечения keyId, а затем hardcoding эти два точных значения в тело приложения, но вход в систему по-прежнему дает ту же ошибку.

Любая идея, где я ошибаюсь?

EDIT: По предложению Филиппа я попытался изменить только отображаемое имя приложения AD через портал, и это действительно решило проблему. Это заставило меня подумать, что, возможно, что-то было не так в другом месте тела приложения, которое фиксировалось при сохранении через портал. Я проверил манифеста до и после того, как сделать это руководство сохранить, и там действительно одна небольшая разница: в разделе RequiredResourceAccess (из которых я узнал отсюда http://www.cloudidentity.com/blog/2015/09/01/azure-ad-permissions-summary-table/ и здесь https://www.microsoftpressstore.com/articles/article.aspx?p=2473127&seqNum=2), у меня было так:

{ 
    "id": "5778995a-e1bf-45b8-affa-663a9f3f4d04", 
    "type": "Role" 
}, 
{ 
    "id": "5778995a-e1bf-45b8-affa-663a9f3f4d04", 
    "type": "Scope" 
} 

Вместо это портал, который изменяет его на

{ 
    "id": "5778995a-e1bf-45b8-affa-663a9f3f4d04", 
    "type": "Role,Scope" 
}, 

Таким образом, я изменил тело, которое мы отправляем, чтобы соответствовать второму формату. К сожалению, мы все еще получаем ту же ошибку с этим изменением.Кроме того, я подтвердил, что манифест теперь идентичен до и после создания сохранения на портале, а также тело, возвращенное вызовом API GET приложения. Должно быть что-то еще, что сохранение порта меняется, кроме определения приложения.

После этого я попытался использовать API-интерфейс Графа, чтобы выполнить два вызова PATCH, чтобы обновить отображаемое имя, а затем изменить его, надеясь, что он будет вести себя аналогично тому, как это делается через портал и устранить проблему. Я проверил через портал, что вызовы PATCH действительно меняют отображаемое имя приложения. К сожалению, кажется, что эти изменения не устранили проблему, и я все еще получаю исходную ошибку.

Мы создаем приложение с API вызова Graph, как это:

$uri = "https://graph.windows.net/$waadTenant/applications?api-version=1.6" 
$newADApp = (Invoke-RestMethod –Uri $uri –Headers $authHeader –Method POST -Body $newappbody –Verbose) 

А вот $ newappbody, что мы в конечном итоге, используя для определения приложения. Я оставил некоторые вещи трудно закодированные для устранения неполадок:

{ 
    "odata.type": "Microsoft.DirectoryServices.Application", 
    "displayName": "customer1", 
    "homepage": "https://customer1.(our tenant).com", 
    "identifierUris": 
    [ 
    "https://customer1.(our tenant).com" 
    ], 
    "replyUrls": 
    [ 
    "https://(our tenant).auth0.com/login/callback" 
    ], 
    "passwordCredentials": 
    [ 
    { 
     "startDate": "(a hardcoded date)", 
     "endDate": "(a hardcoded date)", 
     "keyId": "(hardcoded GUID that was previously generated by the portal and extracted through an API GET)", 
     "value": "(hardcoded Base64 like above)" 
    } 
    ], 
    "requiredResourceAccess": 
    [ 
    { 
     "resourceAppId": "00000002-0000-0000-c000-000000000000", 
     "resourceAccess": 
     [ 
     { 
      "id": "5778995a-e1bf-45b8-affa-663a9f3f4d04", 
      "type": "Role,Scope" 
     }, 
     { 
      "id": "311a71cc-e848-46a1-bdf8-97ff7156d8e6", 
      "type": "Scope" 
     }, 
     { 
      "id": "6234d376-f627-4f0f-90e0-dff25c5211a3", 
      "type": "Scope" 
     } 
     ] 
    } 
    ] 
} 

Answer 1

Похоже, в конечном итоге вопрос здесь связан с применением согласия. я буду вдаваться в более подробно здесь, но вы можете быстро сделать чтение через этот документ, который описывает наше согласие Framework: https://azure.microsoft.com/en-us/documentation/articles/active-directory-integrating-applications/

Материал вы показываете в своем манифесте приложения связаны с конфигурацией приложения, однако, запись согласия для вашего приложения там не будет найдена, поэтому я думаю, что ваше тестирование «a/b» не будет плодотворным.

Я думаю, что вы действительно находите здесь, что у Azure Portal есть «волшебство» в фоновом режиме, которое даст согласие на ваше приложение, если вы являетесь администратором, и вы сохраняете приложение. Когда вы регистрируете приложение от начала до конца на портале (опять же, как администратор), мы автоматически регистрируем ваше согласие после сохранения приложения. Это происходит в фоновом режиме, и создаваемые «объекты», которые создаются, являются: Принципом обслуживания вашего приложения в вашем арендаторе и соглашением между вами как пользователем и вашим главным сервисом. Ссылка, которая создается, представляет собой объект «одобрения для арендатора», который является тем же самым, что вы могли бы получить, если бы вы добавили «prompt = admin_consent» к вашему URL-адресу входа в качестве строки запроса.

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

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

Так что в итоге:

1. Автоматически создавать приложения, используя любой метод, который вы хотите
2. Затем используйте информацию прикладную, и создать интерактивный вход в систему с правами администратора, используя строку запроса «быстрое = admin_consent»
3. Затем использовать ваше приложение, однако вы ожидаете, что работать

Спасибо! Shawn Tabrizi