Доступ к MS Graph из API от имени пользователя, который в данный момент вошел в отдельный веб-клиент

Я разрабатываю API (ASP.NET Core), доступ к которому осуществляется через отдельно размещенный веб-клиент (React), оба размещены на Azure как службы приложений. Клиентское приложение должно иметь аутентификацию на основе Azure Ad (одиночный клиент, предпочтительно с защитой лазурной аутентификации на основе AAD). Когда пользователь входит в клиентскую систему, API должен иметь доступ к MS Graph от имени пользователя. Очевидно, что оба ресурса должны быть защищены, я пробовал использовать лазурную аутентификацию на основе AAD в обеих службах приложений, но мне не удалось получить токен для MsGraph в этом подходе с токеном, полученным из аутентификации в ADD на стороне API.

Вопрос в том, как избежать передачи токена в MsGraph с токеном для azure aad auth от клиента и получить токен для msGraph только на основе токена из aad auth, имея только одно место для входа пользователей и обеспечения безопасности обеих служб приложений?

Я использую самородок для MsGraph на стороне Api для взаимодействия с MsGraph. Я не нашел ни одного образца, относящегося к этому конкретному случаю.


azure azure-active-directory microsoft-graph-api azure-authentication asp.net-core-2.0
person winters0    schedule 11.12.2018    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Сценарий: веб-API вашего приложения (защищенный Azure AD) получает токен аутентификации от клиентского приложения (React) и должен вызывать подчиненный веб-API (Microsoft Graph) от имени вошедшего в систему пользователя.

Концептуальная документация в Microsoft Docs: ваш сценарий точно соответствует OAuth 2.0 от имени потока, как описано в Microsoft Docs для Azure AD здесь Вызовы обслуживания, которые используют делегированную идентификацию пользователя в On-Behalf -Flow

Примеры кода:

Важный код

Вот как вы используете уже переданный токен для получения нового токена, с помощью которого можно вызывать Microsoft Graph API из вашего веб-API от имени пользователя.

Подготовка утверждения пользователя:

ClientCredential clientCred = new ClientCredential(clientId, appKey);
var bootstrapContext = ClaimsPrincipal.Current.Identities.First().BootstrapContext as System.IdentityModel.Tokens.BootstrapContext;
string userName = ClaimsPrincipal.Current.FindFirst(ClaimTypes.Upn) != null ? ClaimsPrincipal.Current.FindFirst(ClaimTypes.Upn).Value : ClaimsPrincipal.Current.FindFirst(ClaimTypes.Email).Value;
string userAccessToken = bootstrapContext.Token;
UserAssertion userAssertion = new UserAssertion(userAccessToken, "urn:ietf:params:oauth:grant-type:jwt-bearer", userName);

Получение токена для Microsoft Graph:

 result = await authContext.AcquireTokenAsync(graphResourceId, clientCred, userAssertion);
person Rohit Saigal    schedule 11.12.2018
comment
Благодарю за ваш ответ! Я видел это раньше, я думаю, что не хватает того, как аутентифицировать пользователя на основе лазурной аутентификации с помощью aad, это также объясняется отдельно, но у меня возникают проблемы с объединением его в одно решение. Сценарий будет больше выглядеть: Пользователь попытался получить доступ к защищенному лазером веб-клиенту = ›Получает перенаправление для входа в систему с учетной записью Ms =› Насколько я понимаю, здесь идет поток obo Клиентское приложение отправляет запрос к API для доступа к ресурсам из msGraph = ›Azure аутентифицирует запрос =› Api получает токен msGraph, получает ресурс и отвечает < / b> - person winters0; 12.12.2018
comment
Я также пробовал использовать это: docs.microsoft.com/en-us/azure/app-service/ - person winters0; 12.12.2018

arrow_upward
0
arrow_downward

В итоге я использовал только Azure Ad + проверка подлинности по коду (без проверки подлинности Azure). API использует поток OBO, клиентское приложение использует неявный поток.

По сути, две отдельные регистрации приложений на aad, клиент, у которого есть разрешение access_as_user для api, и другой для api, который имеет разрешения для MsGraph. Вы настраиваете его в Регистрации приложений (предварительная версия) / разрешениях API. (Для подробного руководства следуйте приведенным ниже примерам, начните с api)

Для веб-клиента я также использовал области: 'access_as_user', 'offline_access', 'openid' в запросе токена, добавил true для «oauth2AllowImplicitFlow» в манифесте и перенаправил на yourdomainname.azurewebsites.com, остальная часть конфигурации аналогична собственный клиент в примере ниже.

Полезные ресурсы:

API:

https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2 https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-поток

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

Веб-клиент:

https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-implicit-grant-flow

Это решение, которое мне подходит на данный момент, возможно, его можно адаптировать лучше.

person winters0    schedule 16.12.2018