Меню

Как настроить spring security

Spring Security за 15 минут

Что вы сделаете?

Вы интегрируете web-app на Spring Boot с библиотекой Spring Security. Мы возьмем незащищенное приложение, которое мы разбирали в прошлой статье и защитим его с помощью Spring Security:

Что вам понадобится?

  • Около 15-50 минут
  • Ваш любимый текстовый редактор или IDE
  • JDK 1.8 или выше
  • Maven 3.0+

Как пользоваться этой статьей

  • Внимательно прочитайте статью
  • Скачайте исходный код с github
  • Запустите и проверьте работу
  • Удостоверьтесь что код вам понятен
  • Если что то осталось неясно, смело задавайте вопросы мне или google

Первичная настройка Spring-Security

Давайте представим, что нам хочется предотвратить неавторизованный доступ к страничке http://localhost:8080/hello. Сейчас если пользователь нажмет ссылку на базовой странице http://localhost:8080/base ничто не остановит его. Вы должны добавить какой то барьер который бы заставлял пользователя авторизоваться перед тем как увидеть эту страничку. Вы сделаете это сконфигурировав Spring Security. Если Spring Security находится в classpath Spring Boot автоматически защищает все HTTP-endpoints базовой(basic) авторизацией

В дальнейшем вы сможете более тонко настроить security. Первое что вам надо сделать это добавить Spring Security в classpath:

WebSecurityConfigurerAdapter

  • @EnableWebSecurity включает поддержку web security и обеспечивает интеграцию со Spring MVC
  • сonfigure(HttpSecurity) определяет какой URL нужно защищать, а какой не надо(по умолчанию все защищено)
  • .antMatchers(“/”, “/base”).permitAll() данные urls защищать не надо(.permitAll())
  • .loginPage(“/login”) определяется страница для совершения логина в приложение, которая доступна всем
  • .logout().permitAll() определяет что разлогиниться могут все
  • configureGlobal(AuthenticationManagerBuilder) устанавливает in-memory хранилище пользователей с одним пользователем

Создадим login-страницу

Добавим файл src/main/resources/templates/login.html с шаблоном thymeleaf в котором включим интеграцию со Spring-Security — thymeleaf-extras-springsecurity3

И не забудем добавить в MvcConfig для страницы логина натройку контроллера — registry.addViewController(“/login”).setViewName(“login”);

А также изменим страничку hello добавив туда ссылку для разлогинивания:

Мы показываем имя пользователя на страничке благодаря использованию интеграции со Spring Security HttpServletRequest#getRemoteUser() Ссылка “Sign Out” создаст POST запрос к “/logout” и далее переведет пользователя на “/login?logout”. Благодаря чему пользователь увидит это сообщение:

Как это устроено?

Эта простейшая авторизация работает благодаря HTTP_cookie. Рекомендую отследить момент до логина и после и посмотреть на состояние cookie с именем JSESSIONID. Вы увидете что после логина cookie не меняет значение. После разлогинивания это значение поменяется, что и будет означать что пользователь вышел из системы.

В chrome нажмите Ctrl-Shift-I -> Network tab и далее заголовки httml запроса

Тоесть как только пользователь залогинился Spring Security присваивает залогиненому пользователю отдельный JSESSIONID по которому он определяет его при последующих запросах. Это все похоже на работу сессий в сервлетах. Подробнее прочитайте вот эту ссылку how-does-spring-security-sessions-work

Источник



Добавление Spring Security в проект – настройки по умолчанию

В этой статье рассказывается, что будет, если добавить в проект Spring Security – какие настройки включатся по умолчанию.

Подготовка

Сгенерируем на https://start.spring.io/ Spring Boot приложение с зависимостью Web:

Напишем в нем единственный REST-контроллер:

Сейчас к нему имеют доступ все:

Доступный всем контроллер

Добавление Spring Security

Для того, чтобы включить Spring Security, достаточно добавить Maven-зависимость:

