Получение токена для веб-API с использованием учетных данных пользователя

Я создал новую учетную запись пользователя в своем тестовом клиенте AAD, скажем, [email protected], и установил для нее пароль. Эта новая учетная запись является членом группы безопасности, которая может получить доступ к определенному веб-API. Я пытаюсь написать тест (консольную программу), который не в интерактивном режиме получает токен доступа, используя учетные данные пользователя и идентификатор приложения в качестве аудитории, а затем вызывает конечную точку.

Как я могу это сделать?

Обновление:

Я пытаюсь написать набор тестов безопасности интеграции для своего приложения веб-API. Приложение использует группы AAD, которые оно получает как набор утверждений, и обрабатывает их как роли. Поэтому мне нужен набор тестовых учетных записей пользователей с известным паролем с разными ролями для проверки поведения конечной точки в разных контекстах безопасности. Этот подход работал у меня в течение многих лет с классической AD (где я мог выдавать себя за пользователя, используя пару логин/пароль, и выполнять SOAP-вызов службы с включенной аутентификацией Windows).

Обновлено2:

Я мог бы использовать набор регистраций приложений вместо тестовых учетных записей пользователей и без проблем получить токен, используя пару client_id/client_secret, но для назначения корпоративного приложения в группу безопасности требуется премиальный уровень AAD, который очень дорогой: (


person UserControl    schedule 06.09.2018    source источник


Ответы (2)


Это в основном то, для чего предназначен поток предоставления учетных данных владельца ресурса (ROPC). Вы предоставляете Azure AD учетные данные своего приложения с учетными данными пользователя и получаете маркер доступа.

Этот поток обычно не следует использовать для аутентификации, поскольку он существует в стандарте в основном как устаревший путь обновления. И это не работает с федеративными пользователями, пользователями с MFA или с просроченным паролем. Однако ваш случай с автоматическим тестом является одним из сценариев, где я считаю его использование приемлемым.

Вот пример вызова на C#:

string tokenUrl = $"https://login.microsoftonline.com/joonasapps.onmicrosoft.com/oauth2/token";
var req = new HttpRequestMessage(HttpMethod.Post, tokenUrl);

req.Content = new FormUrlEncodedContent(new Dictionary<string, string>
{
    ["grant_type"] = "password",
    ["client_id"] = "23d3be1b-a671-4452-a928-78fb842cb969",
    ["client_secret"] = "REDACTED",
    ["resource"] = "https://graph.windows.net",
    ["username"] = "[email protected]",
    ["password"] = "REDACTED"
});

using (var client = new HttpClient())
{
    var res = await client.SendAsync(req);

    string json = await res.Content.ReadAsStringAsync();
}

ADAL.NET не предоставляет перегрузку для выполнения этого AFAIK, поэтому вам нужно сделать это вручную, как это. Вам нужно будет заменить параметры учетными данными вашего приложения + учетными данными вашего пользователя, конечно. Для URL-адреса токена также требуется ваш идентификатор клиента или доменное имя. Измените параметр ресурса на URI идентификатора клиента/идентификатора приложения вашего API.

person juunas    schedule 06.09.2018

Под «не интерактивно» вы имеете в виду окно входа в систему? Если это так, учитывая описанный вами поток и архитектуру, это невозможно. Как еще вы могли бы получить учетные данные пользователей?

Вам следует использовать эту статью в качестве справочного материала при создании решения, чтобы вы понимали различные потоки и параметры OAuth 2.0, в том числе для собственного приложения.

https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-scenarios#native-application-to-web-api

person Mehdi Ibrahim    schedule 06.09.2018
comment
Но у меня уже есть учетные данные (имя учетной записи/пароль). Я просто не понимаю, что мешает мне получить токен не в интерактивном режиме, если я могу получить его с помощью неявного потока? - person UserControl; 06.09.2018
comment
для неявного потока по-прежнему требуется активный сеанс и проверка подлинности пользователя хотя бы один раз. Посмотрите, поможет ли вам этот ресурс: azure .microsoft.com/en-us/resources/samples/ - person Mehdi Ibrahim; 06.09.2018
comment
Спасибо, Мехди! К сожалению, ни один из сценариев у меня не сработал - первому нужна пользовательская сессия, второму нужна доменная среда :( - person UserControl; 06.09.2018
comment
Другой мыслью было бы создать простой тест пользовательского интерфейса, закодированный в Visual Studio, для автоматизации заполнения учетных данных и вашего тестирования. - person Mehdi Ibrahim; 06.09.2018
comment
Хорошая идея, спасибо! Мне, вероятно, потребуется сделать учетные записи пользователей, под которыми будут работать мои агенты CI, интерактивными. - person UserControl; 06.09.2018
comment
@MehdiIbrahim Кажется, вы не слышали о потоке предоставления учетных данных владельца ресурса, который существует именно для этой цели. У него есть свои ограничения, но лично я использую автоматизированное тестирование API. - person juunas; 06.09.2018
comment
@juunas, пожалуйста, расскажите, как реализовать это с помощью Azure. - person Mehdi Ibrahim; 06.09.2018
comment
Я добавил ответ :) - person juunas; 06.09.2018
comment
спасибо juunas, @UserControl, пожалуйста, попробуйте альтернативное предложение, чтобы увидеть, решит ли оно вашу проблему - person Mehdi Ibrahim; 06.09.2018