Самым первым шагом в обеспечении безопасности приложения Spring является добавление в сборку зависимости Spring Boot security starter. В рамках проекта pom.xml файл, добавьте следующее
запись <dependency>:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
Если вы используете набор инструментов Spring, это еще проще. Щелкните правой кнопкой мыши на pom.xml файл и выберите пункт изменить стартовые зависимости в контекстном меню Spring.
При запуске приложения авто конфигурация обнаружит, что Spring Security находится в пути к классу, и настроит некоторую базовую конфигурацию безопасности. Если вы хотите попробовать, запустите приложение и попробуйте посетить домашнюю страницу (или любую другую страницу, если на то пошло). Вам будет предложено пройти аутентификацию с помощью HTTP basic (диалоговое окошко проверки подлинности). Чтобы пройти его, вам нужно будет указать имя пользователя и пароль. Имя пользователя-user(По умолчанию). Что касается пароля, он генерируется случайным образом и записывается в файл журнала приложений (логи). Запись в журнале будет выглядеть примерно так:
Using default security password: 087cfc6a-027d-44bc-95d7-cbb3a798a1ea (рандомное значение, генерируется при каждом запуске)
Если вы правильно введете имя пользователя и пароль, вам будет предоставлен доступ к приложению. Похоже, что защита приложений Spring - довольно простая работа. Не делая ничего, кроме добавления стартера безопасности в сборку проекта, вы получаете следующие функции безопасности:
Все пути HTTP-запросов требуют аутентификации.
Никаких конкретных ролей или полномочий не требуется.
Нет страницы входа в систему.
Аутентификация запрашивается с помощью базовой аутентификации HTTP.
Есть только один пользователь; имя пользователя- user (опять же по-умолчанию).
Это хорошее начало, но я думаю, что потребности в безопасности большинства будет сильно отличаться от этих элементарных функций безопасности.
Вам предстоит еще много работы, если вы собираетесь должным образом защитить ваше приложение. Вам нужно будет, по крайней мере, настроить Spring Security, чтобы сделать следующее:
Запрос на аутентификацию с помощью страницы входа в систему вместо диалогового окна HTTP basic.
Предоставьте несколько пользователей и включите страницу регистрации, чтобы новые пользователи могли зарегистрироваться.
Применяйте различные правила безопасности для разных путей запроса.
Например, домашняя страница и страницы регистрации вообще не должны требовать аутентификации.
Чтобы удовлетворить ваши потребности в безопасности, вам придется написать некоторую явную конфигурацию, переопределяющую ту, что дала вам автоконфигурация. Вы начнете с настройки правильного хранилища пользователей, чтобы у вас было несколько пользователей.
На протяжении многих лет существовало несколько способов настройки безопасности Spring, включая длительную конфигурацию на основе XML. К счастью, несколько последних версий Spring Security поддерживают конфигурацию на основе Java, которая намного проще для чтения и записи.
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web .configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter; @Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter { }
Что эта конфигурация безопасности делает для вас? Ну, не очень много, но это действительно приближает вас на шаг ближе к функциям безопасности, которые вам нужны. Если вы снова попытаетесь зайти на домашнюю страницу, вам все равно будет предложено войти в систему. Но вместо того, чтобы запрашивать диалоговое окно HTTP basic authentication, вам будет показана форма входа в систему.
Личный совет: Переход в режим инкогнито: При ручном тестировании безопасности может оказаться полезным установить браузер в режим приватности или инкогнито. Это гарантирует, что у вас будет новый сеанс каждый раз, когда вы открываете окно. Вам придется каждый раз входить в приложение, но вы можете быть уверены, что все изменения, внесенные вами в систему безопасности, будут применены, и что нет никаких остатков более старого сеанса, мешающих вам видеть ваши изменения.
Это небольшое улучшение—запрос на вход с веб-страницы (даже если она довольно проста на вид) всегда более удобен для пользователя, чем диалоговое окно HTTP basic.
Как оказалось, Spring Security предлагает несколько вариантов настройки хранилища пользователей,
включая следующие:
Хранилище пользователей в памяти
Хранилище пользователей на основе JDBC
Хранилище пользователей с поддержкой LDAP
Пользовательская служба сведений о пользователе
Независимо от того, какое хранилище пользователей вы выберете, вы можете настроить его, переопределив параметр configure() метод, определенный в базовом классе конфигурации WebSecurityConfigurerAdapter. Чтобы начать работу, вы добавите следующее переопределение метода в класс SecurityConfig:
@Override
protected void configure(AuthenticationManagerBuilder auth)
throw Exception {
свой код……
}
Для краткости опишем только один метод хранения пользователей
Теперь вам просто нужно заменить эти многоточия кодом, который использует данный AuthenticationManagerBuilder, чтобы указать, как пользователи будут просматриваться во время аутентификации.
Одно из мест, где может храниться информация о пользователе, - это память. Предположим, у вас есть только несколько пользователей, ни один из которых, вероятно, не изменится. В этом случае может быть достаточно просто определить этих пользователей как часть конфигурации безопасности.
Например, в следующем списке показано, как настроить двух пользователей, "Gosha" и
"Gosha1", в хранилище пользователей в памяти.
@Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception
{ auth .inMemoryAuthentication()
.withUser("Gosha")
.password("1234")
.authorities("ROLE_USER") .and()
.withUser("Gosha1")
.password("0101")
.authorities("ROLE_USER");
}
Как вы можете видеть, AuthenticationManagerBuilder использует API в стиле конструктора для настройки деталей аутентификации. В этом случае вызов inMemoryAuthentication() метод дает возможность указать информацию о пользователе непосредственно в самой конфигурации безопасности.
Каждый вызов withUser() запускает конфигурацию для пользователя. Значение, заданное withUser(), является именем пользователя, в то время как пароль и предоставленные полномочия указываются с помощью методов password() и authorities (). Обоим пользователям предоставляются полномочия ROLE_USER. Пользователь Gosha настроен на использование 1234 в качестве пароля. Точно так же пароль Gosha1 - "0101".
Хранилище пользователей в памяти удобно для целей тестирования или для очень простых задач. приложения, но это не позволяет легко редактировать пользователей. Если вам нужно добавить, удалить или изменить пользователя, вам придется внести необходимые изменения, а затем перестроить и повторно развернуть приложение.
Для приложения вы хотите, чтобы клиенты могли регистрироваться в приложении и управлять своими собственными учетными записями пользователей. Это не соответствует ограничениям хранилища пользователей в памяти, поэтому следует использовать другой вариант, который позволяет использовать хранилище пользователей с поддержкой базы данных.
Это рассмотрим в другой раз.
