Новое приложение Azure AD не работает, пока не обновлено через портал управления

Question

Я создал новое приложение в Azure AD с помощью API-интерфейса AAD Graph. ( код)

К сожалению, он не позволяет моему клиенту получить доступ к запрошенным ресурсам, пока я не зайду на страницу конфигурации приложения на портале управления Azure, внесу косметическое изменение и сохраню его. После удаления изменений и сохранения снова все работает. Файлы манифеста приложения перед изменением + изменение обратных шагов и после них полностью идентичны (как в diff.exe говорит, что они одинаковы).

При сравнении токенов JWT, возвращаемых при аутентификации приложения, он показывает, что токен доступа после изменения включает раздел "роли". Весь раздел "Роли" отсутствует в маркере доступа, возвращенном до сохранения приложения на портале управления.

Похоже, что портал управления Azure "что-то" делает с приложением при сохранении изменений. Вопрос в том, что это такое, и могу ли я сделать то же самое с помощью API AAD graph?

Answer 1

Было несколько вопросов. Некоторые ошибки во внутреннем интерфейсе Azure, которые теперь были исправлены, а также некоторые пропущенные вызовы API, которые я не знал, были необходимы. Благодаря некоторым очень полезным людям из службы поддержки MS мы смогли заставить его работать.

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

1. Создайте объект приложения.
2. Настройте RequiredResourceAccess для приложения, т.е. какие разрешения приложение имеет для API-интерфейса Graph Azure и т. д. Это то, что настраивается в настройках портала "разрешения для других приложений". Вы можете получить необходимые GUID, сконфигурировав разрешения вручную, а затем просмотрев файл манифеста AAD приложения.
3. Создайте субъект- службу для приложения.
4. Добавьте AppRoleAssignments к принципалу службы.

Последняя часть - это то, чего мне не хватало раньше. Даже если вы настроили RequiredResourceAccess для объекта приложения, субъекту службы все еще нужны AppRoleAssignments, чтобы фактически иметь разрешение на доступ к ресурсам.

При создании AppRoleAssignments немного сложно выяснить, какой PrincipalId назначить, поскольку это AAD ObjectId субъекта службы для другого ресурса.

Вот фрагмент для добавления AppRoleAssignment для доступа к API-графику Azure AD Graph. client является экземпляром ActiveDirectoryClient и sp является ServicePrincipal для моего приложения:

// find the azure ad service principal
var aadsp =
     client.ServicePrincipals.Where(csp => csp.AppId == "00000002-0000-0000-c000-000000000000")
     .ExecuteSingleAsync().Result;

// create the app role assignment
var azureDirectoryReadAssignment = new AppRoleAssignment
{
    PrincipalType = "ServicePrincipal",
    PrincipalId = Guid.Parse(sp.ObjectId), //
    Id = Guid.Parse("5778995a-e1bf-45b8-affa-663a9f3f4d04"), // id for Directory.Read
    // azure active directory resource ID
    ResourceId = Guid.Parse(aadsp.ObjectId) // azure active directory resource ID
};
// add it to the service principal
sp.AppRoleAssignments.Add(azureDirectoryReadAssignment);
// update the service principal in AAD
await sp.UpdateAsync();

По моему опыту, вам нужно немного подождать, может быть, 2-3 минуты, прежде чем вновь созданные объекты будут действительны в AAD, а затем вы сможете аутентифицироваться с помощью нового приложения.

Answer 2

Помимо ответа RasmusW выше, вам, возможно, придется сделать еще несколько вещей в зависимости от того, чего вы пытаетесь достичь.

1. Если вы хотите, чтобы делегированные разрешения работали, вам также нужно добавить Oauth2PermissionGrant в коллекцию Oauth2PermissionGrants на корневом уровне. Это должен иметь clientId SPN ObjectId вызывающего абонента, ResourceId ID объекта вызываемого SPN. Значение Scope объекта Oauth2PermissionGrant является ключевым. Он должен иметь разделенные пробелами значения. Каждое значение здесь берется из свойства 'Value' объекта Oauth2Permission в целевом SPN.
2. Кроме того, вам также может потребоваться быть в соответствующей директории, например, в читателях каталогов.