Управление доступом является одной из основных частей безопасности веб-приложения. Контроль доступа гарантирует, что только аутентифицированные и авторизированные лица могут иметь доступ к конфиденциальной информации, и только пользователь с допустимой ролью может выполнять предоставленные ему действия. Формирование ролей призвано определить чёткие и понятные для пользователей информационной системы правила разграничения доступа. Ролевое разделение позволяет реализовать гибкие, изменяющиеся динамически в процессе функционирования приложения правила разграничения доступа[1].
Рассмотрим несколько способов реализации системы управления доступом в корпоративном Java-приложении.
Первый способ реализации предполагает ограничение доступа к частям проекта. Кроме этого накладывается ограничение на число неудачных попыток входа в систему, после чего аккаунт блокируется на определённый временной промежуток, что затруднит применение метода «грубой силы» (brute force[2]). Реализуется класс менеджера пользователей, который должен обеспечивать добавление, удаление, изменение и чтение учетной записи пользователя, проверку на существование логина пользователя и выполнение входа пользователя в систему. В классе информации о пользователе необходимо сделать неизменяемыми идентификатор пользователя и логин. Этот класс также должен содержать регистрационную информацию о пользователе (обязательно логин/пароль и роль пользователя) и время его последнего входа. Также необходимо хранить информацию о числе неудачных попыток аутентификации и о времени/дате снятия блокировки с учетной записи пользователя, если он заблокирован. Необходимо реализовать фильтр, ограничивающий доступ к URL-адресам сайта в соответствии с заданными ограничениями. Ограничения должны задаваться в файле XML[3], путь к которому будет указываться в конфигурационных параметрах приложения. При наложении ограничений безопасности необходимо выбрать, какие ресурсы защищать, задав ограничения с шаблоном URL и ролями, которым запрещено посещать указанную часть сайта. Фильтр должен перехватывать все приходящие от клиента запросы. Если URL запроса HTTP и роль пользователя соответствуют шаблону и указанной роли в ограничении, доступ к ресурсу ограничивается.
Альтернативный способ заключается в применении защиты на уровне методов контроллера, используя поддержку аннотаций[4]. Будет проводиться проверка прав пользователя для выполнения методов, над которыми стоит аннотация. Функция, над которой стоит аннотация, будет выполняться только если у пользователя (текущего потока выполнения) есть права, указанные в параметре аннотации. Возможен вариант, когда аннотируется весь класс. Тогда все методы класса нуждаются в соответствующих правах, и мы можем переопределить те методы, на выполнение которых требуются особые права. Объект, который конфигурируется с помощью аннотации, создаётся с помощью фабрики-контейнера, потому что, создавая объект с помощью оператора new, пришлось бы произвести дополнительные действия для проверки прав пользователя.
Предложенные способы управления доступом должны выбираться в зависимости от требований предметной области и не всегда являются взаимозаменяемыми. Безопасности, основанной на URL-адресах, оказывается недостаточно, когда несколько ролей имеет доступ к одному и тому же ресурсу (URL-адрес), но при этом роли должны выполнять различные действия. Для подобного сценария необходимо реализовать более тонкую политику безопасности, применяя различные права доступа к различным частям ресурса.
В работе были рассмотрены несколько способов проектирования политики управления доступом, которые были основаны на URL-адресах и вызове методов контроллера, а также случаи, в которых определённые способы лучше всего применимы.
Список источников:
1. en.wikipedia.org/wiki/Role-based_access_control
2. www.techopedia.com/definition/18091/brute-force-attack
3. www.w3.org/XML
4. tutorials.jenkov.com/java/annotations.html
