Предоставление согласия от имени одного пользователя с помощью PowerShell

Из этой статьи вы узнаете, как предоставить согласие от имени одного пользователя с помощью PowerShell.

Когда пользователь предоставляет согласие для себя, чаще происходят следующие события:

  1. Создается субъект-служба для клиентского приложения, если субъект-служба еще не существует. Субъект-служба — это экземпляр приложения или службы в клиенте Microsoft Entra. Доступ, предоставленный приложению или службе, связан с соответствующим объектом субъекта-службы.

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

  3. Пользователю назначается клиентское приложение. Назначение приложения пользователю гарантирует, что приложение отображается на портале Мои приложения для этого пользователя. Пользователь может просмотреть и отозвать доступ, предоставленный от своего имени на портале Мои приложения.

Необходимые компоненты

Чтобы предоставить согласие для приложения от имени одного пользователя, вам потребуется:

  • Учетная запись пользователя с администратором привилегированных ролей, администратором приложений или администратором облачных приложений

Прежде чем начать, запишите следующие сведения из Центра администрирования Microsoft Entra:

  • Идентификатор приложения, которому предоставляется согласие. В целях этой статьи мы называем его клиентским приложением.
  • Разрешения API, необходимые клиентскому приложению. Найдите идентификатор приложения API и идентификаторы разрешений или значения утверждений.
  • Идентификатор имени пользователя или объекта для пользователя, которому предоставлен доступ от имени.

В этом примере мы используем Microsoft Graph PowerShell для предоставления согласия от имени одного пользователя. Клиентское приложение — Microsoft Graph Explorer. Доступ предоставляется к API Microsoft Graph.

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

# The app for which consent is being granted. In this example, we're granting access
# to Microsoft Graph Explorer, an application published by Microsoft.
$clientAppId = "de8bc8b5-d9f9-48b1-a8ad-b748da725064" # Microsoft Graph Explorer

# The API to which access will be granted. Microsoft Graph Explorer makes API 
# requests to the Microsoft Graph API, so we'll use that here.
$resourceAppId = "00000003-0000-0000-c000-000000000000" # Microsoft Graph API

# The permissions to grant. Here we're including "openid", "profile", "User.Read"
# and "offline_access" (for basic sign-in), as well as "User.ReadBasic.All" (for 
# reading other users' basic profile).
$permissions = @("openid", "profile", "offline_access", "User.Read", "User.ReadBasic.All")

# The user on behalf of whom access will be granted. The app will be able to access 
# the API on behalf of this user.
$userUpnOrId = "user@example.com"

# Step 0. Connect to Microsoft Graph PowerShell. We need User.ReadBasic.All to get
#    users' IDs, Application.ReadWrite.All to list and create service principals, 
#    DelegatedPermissionGrant.ReadWrite.All to create delegated permission grants, 
#    and AppRoleAssignment.ReadWrite.All to assign an app role.
#    WARNING: These are high-privilege permissions!
Connect-MgGraph -Scopes ("User.ReadBasic.All Application.ReadWrite.All " `
                        + "DelegatedPermissionGrant.ReadWrite.All " `
                        + "AppRoleAssignment.ReadWrite.All")

# Step 1. Check if a service principal exists for the client application. 
#     If one doesn't exist, create it.
$clientSp = Get-MgServicePrincipal -Filter "appId eq '$($clientAppId)'"
if (-not $clientSp) {
   $clientSp = New-MgServicePrincipal -AppId $clientAppId
}

# Step 2. Create a delegated permission that grants the client app access to the
#     API, on behalf of the user. (This example assumes that an existing delegated 
#     permission grant does not already exist, in which case it would be necessary 
#     to update the existing grant, rather than create a new one.)
$user = Get-MgUser -UserId $userUpnOrId
$resourceSp = Get-MgServicePrincipal -Filter "appId eq '$($resourceAppId)'"
$scopeToGrant = $permissions -join " "
$grant = New-MgOauth2PermissionGrant -ResourceId $resourceSp.Id `
                                     -Scope $scopeToGrant `
                                     -ClientId $clientSp.Id `
                                     -ConsentType "Principal" `
                                     -PrincipalId $user.Id

# Step 3. Assign the app to the user. This ensures that the user can sign in if assignment
#     is required, and ensures that the app shows up under the user's My Apps portal.
if ($clientSp.AppRoles | ? { $_.AllowedMemberTypes -contains "User" }) {
    Write-Warning ("A default app role assignment cannot be created because the " `
                 + "client application exposes user-assignable app roles. You must " `
                 + "assign the user a specific app role for the app to be listed " `
                 + "in the user's My Apps portal.")
} else {
    # The app role ID 00000000-0000-0000-0000-000000000000 is the default app role
    # indicating that the app is assigned to the user, but not for any specific 
    # app role.
    $assignment = New-MgServicePrincipalAppRoleAssignedTo `
          -ServicePrincipalId $clientSp.Id `
          -ResourceId $clientSp.Id `
          -PrincipalId $user.Id `
          -AppRoleId "00000000-0000-0000-0000-000000000000"
}

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

Необходимо предоставить согласие на следующие разрешения:

Application.ReadWrite.All, , Directory.ReadWrite.AllDelegatedPermissionGrant.ReadWrite.All.

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

В примере корпоративное приложение ресурса — Microsoft Graph идентификатора aaaaaaaa-0000-1111-2222-bbbbbbbbbbbbобъекта. Microsoft Graph определяет делегированные разрешения User.Read.All и Group.Read.All. Тип согласия Principalуказывает, что вы даете согласие от имени одного пользователя в клиенте. Идентификатор объекта клиентского корпоративного приложения aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb. Основной идентификатор пользователя aaaaaaaa-bbbb-cccc-1111-222222222222.

Внимание

Будьте осторожны! Разрешения, предоставленные программным способом, не подлежат проверке или подтверждению. Они вступают в силу немедленно.

  1. Получение всех делегированных разрешений, определенных Microsoft Graph (приложением ресурсов) в вашем клиенте. Определите делегированные разрешения, которые необходимо предоставить клиентскому приложению. В этом примере разрешения делегирования имеют и User.Read.AllGroup.Read.All

    GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=displayName eq 'Microsoft Graph'&$select=id,displayName,appId,oauth2PermissionScopes
    
  2. Предоставьте делегированные разрешения клиентскому корпоративному приложению от имени пользователя, выполнив следующий запрос.

    POST https://graph.microsoft.com/v1.0/oauth2PermissionGrants
    
    Request body
    {
       "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
       "consentType": "Principal",
       "resourceId": "a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1",
       "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
       "scope": "User.Read.All Group.Read.All"
    }
    
  3. Убедитесь, что вы предоставили пользователю согласие, выполнив следующий запрос.

    GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants?$filter=clientId eq '00001111-aaaa-2222-bbbb-3333cccc4444' and consentType eq 'Principal'
    
  4. Назначьте приложению пользователю. Это назначение гарантирует, что пользователь может войти в систему, если это необходимо, и гарантирует, что приложение доступно на портале Мои приложения пользователя. В следующем примере представляет клиентское приложение, resourceIdкоторому назначается пользователь. Пользователь назначает роль приложения по умолчанию.00000000-0000-0000-0000-000000000000

        POST /servicePrincipals/resource-servicePrincipal-id/appRoleAssignedTo
    
        {
        "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
        "resourceId": "a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1",
        "appRoleId": "00000000-0000-0000-0000-000000000000"
        }
    

Следующие шаги