Цель использования allowAll() в аннотации PreAuthorize в Spring Security

Будучи новичком в структуре безопасности Spring, я хотел знать, почему мы используем @PreAuthorize("permitAll()") с методами? В документации сказано, что PermitAll всегда оценивается как true. (http://docs.spring.io/spring-security/site/docs/3.0.x/reference/el-access.html)

Кроме того, у меня есть изменение кода ниже. Разработчик вносит изменения из allowAll() в конкретную проверку разрешений. Что здесь подразумевается? Так как я не слишком уверен в том, как работает allowAll(), я не могу судить о логике изменения кода. Мне кажется, что разработчик добавляет определенные проверки разрешений и передает null в качестве объекта аутентификации. Может ли кто-нибудь объяснить, каково влияние явной передачи null в качестве объекта аутентификации? Получают ли пользователи, не прошедшие проверку подлинности, доступ, если у них есть конкретное разрешение «LUONTI» на целевой объект — «opetussuunnitelma»?

-    @PreAuthorize("permitAll()")
+    @PreAuthorize("hasPermission(null, 'opetussuunnitelma', 'LUONTI')")
     OpetussuunnitelmaDto addOpetussuunnitelma(OpetussuunnitelmaDto opetussuunnitelmaDto);

Спасибо. Любая помощь высоко ценится!


java security spring-security annotations spring-annotations
person Zack    schedule 25.06.2015    source источник

Ответы (2)


arrow_upward
7
arrow_downward

permitAll() делает именно то, что говорит. Он позволяет (разрешает) авторизовать сеанс любого пользователя (всего) для выполнения этого метода.

То, как Spring управляет своей аутентификацией и авторизацией, означает, что любой, кто заходит на ваш сайт, получает сеанс. Этот сеанс может быть анонимным или аутентифицированным (пользователь предоставил какие-либо учетные данные, и система приняла их). Альтернативы permitAll (например, hasPermission()) обычно проверяют аутентификацию пользователя, чтобы убедиться, что ему назначена какая-то роль или группа, прежде чем разрешить вызов аннотированного класса/метода.

Если используется permitAll(), это означает явно разрешить любому сеансу, анонимному или аутентифицированному, доступ к аннотированному методу.

Изменение кода, внесенное другим разработчиком, ограничило данный метод чем-то нестандартным. Взгляните на этот Spring — Expression- Контроль доступа на основе

person Dave Lugg    schedule 25.06.2015
comment
Если allowAll() разрешает все, то это равнозначно отсутствию проверки аннотаций. Итак, почему кто-то должен использовать его в первую очередь? - person Zack; 25.06.2015
comment
Кроме того, правильно ли моя интерпретация использования нуля в приведенном выше коде? - person Zack; 25.06.2015
comment
Я не уверен, почему в вашем коде это было с самого начала, но это может на самом деле отличается от отсутствия аннотации. Spring каскадирует аннотации @PreAuthorize, потому что они применимы и к классам. Если в классе присутствует аннотация @PreAuthorize, а в методе ничего нет, метод наследует классы @PreAuthorize. Он также мог бы сделать это с намерением быть явным (любой пользователь может использовать потенциально доступ к этому, не возвращая никакой конфиденциальной информации) - person Dave Lugg; 25.06.2015
comment
Может быть, режим по умолчанию не PermitAll, и поэтому вы должны явно указать это, используя аннотацию. Я ищу конкретные аргументы. - person Zack; 25.06.2015
comment
Не имея возможности увидеть всю конфигурацию пружины, будет практически невозможно дать вам конкретное обоснование ее наличия. Использование null означает, что реализация PermissionEvaluator, используемая для ваших вызовов hasPermission(), не заботится о каких-либо объектах Authentication (возможно, вместо этого она каждый раз извлекает их из сеанса). К сожалению, очень сложно дать вам явное обоснование, не видя ничего, кроме этой сигнатуры метода. - person Dave Lugg; 25.06.2015
comment
Вот ссылка на код, который я пытаюсь понять. github.com/Opetushallitus/eperusteet-ylops/commit/ - person Zack; 25.06.2015
comment
Похоже, вы правы, метод hasPermission в PermissionEvaluator всегда возвращает true, независимо от аутентификации. Но что будет, если разработчик не передаст null ? Я просто думаю, было ли использование null ненужным или нет - person Zack; 25.06.2015
comment
Я просмотрел код, и, помимо того, что я просто указал разрешения (что является веской причиной), я не могу найти конкретную, функциональную причину, стоящую за этим. Если вы передали фактическую аутентификацию в метод, реализованный PermissionEvaluator может исследовать предоставленную аутентификацию, чтобы определить, авторизован ли он для доступа к методу. - person Dave Lugg; 25.06.2015
comment
Давайте продолжим обсуждение в чате. - person Zack; 25.06.2015
comment
Иногда я использую permitAll на интерфейсах контроллера для принудительного создания прокси-объекта. - person Pijusn; 11.02.2016

arrow_upward
4
arrow_downward

Я чувствую, что никто на самом деле не дал вам то, что вы действительно хотели, что является примером использования "permitAll()".

Его можно использовать, когда вы ограничиваете весь свой класс или приложение определенным разрешением, например: @PreAuthorize("hasAuthority('USER')")

Здесь только клиенты, идентифицированные как те, кого вы определили как пользователя, могут иметь доступ к методам вашего класса.

Но в какой-то момент в вашем контроллере вы хотите, чтобы определенный метод был без разрешений, поэтому вы добавите @PreAuthorize("permitAll()") к своему методу, чтобы он переопределял глобальное разрешение.

Люди будут делать это, потому что безопаснее сначала защитить все с помощью блокировки с наивысшим разрешением, а затем протыкать дыры в сети (например, приложение/класс заблокированы для ADMIN, но большинство методов затем авторизованы для USER), чем наоборот. Потому что, если по умолчанию все разблокировано, в тот день, когда вы забудете заблокировать контроллер, у вас могут возникнуть проблемы с безопасностью.

person Echox    schedule 04.09.2018
comment
Очень полезный Echox, спасибо - person Julien__; 27.11.2020