Ролевой контроль в приложении: вариант реализации

Привет! Меня зовут Валерия, я java-разработчик компании SimbirSoft. В этой статье я хочу рассказать об одном из способов реализации ролевого контроля над действиями пользователей в системе. Механизм ролевого контроля позволяет сделать бизнес-процессы надежными с точки зрения информационной безопасности и привести их в соответствие с внутренними регламентами организации. Задачи подобного рода так или иначе возникают на любом проекте. 

Есть несколько способов решения. Они зависят от проблематики, требований, доменной области, пожеланий заказчика и т.д. Возможные варианты реализации:

• Контроль доступа к методам через ldap группы из AD, проверяемые  в приложении: если пользователь входит в какую-то ldap-группу, то ему разрешены соответствующие действия.

• Контроль доступа к методам через группы ldap, рассматриваемые как роли пользователя, которые помещаются в SecureContext и становятся доступны механизмам SpringSecurity.

• Контроль доступа к эндпоинтам на основе внутренних ролей приложения (не обязательно завязанные на AD-группы).

• Контроль доступа (с ролями и без) к объектам приложения на базе AOP.

• Контроль доступа (с ролями и без) к объектам приложения на базе  Spring ACLs.

Однако довольно часто встречается комбинация методов, когда какие-то действия ограничиваются на уровне контроллера, какие-то на сервисном слое, а какие-то — в зависимости от объекта, который необходимо обработать. Мы рассмотрим такой вариант: роль приложения + ldap группа с ограничениями на уровнях контроллера и сервиса.

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

Авторизация в разрабатываемой системе идет через ldap, а права пользователя определяются через принадлежность к ldap-группе. То есть, сотрудник может работать в подразделении Управление, а иметь доступ к Складу, Охране и Бухгалтерии, если в ldap он состоит в соответствующих группах.

Архитектура разрабатываемой системы — MVC, то есть, созданы:

• репозиторий-сервис-контроллер для управления документами;

• репозиторий-сервис-контроллер для заявок;

• репозиторий-сервис-контроллер для статей.

На уровне контроллеров разделения по подразделениям нет, однако есть разделение по наличию роли администратора (роль приложения). Ограничение на доступ к эндпоинтам редактирования по роли стоит на уровне фильтров Spring Security через AuthorizationManagerRequestMatcherRegistry:

requestMatchers(HttpMethod.PUT, "/papers/**").hasAnyAuthority(“ADMIN”)

То есть put-запрос, выполняющий редактирование статей, доступен только пользователям с ролью администратора. Обратите внимание, здесь (и далее) используются именно authorities, хотя называются ролью.  

Используется стандартный rest-подход: для создания документа посылаем Post-запрос на конечную точку /docs, редактирование – put-запрос на /docs/{guid}, удаление – delete на /docs/{guid}. Со статьями и заявками то же самое. Со стороны интерфейса, естественно, стоит защита, что пользователь не может передать на обработку тот объект, к которому у него нет доступа. Однако по внутренним требованиям безопасности защита должна быть и от curl-запросов. То есть, ролевой контроль нужно сделать именно на сервисном слое.

Описанную проблематику можно нагляднее представить следующей схемой (на примере объекта Документ):

С точки зрения модели мы должны ввести некоторое поле, которое поможет сопоставить принадлежность документа и роли пользователя.  

Назовем это поле ldap-name и рассмотрим на примере DTO Документа, как это можно сделать:

DocumentDTO { @NotNull  DepartmentDTO department;}

DepartmentDTO { String ldap-name; }

Общая логика такова: метод вызывается авторизованным пользователем (то есть находящемся в SecureContext, а значит потенциально имеющим GrantedAuthority). В метод приходит DocumentDto с обязательно заполненным DepartmentDto. Нам необходимо, до попадания в метод, проверить, есть ли ldap-name из DepartmentDto Документа в списке ролей вызвавшего метод пользователя. Общая схема приведена на рисунке:

