Простой, безопасный контроль доступа на основе ролей (RBAC) для API REST

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

Разрешения на набор ролей

Управление разрешениями для пользователя может быть утомительной задачей, когда в нее вовлечено много пользователей. По мере добавления пользователей в систему поддержание прав пользователей становится все труднее и более подвержено ошибкам. Неправильное назначение разрешений может блокировать доступ пользователей к требуемым системам или, что еще хуже, разрешать неавторизованным пользователям доступ к закрытым областям или выполнять рискованные операции.

В этой статье я расскажу о том, как элегантно управлять доступом к приложениям RESTful. Существует много различных моделей управления доступом, таких как управление доступом на основе ролей (RBAC) и дискреционное управление доступом (DAC). Хотя принципы, описанные в документе, могут применяться к различным моделям, я выбрал RBAC в качестве справочного, поскольку он широко принят и очень интуитивен.

Немного о ролях

Управление доступом на основе ролей — это общий подход к управлению доступом пользователей к ресурсам или операциям. Разрешения точно определяют, к каким ресурсам и действиям можно получить доступ. Основной принцип заключается в следующем: вместо того, чтобы отдельно управлять разрешениями каждого пользователя, разрешения предоставляются ролям, которые затем назначаются пользователям или, что лучше, группам пользователей.

Разрешения на набор ролей

Управление разрешениями для пользователя может быть утомительной задачей, когда в нее вовлечено много пользователей. По мере добавления пользователей в систему поддержание прав пользователей становится все труднее и более подвержено ошибкам. Неправильное назначение разрешений может блокировать доступ пользователей к требуемым системам или, что еще хуже, разрешать неавторизованным пользователям доступ к закрытым областям или выполнять рискованные операции.

Просмотр действий пользователей обычно дает только ограниченное количество действий, которые выполняют пользователи (например, чтение данных, отправка форм). При более внимательном рассмотрении этих действий пользователя можно обнаружить, что некоторые действия, как правило, сочетаются друг с другом. Это означает, что пользователи, которые выполняют действие A, обычно также выполняют действие B. Например, чтение и обновление отчетов или удаление и добавление учетных записей. Затем их можно объединить в «роли», такие как «Редактор» или «Администратор учетной записи». Обратите внимание, что роли не обязательно связаны с должностями или организационной структурой, а скорее отражают соответствующие действия пользователя. Как только роли правильно определены и назначены каждому пользователю, разрешения могут быть назначены ролям, а не пользователям. Управление разрешениями для небольшого числа ролей — намного более легкая задача.

Как всегда, иллюстрация имеет большое значение:

Вот набор пользователей и их назначенные разрешения, связанные напрямую без ролей:

И вот, точно такой же набор пользователей и разрешений , организованный с ролями:

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

Группы Bundle Пользователи

Еще лучшая практика — это назначение ролей группам пользователей, а не отдельным пользователям.

При рассмотрении шаблонов действий пользователей в отношении ролей, приведенных выше, мы часто обнаруживаем, что между пользователями существует очень много общего, то есть группы пользователей, как правило, «ведут себя» одинаково — выполняют одинаковые операции с общими ресурсами. Это позволяет нам объединять пользователей в группы, а затем назначать роли только нескольким группам вместо множества пользователей. Следуя предыдущим примерам, вполне вероятно, что найдется несколько пользователей, которым требуется роль «Администратор учетной записи», поэтому мы можем создать группу с именем «Администраторы учетной записи», добавить пользователей в эту группу и назначить эту роль группе. каждого отдельного пользователя.

Реализация ролей — делай и не делай

Никогда не соединяйте действия и детали авторизации

Во многих системах разработчики ограничивают доступ к определенной операции, указывая разрешения непосредственно в методе реализации. Да, в коде! Как правило, проверка роли добавляется в защищенный метод, часто путем его аннотирования. Вот пример из кода на основе Spring Security:

@PreAuthorize("hasRole('Editor')")
public void update_order(Order order);

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

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

Как избежать сцепления?

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

Это позволило бы нам использовать общую аннотацию, такую ​​как эта:

@Secured
public void update_order(Order order);

Сопоставление ролей и разрешений (т. Е. Разрешения на выполнение определенного действия) теперь можно выполнить в файле конфигурации, который легко настраивается клиентами!

Например, рассмотрим этот файл role_config.yaml:

order_manager:
  - 'create_order'
  - 'view_order'
  - 'delete_order'
  - 'update_order'
order_inspector: 
  - 'viewer_order'

order_manager:
  '/orders':
    - 'GET'
    - 'POST'
    - 'PUT'
    - 'DELETE'
order_editor:
  '/orders':
    - 'GET'
    - 'POST'
    - 'PUT'
order_inspector:
  '/orders':
    - 'GET'