Как протестировать веб-API, защищенный Azure AD, с помощью тестового адаптера Visual Studio?

Я создал мультитенантный веб-API, который отлично работает. Теперь я хочу создать собственный клиент для тестирования. Приложение веб-API определяется в одном арендаторе. Тестовое приложение определено в другом клиенте, который дал согласие администратора на использование веб-API.

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

Получение токена

var userCredential = new UserCredential("[email protected]", "password");
var context = new AuthenticationContext("https://login.windows.net/common");

return context.AcquireToken("https://webapitenant.onmicrosoft.com/webApiResourceUri", testClientId, userCredential).AccessToken;

Проблема с этим кодом заключается в том, что он не работает, пока я не даю согласие администратора на собственное приложение, даже если пользователь находится в том же клиенте, что и регистрация приложения.

Исключение:

'Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException' in Microsoft.IdentityModel.Clients.ActiveDirectory.dll

Additional information: 
AADSTS65001: The user or administrator has not consented to use the application with ID 'nativeclientid'. Send an interactive authorization request for this user and resource. 

Поскольку тесты не интерактивны, мне нужно создать консольное приложение, использующее приведенный выше код, но с PromptBehaviour.Always. Это запросит у меня имя пользователя и пароль и покажет форму согласия. После того, как я даю согласие, начинают работать тесты, использующие ту же регистрацию нативного приложения.

Есть ли способ принять форму согласия без интерактивного графического интерфейса?


person Gabriel Smoljár    schedule 14.12.2016    source источник


Ответы (1)


На данный момент нет другого способа написать согласие пользователя без какого-либо пользовательского опыта. (Что правильно?)

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

Если вы используете другие порталы или API для создания своего приложения, вам необходимо дать согласие на использование приложения хотя бы один раз. Вам не нужно обязательно указывать в приложении подсказку, чтобы получить экран согласия. Вы можете просто сгенерировать URL-адрес для входа в свое приложение, что также проведет вас через процесс получения согласия:

https://login.microsoftonline.com/<TenantID>/oauth2/authorize?client_id=<AppID>&response_type=code&redirect_uri=<RedirectURI>&resource=<ResourceURI>&prompt=admin_consent

Обратите внимание, что мы добавили «prompt=admin_consent» в конце, что даст согласие на приложение от имени всего клиента. С таким согласием вам нужно будет сделать это только один раз для каждого приложения, чтобы оно заработало.

Надеюсь, это поможет!

person Shawn Tabrizi    schedule 14.12.2016
comment
Вы уверены, что приложения, созданные на портале, получают согласие автоматически? Я создал собственный клиент на портале, и мне все равно было предложено заполнить форму согласия. Тестовый пользователь находится в том же каталоге, что и собственное приложение. Однако веб-API находится в другом арендаторе. - person Gabriel Smoljár; 15.12.2016
comment
Конкретно как администратор да согласие записывается. В прошлом приложения Native Client не записывали согласие, но, насколько я понимаю, с тех пор это было исправлено, поэтому оно также должно работать с собственными клиентами. Наконец, вы можете обнаружить, что в вашем коде вы «запрашиваете согласие», что вызовет диалог о согласии независимо от того, дали вы уже согласие или нет. Дайте мне знать, если вы по-прежнему сталкиваетесь с таким поведением, и, возможно, мы сможем отладить ваш опыт за пределами сайта. - person Shawn Tabrizi; 15.12.2016
comment
Если я правильно помню, он работает так, как вы говорите, пока веб-API и собственный клиент зарегистрированы в одном арендаторе. В моем случае я хотел запустить тесты на удаленном сервере, так как отлаживать локально проще, чем ждать и устранять неполадки вывода сборки VSTS. Причина наличия приложений в отдельных арендаторах заключалась в том, что разработчикам нужно было только настроить собственное собственное приложение в своих собственных арендаторах и предоставить общий доступ к приложению веб-API в общем арендаторе. Форсирование формы согласия в фиктивном консольном приложении было преднамеренным, поскольку это имело бы смысл, исходя из сообщения об исключении в вопросе. - person Gabriel Smoljár; 15.12.2016
comment
Я только что попытался настроить это для одного из моих коллег, который является администратором. В этом случае и веб-API, и собственный клиент находились в одном арендаторе. Нам все равно пришлось использовать URL-адрес в вашем ответе, чтобы получить согласие. Правильно ли я вас понял, если сказал, что это не ожидаемое поведение? - person Gabriel Smoljár; 16.12.2016
comment
Да, это НЕ ожидаемое поведение. Я только что проверил это на себе и получил ожидаемые результаты. Я вошел в свой клиент, войдя в систему как администратор клиента, используя Портал управления Azure. Я создал собственное клиентское приложение. Затем я создал веб-API для одного клиента с идентификатором URI идентификатора приложения. Затем я вернулся к собственному клиентскому приложению и добавил разрешение по умолчанию, созданное для моего веб-API, в разделе «Разрешения для других приложений». Затем я сохранил родное приложение. Затем я использовал ADAL и Auth Code Grant Flow, чтобы получить токен доступа, и все это без согласия. - person Shawn Tabrizi; 17.12.2016