Мы видим классическую иллюстрацию для аспектного подхода: у нас есть валидационный метод, который мы привязываем к проверяемому перед его вызовом. В Spring Security для этой цели используется аннотация @PreAuthorize.

Для реализации описанной схемы нам необходимо сделать следующее: 

Первое. Реализовать IAuthService с методом получения ролей текущего пользователя (организацию перехода от полного наименования ldap-групп к ldap-name оставим за скобками, так как это отдельная тема). Приведем класс-реализацию сервиса:

@Service public class AuthUserServiceImpl implements IAuthService {     @Override     public Set<String> getMySecureRoles() {         Authentication authentication = SecurityContextHolder.getContext().getAuthentication();         AuthUserDetails authDitails = (AuthUserDetails) authentication.getPrincipal();         authDitails.getAuthorities();         return authDitails.getAuthorities().stream().map(e -> e.toString()).collect(Collectors.toSet());     } }

Возможный ответ метода:

[   "MONEY",   "SKLAD",   "CONTROL" ]

Второе. Сделать интерфейс и его реализацию для проверки возможности действия (приведем сразу второе).

@Component @RequiredArgsConstructor @Component("checkerBean") public class ActionCheckPermissionImpl implements IActionCheckPermission {      private final IAuthService authService;          private final DocRepo docRepo;          private final DoMapper docMapper;      @Override     public void checkPermission(Object object) {         String ldapName = "";         if (object instanceof DocumentDto doc) {             ldapName = doc.getDepartment).getLdapName0;         }         if (object instanceof Document doc) {             ldapName = doc.getDepartment.getLdapName;         }         if (lauthService.getMySecureRoles().contains(ldapName)) {             throw new AccessDeniedException("Access denied: you have not necessary role");         }         // do something ...     } }

Третье. В сервисном слое пометить аннотацией необходимые методы

public interface DocumentService {          @PreAuthorize("isAuthenticated()")     List<DocumentDto> getDocuments();      @PreAuthorize("hasAuthority('ADMIN')")     List<DocumentDto> getDocumentsForReview();      @PreAuthorize(“@checkerBean.checkPermission(#dto)”)     DocumentDto addDocument(@P(“dto”) DocumentDto dto);      @PreAuthorize(“@checkerBean.checkPermission(#dto)”)     List<DocumentDto> updateDocument(@P(“dto”) DocumentDto dto);      @PreAuthorize(“@checkerBean.checkPermission(@documentRepo.findById(id).get())”)     void deleteDocument(@P(“id”)UUID id); }

То есть, dto, пришедшее в метод может быть таким:
{ department : { ldap-name: “SKLAD”}}

Если getMySecureRoles() вернет пользователю вот такой список: [«MONEY»,  «SKLAD»,  «CONTROL»], проверка будет успешно пройдена. Если же вот такой — [«MONEY», «CONTROL»] возникнет AccessDeniedException.

За скобками осталось несколько моментов использования @PreAuthorize, которые необходимо подсветить.

Во-первых, не забыть поставить аннотацию @EnbleWebSecurity над основным приложением.

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

@Component(“checkerBean”) public class ActionCheckPermissionImpl implements IActionCheckPermission {   … }

В-третьих, через аннотацию @P явно указать имена используемых параметров.

В этой статье мы рассмотрели реализацию ролевого контроля действий над объектами (через @PreAuthorize). Из приведенного примера видно, что @PreAuthorize предназначен для простой и эффективной проверки доступа на основе аспектного подхода. Если доступ отклоняется, он просто предотвращает выполнение метода, передавая управление обработчику ошибок. Если же вам нужно более детальное управление валидацией с возможностью выбрасывания специфических исключений, можно использовать самостоятельную привязку валидационных методов через чистые аспекты.

Спасибо за внимание!

Больше авторских материалов для backend-разработчиков от моих коллег читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.