И сразу же мы столкнемся с неожиданностью. Теперь при попытке ввести в браузере http://localhost:8080/api/hello мы перенаправляемся на страницу логина http://localhost:8080/login. Если ввести в нее любые наугад взятые данные, получим ошибку:

Отсюда очевидно, что некая проверка выполняется. Но какая?

Что дает зависимость spring-boot-starter-security

Обычно включение любого стартера в POM-файл ничего не дает: чтобы что-то запрограммировать, все равно надо написать дополнительный код. В случае Spring Security все иначе.

Давайте заглянем в консоль. В ней видно, что генерируется некий пароль:

В консоли выдается сгенерированный пароль

Да, Spring Security создал некоего пользователя по умолчанию. Имя его user, а пароль генерируется автоматически при запуске программы.

Итак, что происходит при одном только добавлении spring-boot-starter-security в POM-файл:

  • Spring Security создает пользователя с именем user и автоматически сгенерированным паролем, который можно посмотреть в консоли.
  • Создается страница с формой для ввода имени и пароля -имеем Form-based аутентификацию.
  • Имя и пароль реально проверяются.
  • Все url оказываются недоступны, пока мы не “залогинимся” под этим пользователем.
  • И еще создается страница, где можно “разлогиниться”. Она находится по адресу logout. Выглядит так:

Страница “разлогина”

In-Memory аутентификация

С точки зрения получения параметров пользователя из запроса, продемонстрированная выше аутентификация является Form-Based – имя и пароль отправляются через форму и берутся на сервере из запроса как POST-параметры.

С точки зрения же хранения пользователей на стороне сервера, продемонстрированная выше аутентификация в Spring Security называется In-Memory authentication. Она означает, что пользователь хранится не в базе, не на LDAP-сервере и не где-либо еще, а в оперативной памяти приложения до тех пор, пока оно запущено. И чтобы отредактировать пользователя, придется заново запускать приложение. Разумеется, этот вариант не годится для среды Production, зато он прост и полезен для экспериментов во время разработки.

Как задать своего пользователя в In-Memory аутентификации

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

Но чтобы не подсматривать пароль в консоли, можно воспользоваться файлом настроек application.yml – зафиксировать имя/пароль там.

Переопределение пользователя и пароля в настройках

Для этого в настройках application.yml нужно задать свойства:

Теперь пароль не генерируется и в консоль не выводится – используется пользователь с именем и паролем, заданным в application.yml .

Можно задать и несколько пользователей – давайте сделаем это в коде. Перейдем наконец к написанию кода – напишем класс-конфигурацию для Spring Security и настроим в нем аутентификацию явно.

Настройка In-Memory аутентификации в коде

Итак, создадим класс SecurityConfig, который расширяет класс WebSecurityConfigurerAdapter. Сделаем его бином с помощью @EnableWebSecurity:

Аутентификацию выполняет AuthenticationManager, но определять этот бин явно нам не надо. Вместо этого надо переопределить метод configure(AuthenticationManagerBuilder auth) класса WebSecurityConfigurerAdapter – так мы получим доступ к билдеру AuthenticationManagerBuilder, а уж через него настроим нужный нам AuthenticationManager. Делается это так:

  • Во первых, в билдере надо задать тип аутентификации – она может быть не In-Memory, а другой: например, Jdbc, LDAP или кастомной (тип аутинтификации задает где в принципе хранится пользователь). У нас In-Memory аутентификация – этот факт задается строкой auth.inMemoryAuthentication().
  • Далее идут специфические настройки выбранного AuthenticationManager. В них уточняется, как AuthenticationManager извлекает хранимого пользователя, чтоб потом сравнить его с введенным. В случае In-Memory аутентификации менеджеру далеко ходить не надо, реальные имя и пароль задаются тут же с помощью withUser() и password():

На самом деле AuthenticationManager достает не только реальные имя и пароль, но еще разрешение пользователя (что ему разрешено делать в приложении). Мы задали двух пользователей с разрешением ROLE_USER. В данном примере разрешения не используются, мы будем их использовать в примере про авторизацию.

