Как указать разрешения в пользовательской политике согласия приложения?

ProgramBox

Как указать разрешения в пользовательской политике согласия приложения?

Post author:admin
Запись опубликована:10 февраля, 2023
Post category:Вопросы по программированию

#azure #azure-active-directory

Вопрос:

Я успешно создал пользовательскую политику согласия приложений, используя New-AzureADMSPermissionGrantConditionSet документы MS docs и следуя им. Я указал ClientApplicationIds , и это отлично работает.

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

Мне нужна помощь в понимании (и доступе) идентификаторов разрешений в «свойстве OAuth2Permissions объекта ServicePrincipal API».

На какой ServicePrincipal ссылается документ? Разрешения в домашнем клиенте приложения или в клиенте, использующем приложение? Если на приложение еще не получено согласие, значит, в клиенте, использующем приложение, нет ServicePrinciple, поэтому у меня проблема с курицей и яйцом.

И какие разрешения я ожидаю получить? Мне интересно, почему MS просто не позволила нам передавать области в виде строк email mail.read , например, и т.д. Я не совсем понимаю, каковы разрешения в данном конкретном контексте.

1. Участник службы, на который он ссылается, является участником службы для API. (Например, Microsoft Graph или ваш собственный пользовательский API.) На самом деле у вас нет проблемы с курицей и яйцом, потому что, если участник службы API не существует в клиенте, вход в систему все равно завершится неудачно, независимо от того, может ли пользователь дать согласие. Я добавил еще один ответ, показывающий, как получить идентификаторы разрешений с помощью Azure AD PowerShell на основе значений строковых утверждений.

Ответ №1:

Мне нужна помощь в понимании (и доступе) идентификаторов разрешений в «свойстве OAuth2Permissions объекта ServicePrincipal API».

Идентификатор разрешения означает id делегированное разрешение API (т. Е. oauth2Permissions Определенное в API), Которое вы добавили при регистрации клиентского приложения.

Например, вы создали клиентское приложение с несколькими арендаторами в клиенте A, добавили Mail.Read делегированное разрешение Microsoft Graph, по умолчанию User.Read делегированное разрешение также будет автоматически, поэтому в вашем клиентском приложении всего два разрешения API permissions .

Теперь вы хотите использовать пользовательскую политику согласия приложений в клиенте B, вы хотите, чтобы пользователь дал согласие на два разрешения, тогда -Permissions должно быть одно id из двух разрешений, определенных в Microsoft Graph, чтобы легко найти его, просто перейдите к клиентскому приложению в клиенте A -> Manifest , затем вы можете получитькак id показано ниже.

Полная команда должна быть

 New-AzureADMSPermissionGrantConditionSet `
    -PolicyId "joy-custom-policy" `
    -ConditionSetType "includes" `
    -PermissionType "delegated" `
    -ResourceApplication "00000003-0000-0000-c000-000000000000" `
    -Permissions @("e1fe6dd8-ba31-4d61-89e7-88639da4683d","570282fd-fa5c-430d-a7fd-fc8dc98a9dca")

В другом сценарии вы используете пользовательский API (созданный в клиенте A) в клиентском приложении вместо API Microsoft.

Если это так, сначала вам нужно предоставить согласие администратора для приложения API в клиенте B, иначе вы получите сообщение об ошибке The app needs access to a service ("api://tenantA/myapi") that your organization (tenant B) has not subscribed to or enabled , или вы можете использовать учетную запись администратора для запуска New-AzureADServicePrincipal -AppId <appid of the API app> в клиенте B, это также будет работать, после согласия обычный пользователь сможет дать согласие на разрешение, определенное вполитика.

Примечание: Иногда вы можете получить сообщение об ошибке This app may be risky , подобное приведенному ниже.

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

1. Фантастика, спасибо за подробное объяснение Радости. При наличии нескольких разрешений, как в вашем примере, как я могу просмотреть детали, чтобы узнать, что есть что? В любом случае, я уже запущен. Спасибо. Кстати, я никогда раньше не нажимал на манифест! Какая полезная вкладка. 🙂

2. @TrevorJ Вы можете получить идентификатор объекта участника-службы API в клиенте, а затем использовать (Get-AzureADServicePrincipal -ObjectId xxx).Oauth2Permissions , вы найдете их в результате.

Ответ №2:

Вот пример того, как можно получить идентификаторы разрешений для трех делегированных разрешений для Microsoft Graph с помощью Azure AD PowerShell:

 # The appId for the client application
$clientAppId = "{client-app-id}"

# The claim values for the Microsoft Graph delegated permissions to include
$claimValues = @("User.Read", "Mail.Send", "User.ReadBasic.All")

# Get the service principal for Microsoft Graph
$resource = Get-AzureADServicePrincipal -Filter "servicePrincipalNames/any(n:n eq 'https://graph.microsoft.com')"

# Get the delegated permission IDs for the given claim values
$permissionIds = $resource.OAuth2Permissions `
  | ? { $claimValues.Contains($_.Value) } | select -ExpandProperty Id

# Use these permission IDs in a condition set for a custom permission grant policy
New-AzureADMSPermissionGrantConditionSet `
    -PolicyId "my-custom-policy" `
    -ConditionSetType "includes" `
    -ClientApplicationIds @($clientAppId) `
    -PermissionType "delegated" `
    -ResourceApplication $resource.AppId `
    -Permissions $permissionIds