Разница в лазурном объявлении между авторизацией на основе группы и авторизацией на основе ролей

Привет, недавно я начал работать над лазурной рекламой. Я начал работать над авторизацией для своего API ядра .net. У меня есть нижеследующее понимание ролей и групп в лазурной рекламе.

Группы Azure AD. Группы ничего, кроме группировки пользователей, относятся к одному делу. Один пользователь может принадлежать к нескольким группам. Каждый раз, когда добавляется новый пользователь, мы можем связать пользователя с разными группами.

Авторизация на основе групп Azure AD для ядра .net у нас будет API для нашего основного приложения .net. Таким образом, объединив указанные выше группы объявлений Azure и мое основное приложение .net, мы можем получить авторизацию на основе plociy. Например, некоторые группы могут получить доступ к нескольким API. Например,

services.AddAuthorization(options =>
            {   
                options.AddPolicy("GroupsCheck", policy =>
                {
                    policy.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);
                    policy.RequireAuthenticatedUser();
                    policy.Requirements.Add(new GroupsCheckRequirement("group id"));
                });
            });

Поэтому всякий раз, когда у меня есть [Authorize (Policy = "GroupsCheck")] поверх контроллера, только если пользователь принадлежит соответствующему идентификатору группы, он будет иметь доступ к этим API.

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

это мое понимание. Пожалуйста, поправьте меня, если я неправильно понимаю.

Теперь мое замешательство начинается здесь.

Группы делают две основные вещи. Во-первых, мы можем выполнять авторизацию в нашем приложении .net, а затем мы можем группировать пользователей с помощью групп и назначать роли. Но что-то меня смущает, так это авторизация на основе ролей в основном приложении .net. RBAC в лазурном режиме - это детализированный доступ к разным пользователям / группам. Какая будет связь между RBAC в моем базовом приложении .net и лазурным.

Согласие администратора

Другое дело, например, что у меня есть роль пользователя лазурной рекламы, я создал базовое приложение .net и зарегистрировался в лазурной рекламе. Теперь моему приложению требуется доступ к графику Microsoft. Таким образом, чтобы предоставить Microsoft Graph доступ к моему клиенту приложения, администратор должен дать согласие. Например, чтобы прочитать все группы в клиенте, приложение должно вызвать Microsoft Graph. Это мое понимание согласия администратора.

Может ли кто-нибудь помочь мне правильно понять эти вещи? Любая помощь будет оценена по достоинству. Спасибо


azure azure-rbac .net azure-active-directory microsoft-graph-api
person Niranjan    schedule 12.01.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Какая будет связь между RBAC в моем базовом приложении .NET и Azure?

Роли Azure AD и роли приложений не связаны друг с другом. Есть способы сделать это (см. здесь), но это совершенно разные вещи. Роли Azure AD больше предназначены для управления доступом к ресурсам Azure и на самом деле не применяются к ролям конкретных приложений (т.е. в школьном приложении учащиеся не могут получить доступ к оценкам всего класса).

Итак, чтобы предоставить Microsoft Graph доступ к моему клиенту приложения, администратор должен дать согласие.

Это правда. Microsoft Graph в основном предоставляет API для доступа ко всему, что происходит внутри каталога. Естественно, поскольку есть конфиденциальная информация, требуется разрешение администратора.

person mmking    schedule 12.01.2020