Итак, мы настроили AuthenticationManager, который сравнивает переданные имя и пароль со значениями имени и пароля u1 p1 и u2 p2. В случае совпадения с любым из пользователей, аутентификация проходит успешно.

Обратите внимание на бин PasswordEncoder – в нем задается, как шифровать пароль. Мы задали NoOpPasswordEncoder, который не делает ничего – оставляет пароль в первоначальном виде. Это выбрано в учебных целях, чтобы было наглядно, что требуется вводить в форму логина при запуске примера – ведь в методе password(“p2”) задается уже зашифрованный пароль. Конечно, в реальном приложении NoOpPasswordEncoder не пригоден – пароль нужно шифровать, например, с помощью BCryptPasswordEncoder.

Итоги

Таким образом, в примере мы вручную воспроизвели In-Memory аутентификацию, которая вообще-то предоставляется по умолчанию при добавлении security-стартера в проект. Правда, немного видоизменили ее, добавив двух своих пользователей.

Код примера есть на GitHub, в следующей статье настроим авторизацию.

Источник

Как настроить авторизацию в Spring Security

Продолжим тему аутентификации и авторизации в Spring Security.

Аутентификация – это проверка пользователя на то, является ли он тем, кем себя выдает. Приложение спрашивает “кто ты”, а пользователь, например, вводит имя и пароль. Приложение проверяет, что такому имени действительно соответствует такой пароль и отвечает ок, проверка пройдена.

Авторизация – это выдача прав (либо отказ). Происходит уже после того, как пользователь подтвердил свою идентичность. Допустим, пользователь прошел аутентификацию и хочет попасть на url:

Приложение проверяет, какие стоят права у данного пользователя, и либо впускает его, либо нет.

Например, user может зайти на url /user, а admin и на /user, и еще на другие url.

Подготовка

В прошлом примере мы настроили аутентификацию типа In-Memory, при которой пользователи хранятся в памяти приложения. Пример простой и подходящий для демонстрации настройки авторизации.

Контроллер

Но для того, чтобы настроить права (для двух пользователей), дополним контроллер еще парой методов. Итак, пусть будут две роли USER и ADMIN, а также три URL:

Контроллер теперь имеет три URL:

Пользователи (In-Memory athentication)

А настройка аутентификации (см. предыдущий пример) выглядит теперь так:

Теперь мы ввели два разрешения ROLE_USER и ROLE_ADMIN, а в прошлом примере было одно.

Вот теперь разрешения нам пригодятся – для настройки авторизации.

Настройка авторизации

Чтобы настроить авторизацию, надо точно так же, как мы делали при настройке аутентификации, переопределить метод configure(), только теперь с другим аргументом HttpSecurity:

Именно этот объект HttpSecurity и нужно настраивать. Создавать его как бин не надо, его создает Spring Security, а мы получаем к нему доступ из метода configure(HttpSecurity http).

Как мы видели в прошлой статье, по умолчанию Spring Security дает доступ к любому url любому аутентифицированному пользователю. Иначе говоря, если хочешь попасть на url, перенаправляешься на форму ввода пароля, и только после этого попадаешь на url.

Переопределив метод configure(HttpSecurity http), мы немедленно отменили поведение по умолчанию. Теперь внутри переопределенного метода все требуется задать заново вручную (с небольшими нововведениями).

Мы по очереди перечисляем возможные url и задаем права доступа к ним (точнее, в нашем примере – роли).

Перечисление url

Это строкой мы говорим предоставить разрешения для следующих url.

Далее мы перечисляем не сами url (поскольку их может быть слишком много), а шаблоны. Шаблоны url задаются с помощью класса AntPathRequestMatcher .

Перечислять шаблоны надо в порядке от самых узкоохватывающих до широкоохватывающих:

