Проще говоря, Spring Security поддерживает семантику авторизации на уровне метода.
Как правило, мы можем защитить наш сервисный уровень, например, ограничив роли, которые могут выполнять определенный метод, и протестировать его с помощью специальной поддержки тестирования безопасности на уровне метода.
В этом руководстве мы рассмотрим использование некоторых аннотаций безопасности. Затем мы сосредоточимся на тестировании безопасности нашего метода с помощью различных стратегий.
В этом руководстве мы сосредоточимся на Spring Security Expressions и, конечно же, на практических примерах с этими выражениями.
Перед рассмотрением более сложных реализаций (таких как ACL) важно иметь четкое представление о выражениях безопасности, поскольку они могут быть достаточно гибкими и мощными при правильном использовании.
Чтобы использовать Spring Security, вам необходимо включить следующий раздел в файл pom.xml :
В этой статье мы узнаем, как использовать аннотации @PreFilter и @PostFilter для защиты операций в приложении Spring.
При использовании вместе с аутентифицированной основной информацией @PreFilter и @PostFilter позволяют нам определять подробные правила безопасности с использованием Spring Expression Language.
@PreFilter и @PostFilterПроще говоря, аннотации @PreFilter и @PostFilter используются для фильтрации списков объектов на основе определяемых нами пользовательских правил безопасности.
Список контроля доступа ( ACL) — это список разрешений, прикрепленных к объекту. ACL указывает, какие удостоверения предоставляются, какие операции над данным объектом.
Spring Security Access Control List — это компонент Spring , поддерживающий безопасность объектов домена. Проще говоря, Spring ACL помогает определить разрешения для конкретного пользователя/роли в одном объекте домена, а не повсеместно, на типичном уровне для каждой операции.
Например, пользователь с ролью администратора может видеть ( ЧИТАТЬ) и редактировать ( ЗАПИСАТЬ) все сообщения в центральном ящике уведомлений , но обычный пользователь может только видеть сообщения, относиться к ним и не может редактировать. Между тем, другие пользователи с ролью Редактор могут видеть и редактировать определенные сообщения.
Следовательно, разные пользователи/роли имеют разные разрешения для каждого конкретного объекта. В этом случае Spring ACL способен выполнить эту задачу. В этой статье мы рассмотрим, как настроить базовую проверку разрешений с помощью Spring ACL .
В этом руководстве мы сосредоточимся на создании пользовательского выражения безопасности с помощью Spring Security .
Иногда выражения, доступные в фреймворке , просто недостаточно выразительны. И в этих случаях относительно просто построить новое выражение, которое семантически богаче, чем существующие.
Сначала мы обсудим, как создать настраиваемый PermissionEvaluator , затем полностью настраиваемое выражение и, наконец, как переопределить одно из встроенных выражений безопасности.
В большинстве случаев при защите веб-приложения Spring или REST API инструментов, предоставляемых Spring Security, более чем достаточно, но иногда мы ищем более конкретное поведение.
В этом руководстве мы напишем собственный AccessDecisionVoter и покажем, как его можно использовать для абстрагирования логики авторизации веб-приложения и отделения ее от бизнес-логики приложения.
Чтобы продемонстрировать, как работает AccessDecisionVoter , мы реализуем сценарий с двумя типами пользователей, ПОЛЬЗОВАТЕЛЬ и АДМИНИСТР, в котором ПОЛЬЗОВАТЕЛЬ может получить доступ к системе только в четные минуты, в то время как АДМИНИСТРАТОР всегда будет иметь доступ.
В этой быстрой статье мы объясним тонкую, но существенную разницу между ролью и GrantedAuthority в Spring Security `` . Подробнее о ролях и полномочиях читайте в статье здесь .
Предоставленные полномочияВ Spring Security мы можем думать о каждом GrantedAuthority как об отдельной привилегии . Примеры могут включать READ_AUTHORITY , WRITE_PRIVILEGE или даже CAN_EXECUTE_AS_ROOT . Важно понимать, что имя является произвольным .