Как назначить роль новому пользователю с помощью Graph API
У меня есть приложение React и веб-API .NET 8 с собственными регистрациями приложений в клиенте внешнего идентификатора MS Entra. Аутентификация осуществляется с помощью msal-react, а на серверной стороне я использую Microsoft.Identity.Web.
Я хотел бы программно назначить роль пользователю после того, как он успешно зарегистрируется, поскольку некоторым конечным точкам веб-API требуется эта роль для аутентификации. Я просматривал документацию MS, но немного застрял в общей картине ее реализации.
В этой статье MS показан следующий код для отправки запроса на назначение роли через Graph API:
// Dependencies
using Microsoft.Graph.Models;
var requestBody = new AppRoleAssignment
{
PrincipalId = Guid.Parse("cde330e5-2150-4c11-9c5b-14bfdc948c79"),
ResourceId = Guid.Parse("8e881353-1735-45af-af21-ee1344582a4d"),
AppRoleId = Guid.Parse("00000000-0000-0000-0000-000000000000"),
};
// To initialize your graphClient, see https://learn.microsoft.com/en-us/graph/sdks/create-client?from=snippets&tabs=csharp
var result = await graphClient.Users["{user-id}"].AppRoleAssignments.PostAsync(requestBody);
Исходя из этого, мне нужно создать Graph Client с использованием OBO, который я нашел в этой статье MS, он выглядит так:
var scopes = new[] { "https://graph.microsoft.com/.default" };
// Multi-tenant apps can use "common",
// single-tenant apps must use the tenant ID from the Azure portal
var tenantId = "common";
// Values from app registration
var clientId = "YOUR_CLIENT_ID";
var clientSecret = "YOUR_CLIENT_SECRET";
// using Azure.Identity;
var options = new OnBehalfOfCredentialOptions
{
AuthorityHost = AzureAuthorityHosts.AzurePublicCloud,
};
// This is the incoming token to exchange using on-behalf-of flow
var oboToken = "JWT_TOKEN_TO_EXCHANGE";
var onBehalfOfCredential = new OnBehalfOfCredential(
tenantId, clientId, clientSecret, oboToken, options);
var graphClient = new GraphServiceClient(onBehalfOfCredential, scopes);
Итак, в моем коде веб-API мне нужно получить PrincipalId пользователя, ResourceId веб-API (где были созданы роли приложения) и AppRoleId, чтобы иметь возможность отправить запрос.
Я раньше не использовал Graph API, поэтому хотел проверить, правильный ли это способ сделать так, чтобы токен доступа для пользователя обновлялся/возвращался с новой ролью, добавленной в утверждение ролей, которое будет использоваться для успешного использования. поразить конечные точки, требующие указанную роль, когда пользователь делает к ней запрос.
Это выглядит правильно и/или я что-то упускаю? Я считаю, что мне, возможно, придется добавить еще одну область API Graph во второй фрагмент кода, но любые рекомендации будут полезны при навигации по этому интересному миру MS Graph.
Ответы 1
Ваш подход правильный для добавления ролей приложения пользователям.
Для второго фрагмента вам понадобятся дополнительные области действия, как описано в документации.
AppRoleAssignment.ReadWrite.All и Application.Read.All будут наименее привилегированной комбинацией.
Обратите внимание, что это применимо, если вы вызываете Graph API от имени пользователя; если вы хотите сделать это, используя только учетные данные приложения, потребуются разрешения приложения с теми же именами (вместо делегированных разрешений, т. е. областей).
Убедитесь, что ResourceId соответствует идентификатору объекта целевого субъекта-службы API.
Хорошо, у вас есть что-то вроде пользовательского интерфейса для назначения ролей? Что-то вроде: React UI -> API -> Graph API? Это совершенно нормально, но вам нужно будет использовать поток «от имени» в серверной части. Ваш второй фрагмент в настоящее время показывает, что он использует DeviceCodeCredential, который использует поток кода устройства. Вероятно, вы захотите использовать MSAL.js во внешнем интерфейсе (npmjs.com/package/@azure/msal-react). На серверной стороне вы можете использовать MSAL напрямую или библиотеку Microsoft.Identity.Web.
Дело не в том, что роли выбираются во внешнем интерфейсе (если вы это имели в виду), поскольку в настоящее время я хочу, чтобы любому пользователю была назначена одна роль при регистрации. Приношу свои извинения, я должен был сказать, что использую библиотеку msal-react и Microsoft.Identity.Web на серверной стороне. У меня было ощущение, что DeviceCodeCredential кажется неправильным, поскольку пользователь аутентифицируется при регистрации через приложение React, и после регистрации я хочу добавить конкретную роль к их утверждениям токенов, чтобы избежать ручного выполнения этого на портале. Значит, эта установка потребует потока OBO?
OBO требуется, когда у вас есть что-то вроде интерфейса -> серверная часть -> другой API. Серверная часть может использовать OBO для получения токена для другого API от имени пользователя, вошедшего во внешний интерфейс.
Аххх, окей. Таким образом, пользователь проходит аутентификацию в React, и возвращаемый им токен идентификатора предназначен для веб-API. Теперь веб-API необходимо, чтобы OBO отправил запрос в Graph API с информацией о пользователе. И как только роль назначена, отправляется ли пользователю новый токен для отправки в API с утверждением роли? В любом случае, большое спасибо за вашу помощь! Хотя я новичок в authn/authz, я несколько дней читал/делал статьи/документацию/тестировал, чтобы разобраться в этом, лол, и мне сказали, что это не ситуация с OBO, так что это должно меня подтолкнуть!
Да, токен идентификатора/токен доступа для приложения, в котором зарегистрирована роль, будет содержать его. Но имейте в виду, что существующие токены не будут обновляться немедленно, это произойдет после обновления токена.
О, это приятно знать. Таким образом, необходимо будет выдать новый токен доступа, чтобы пользователь мог успешно обращаться к защищенным конечным точкам API после того, как он зарегистрируется/получит назначенную роль, и если это так, я предполагаю, что токен обновления не может использоваться для этого (если только они не могут быть используется для более токенов с истекшим сроком действия)?
Хорошо, спасибо за совет, попробую. Правильно ли поток аутентификации/получения токена доступа пользователя -> перенаправляется на redirectUrl, который является компонентом React, который отправляет запрос на внутренний код с приведенной выше логикой API Graph? Я все еще новичок в authn/authz и помню, что читал что-то о том, что «redirectUrl должен быть пустой страницей», но, возможно, я неправильно помню и/или имею неправильное представление о вызове кода Graph API после регистрации пользователя, поскольку это похоже на дополнительный вызов API. от React до бэкэнда. Я могу задать еще один вопрос, и он будет длинным.