Например, следующие три url подпадают под шаблон /admin/**:

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

Настройка доступа (роли, разрешения)

Наконец, к главному. После шаблона в каждой строке указывается кому разрешен доступ: всем пользователям (метод permitAll() разрешает доступ всем, в том числе неаутентифицированным пользователям) или пользователям с определенной ролью – метод hasRole(“ADMIN”) (либо ролями).

Обратите внимание, что в настройках аутентификации в начале статьи мы задавали пользователям разрешение с префиксом ROLE. А в настройках авторизации доступ определяем через роль. Роль идет без префикса ROLE, таково соглашение.

Можно было задать доступ с помощью разрешений, результат был бы аналогичный:

Еще такой есть полезный метод:

Страница ввода пароля

Наконец, страница логина теперь генерироваться не будет, чтобы ее вернуть, допишем строку:

Если пользователь не аутентифицирован (в данном случае так будет, если в запросе либо отсутствует кукис JSESSIONID, либо он неправильный), то выполняется редирект на страницу ввода логина и пароля.

Ввод логина и пароля в форму считается аутентификцией типа Form-Based, что означает, что имя и пароль приходят в POST-запросе в параметрах username и password (такие имена параметров по умолчанию используются в Spring Security). То есть когда пользователь попадет на страницу логина и введен туда данные, на сервер пойдет новый запрос, в котором данные будут передаваться в этом самом POST.

Чтобы задать аутентификацию типа Http Basic, строка в коде должна быть такая:

В этом случае браузеру придет ответ с требованием показать нативную браузерную форму, куда пользователь так же вводит данные. Но эти данные в случае Http Basic –аутентификации передаются уже в другом виде – в заголовке:

Это устаревший и небезопасный способ.

Но суть в том, что обе эти строки указывают Spring Security, как именно он должен брать из запроса имя пользователя и пароль.

Итоги

Пример доступен на GitHub.

Также см. тут как защитить конкретные методы с помощью @Preauthorize.

Как настроить авторизацию в Spring Security: 13 комментариев

Здравствуйте, подскажите, пожалуйста, как со всеми аналогичными настройками авторизоваться через постман? json с передачей username и password в формате json (raw) и через form-data не сработали. Возвращается всегда 403

1) Надо отключить csrf в configure(HttpSecurity http) (так как из браузера он с формой передается, а из POSTMAN – нет):
http.csrf().disable();
2) ну и перeдавать в POST-запросе localhost:8080/login form-data, к примеру такие:
username: user
password: password

Спасибо! Помогло 🙂 Еще вопрос: мне нужно чуть усложнить приложение, чтобы пользователь имел доступ на редактирование только созданных им объектов. Соответственно, роль будет по-прежнему юзер, но ограничениями доступа к “чужим аккаунтам”. Предполагаю, что это можно решить как-то средствами группового разграничения доступа, но пока не получилось найти адекватный источник реализации этого всего добра. Можете натолкнуть на мысль?

Можно сделать авторизацию на уровне методов, например, если пользователь приложения AppUser может редактировать только свой объект Thing, то аннотируем метод редактирования так:

@PreAuthorize(«authentication.principal.username.equals(#thing.appUser.username)»)
public Thing editThing(Thing thing) <
//.
>
(подразумевается, что Thing имеет ссылку на юзера)

Есть также Spring Security ACL – мощная вещь (но возможно избыточная, нужно создавать обязательные таблицы и т.д.)

Я так понимаю, в контроллере использовать @PreAuthorize не выйдет? Нужно вынести куда-то в отдельный класс? Потому что вот так у меня не сработало (хотя блог с юзером связаны) Запрос выполнился даже не связанный:
@PutMapping(“/blog/”)
@PreAuthorize(“authentication.principal.username.equals(#blog.user.username)”)
public ResponseEntity updateBlog(@PathVariable int id, @Valid @RequestBody Blog blog) throws EntityNotFoundException <
ModelMapper mapper = new ModelMapper();

if (!blogRepository.findById(id).isPresent())
throw new EntityNotFoundException(“The blog with + id + ” doesn’t exist”);
Blog blogToUpdate = blogRepository.getOne(id);
blogToUpdate.setTitle(blog.getTitle());
blogToUpdate.setContent(blog.getContent());
blogRepository.save(blogToUpdate);
return ResponseEntity.ok().body(mapper.map(blogToUpdate, BlogDto.class));
>

1. Возможно не включили @EnableGlobalMethodSecurity(prePostEnabled = true) на главном классе.
2. @PreAuthorize рекомендуется ставить на методы сервисов

Вы очень понятно объясняете, спасибо большое за ваш труд!
2 связанных вопроса:
1. Откуда в конфиге вытаскивается информация о наличии у юзера определенной роли hadRole? Я использую jwt token, по вашему примеру делала фильтр, чтобы токен при запуске апп.проверялся, обновлялся (дата продлевается) и заново ложился в хедер реквеста перед возвратом в чейн – и дальше уже в контроллер

2. Допустим, в jwt токен есть роли в authorities. Что срабатывает раньше: наш конфиг со своими hadRole, или фильтр? А то выходит, фильтр мне обновит токен (дату, и вытащит в токен актуальные роли из бд с помощью userDetails), но секьюрити конфиг сработает раньше фильтра и не будет знать, что юзер уже админ, например

уточните, пожалуйста, что вы имеете в виду под “конфиг где вытаскивается информация о наличии у юзера определенной роли hadRole”?
В методе configure(AuthenticationManagerBuilder auth) указаны два In-Memory пользователя user и admin с ролями, но если у вас база, то этих пользователей в этом методе не должно быть. Они созданы как замена реальным для демонстрации примера.
P.S. их можно считать аналогом пользователей из базы, но только они пересоздаются каждый раз при перезапуске приложения в том же виде.

Подскажите, использую микросервисную архитектуру, и авторизация выполняется на другом сервере. У пользователя есть два токена. Токен досупа и refresh токен. Второй устаревает каждый 3 минуты. За его обновлением следит свой сервис.
Для доступа к основыным сервсам приложения пользователь в базовой аутентификации передает логин и пароль. Логи это токен доступа… пароль… refreshToken. Так как второй все время обновляется то компроментация ему не страшна.
Но есть пролблем. Спринг хеширует авторизацию. И при повторных запросах уже не проверяет ее если установлен куки JSESSIONID.
А так как токен устаревает, то проверять надо при каждом доступе к серверу.
Сейчас у меня такие настройки Spring Security

@Override
protected void configure(HttpSecurity http) throws Exception <
http
.csrf().disable()
.authorizeRequests().anyRequest().authenticated()
.and().httpBasic()
.and().sessionManagement().disable()
.logout().deleteCookies(“JSESSIONID”).permitAll();

http.addFilterAfter(
new CustomFilter(), BasicAuthenticationFilter.class);

Подскажите, может еще надо что то дописать, чтоб каждый запрос проходил процедуру авторизации?

В декомпилированном BasicAuthenticationFilter нашел вот такой метод private boolean authenticationIsRequired(String username) <
Authentication existingAuth = SecurityContextHolder.getContext().getAuthentication();
if (existingAuth != null && existingAuth.isAuthenticated()) <
if (existingAuth instanceof UsernamePasswordAuthenticationToken && !existingAuth.getName().equals(username)) <
return true;
> else <
return existingAuth instanceof AnonymousAuthenticationToken;
>
> else <
return true;
>
>

тут он как раз проверяет необходимость повторной авторизации. Но как это мне поможет не понимаю.

Что касается сессий: попробуйте их таким образом отключить:
http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS); (вместо .and().sessionManagement().disable())

Спасибо! Помогло!
У меня токен обновления живет 3 минуты. Может мне не отключать совсем сессию, а сделать у нее таймаут, пару минут. Чтоб уменьшить нагрузку на сервис авторизации?

Источник

Читайте также:  Как настроить приложение cube acr