Как обрабатывать разрешения в приложении с помощью единого входа Azure AD? - PullRequest
1 голос
/ 05 июня 2019

Первый проект, работающий как с единым входом, так и с Azure, так что, возможно, я просто делаю это неправильно.Перед использованием SSO я сам сгенерировал бы токен.Это позволило мне поместить все, что я хотел, в токен, который я использовал бы для определения разрешений.При использовании response-adal с Azure AD SSO токен генерируется на стороне клиента, и все, что я получаю, - это идентификатор пользователя.Следуя тому, что я делал в прошлом, я написал собственный атрибут, чтобы гарантировать, что у пользователя есть соответствующие разрешения для вызова API.Но вместо того, чтобы просто извлекать информацию из токена, который передается с каждым запросом, я должен запрашивать разрешения каждый раз, когда они делают запрос, по сути, удваивая хиты базы данных.

Есть ли способ для меня обработатьроли / разрешения (администратор, менеджер, пользователь, только для чтения и т. д.) с использованием разрешений единого входа и приложений, не запрашивая базу данных каждый раз, когда мне нужно проверить разрешения?

Предыдущий процесс: User visits site > enters credentials > server authenticates, gets permissions, generates token with permissions, returns it to client > client passes token on every request > server validates and parses token > attribute checks parsed token to ensure user has necessary permission > completes request

Текущий процесс: User visits site > client authenticates with Azure AD and gets token > client passes token on every request > server gets authentication information from token > server queries database to get users permissions > attribute checks query results to ensure user has necessary permission > completes request

Как мне улучшить текущий процесс?Каждый найденный мною результат в Google покрывает только аутентификацию и недостаточно углубляется в реальное приложение, чтобы я мог найти «лучшую практику» или даже какую-либо практику.Я просто делаю это неправильно?

1 Ответ

1 голос
/ 05 июня 2019

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

Роли приложений

Документация Microsoft - Роли приложений

Назначение - Эти роли определены вМанифест приложения для приложения, которое разрабатывает ваша организация и которое зарегистрировано в Azure Active Directory.Эти роли очень специфичны для вашего приложения и могут использоваться в коде приложения для реализации логики авторизации для аутентифицированных пользователей.

Пример приложения (который использует эту концепцию и выполняет то, что вы ищетеfor) -

Авторизация в веб-приложении с использованием ролей приложений Azure и утверждений о ролях

Краткое объяснение

1)После регистрации приложения в Azure AD вы можете определить пользовательские роли (специфичные для вашего приложения), отредактировав манифест приложения (JSON) в Azure AD.
Вот пример JSON того, как будет выглядеть определение роли приложения:

"appRoles": 
[
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Creators can create Surveys",
    "displayName": "SurveyCreator",
    "id": "1b4f816e-5eaf-48b9-8613-7923830595ad",
    "isEnabled": true,
    "value": "SurveyCreator"
  },
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Administrators can manage the Surveys in their tenant",
    "displayName": "SurveyAdmin",
    "id": "c20e145e-5459-4a6c-a074-b942bbd4cfe1",
    "isEnabled": true,
    "value": "SurveyAdmin"
  }
]

2) Вы сможете назначать эти роли пользователям / группам / приложениям через портал Azure или программно.(вы можете контролировать разрешенные типы элементов для ролей)

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

if (context.User.HasClaim(ClaimTypes.Role, "Admin")) { ... }

Вот еще одна связанная документация по документам Microsoft - Авторизация на основе ролей и ресурсов

Я вижу, вы также отметили asp.net-core в своем вопросе.Поэтому, если вы работаете с основным приложением ASP.NET, вы можете использовать политики, как показано в разделе Авторизация на основе ролей приведенной выше ссылки.

public class SurveyCreatorRequirement : AuthorizationHandler<SurveyCreatorRequirement>, IAuthorizationRequirement
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, SurveyCreatorRequirement requirement)
    {
        if (context.User.HasClaim(ClaimTypes.Role, Roles.SurveyAdmin) ||
            context.User.HasClaim(ClaimTypes.Role, Roles.SurveyCreator))
        {
            context.Succeed(requirement);
        }
        return Task.FromResult(0);
    }
}

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

Группы

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

ПРИМЕЧАНИЕ : группы полностью независимы от вашего приложения, т. Е. Группы Azure AD могут и существуют, чтобы служить цели группирования членов, дажебез вашего заявления.Роли приложений, с другой стороны, очень специфичны для вашего приложения, они мало что значат для кого-либо, кроме вашего приложения.

Пример приложения, которое принимает решения на основе групп

Авторизация в веб-приложении с использованием групп и утверждений Azure AD


Индивидуальная или определенная авторизация на основе ресурсов

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

Я обсуждал это в соответствующей статье SO здесь - Авторизация на основе ресурсов с Azure AD

...