Spring Security/Конфигурирование с помощью пространства имён: различия между версиями

= Введение =

Конфигурирование с помощью пространства имен было доступно, начиная с версии 2.0 Spring Framework. Это позволило дополнить традиционный синтаксис бинов контекста приложения Spring'а элементами из дополнительных схем XML. Более подробную информацию можно найти в справочном руководстве Spring. Элементы пространства имен могут использоваться просто для более краткой настройки отдельных бинов или можно воспользоваться мощью альтернативного синтаксиса конфигурации, которая более точно соответствует предметной области и скрывает сложности, лежащие в основе фреймворка, от пользователя. Простой элемент может скрывать тот факт, что несколько бинов и этапов обработки будут добавлены к контексту приложения. Например, если добавить следующие элемент из пространства имен security в контекст приложения, то будет запускается встроенный LDAP сервер для использования в приложении в целях:

<security:ldap-server />

Это гораздо проще, чем настраивать зависимости эквивалентных бинов Apache Directory Server. Атрибуты элемента ldap-server большинство типовых конфигурационных требований и пользователь освобожден от необходимости беспокоиться о том, какие бины необходимо создавать и какие соответственно какие имена бинов.<ref name="[1]">You can find out more about the use of the <code>ldap-server</code> element in the chapter on LDAP.</ref>. При использовании хорошего XML-редактора при редактировании файла контекста приложения будет предоставлена информация о имеющихся атрибутах и элементах. Мы рекомендуем вам попробовать SpringSource Tool Suite, который имеет специальные возможности для работы со стандартными пространствами имен Spring'а.

 

Чтобы начать использовать пространство имен Security в контексте вашего приложения, все что нужно вам сделать это добавить объявление схемы в файл контекста приложения:

 

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:security="http://www.springframework.org/schema/security"

...

</beans>

 

Во многих примерах, которые вы увидите, мы будем часто использовать по умолчанию пространство имен "security", а не "bean", это означает, что мы можем опустить префикс для всех элементов пространства имен "security", в результате чего содержание конфигурационного файла будет проще для чтения и понимания. Вы можете поступать подобным образом, если ваш контекст приложения разделен на несколько отдельных файлов и большая часть конфигурации, которая относится к безопасности, собрана в одном из них. В этом случае файл контекста приложения для конфигурирования безопасности будет начинаться следующим образом:

 

<beans:beans xmlns="http://www.springframework.org/schema/security"

xmlns:beans="http://www.springframework.org/schema/beans"

...

</beans:beans>

Мы предполагаем что этот синтаксис будет использоваться в этой главе.

 

Первое что необходимо сделать, это добавить следующее объявление фильтра в ваш web.xml файл:

 

<filter>

<filter-name>springSecurityFilterChain</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

 

Это дает возможность встроиться внутрь веб-инфраструктуры Spring Security. Класс <code>DelegatingFilterProxy</code>, из состава Spring Framework , передает запросы реализации фильтра, которая определена как Spring бин в контексте вашего приложения. В данном случае бин называется "springSecurityFilterChain", который является внутренним инфраструктурным бином, создаваемым при обработке пространства имен для решения вопросов связанных с веб-безопасностью. Заметим, что вы не должны использовать бин с этим именем самостоятельно. После того как вы добавили эти строки в ваш <code>web.xml</code>, вы можете приступить к редактированию файла контекста приложения. Сервисы веб-безопасности настраиваются с помощью элемента <code><http></code>.

Все что нужно чтобы начала работать веб-безопасность, это написать следующие строки:

 

<http auto-config='true'>

<intercept-url pattern="/**" access="ROLE_USER" />

</http>

Которые говорят о том, что мы хотим, чтобы в нашем приложение все URL-адреса были защищенными, для доступа к ним требуется роль <code>ROLE_USER</code>. Элемент <code><http></code> является родительским для всей функциональности связанной с веб доступом в пространстве имен security. Элемент <code><intercept-url></code> задает шаблон, с которым сравниваются URL-адресов входящих запросов, для шаблона используется синтаксис в стиле Ant path. Атрибут <code>access</code> определяет требования к правам доступа для запросов, совпадающих с данным шаблоном для доступа просит соответствующие заданной модели. В конфигурации по умолчанию, это как правило список ролей, разделенных запятыми, пользователь должен обладать одной из них, чтобы иметь возможность выполнить запрос. Префикс "ROLE_" является маркером, который показывает что нужно выполнить простое сравнение с полномочиями пользователя. Иными словами, будет использоваться выполняться обычная проверка, основанная на ролях пользователей. Контроль доступа в Spring Security не ограничивается использованием простых ролей (отсюда использования префикса, чтобы различать различные типы атрибутов безопасности). Позже мы увидим, как может меняться их интерпретация <ref name="[2]">The interpretation of the comma-separated values in the access attribute depends on the implementation of the AccessDecisionManager which is used. In Spring Security 3.0, the attribute can also be populated with an EL expression.</ref>.

 

Чтобы добавить нескольких пользователей, можно задать тестовые данные прямо в пространстве имен:

 

<authentication-manager>

<authentication-provider>

</authentication-provider>

</authentication-manager>

 

В приведенной выше конфигурации, определены два пользователя, их пароли и роли в приложении (которые будут использоваться для контроля доступа). Кроме того, можно загрузить информацию о пользователе из стандартного файла свойств с использованием атрибута <code>properties</code> для тега <code>user-service</code>. См. раздел «Аутентификация in-memory» для более подробной информации о формате файла. Использование элемента <code><authentication-provider></code> означает, что это информация о пользователях будет использоваться менеджером аутентификации для обработки запросов аутентификации. Может иметься несколько элементов <code><authentication-provider></code> для задания нескольких источник аутентификационной информации, и каждый из них будет опрашиваться по очереди.

=== Что делает включение auto-config? ===

Атрибут <code>auto-config</code>, который мы уже использовали, это просто сокращенный синтаксис:

<http>

<form-login />

<logout />

</http>

Эти элементы отвечают соответственно за установку логина на основе веб-формы, базовый логин и выход из приложения <ref name="[3]">In versions prior to 3.0, this list also included remember-me functionality. This could cause some confusing errors with some configurations and was removed in 3.0. In 3.0, the addition of an AnonymousAuthenticationFilter is part of the default <http> configuration, so the <anonymous /> element is added regardless of whether auto-config is enabled.</ref>. Каждый из них имеет атрибуты, которые могут быть использованы для изменения их поведения.

 

Вы можете быть удивлены когда при попытке войти в систему появится веб-форма для логина, так как мы ничего не говорили ни о каких HTML или JSP файлах. В действительности, поскольку мы не явно установили URL для страницы входа в систему, Spring Security будет генерировать ее автоматически, основываясь на доступных возможностях и используя стандартные значения для URL, который будет обрабатывать в ход в систему по умолчанию, после того как пользователь войдет в систему он будет перенаправлен на URL для которого был послан запрос. Тем не менее, пространство имен предлагает поддержку, которая позволяет настраивать эти параметры. Например, если вы хотите использовать свою собственную страницу для входа в систему, то вы можете использовать:

 

<http auto-config='true'>

<intercept-url pattern="/login.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>

<form-login login-page='/login.jsp'/>

</http>

 

Обратите внимание, что вы все еще можете использовать <code>auto-config</code>. Элемент <code>form-login</code> просто перекрывает настройки по умолчанию. Также отметим, что мы добавили дополнительный элемент <code>intercept-url</code>, что запросы к станице входа в систему были доступны для анонимных пользователей <ref name="[4]">See the chapter on anonymous authentication and also the AuthenticatedVoter class for more details on how the value IS_AUTHENTICATED_ANONYMOUSLY is processed.</ref>. В противном случае запрос совпадет с шаблоном<code> /**</code> и доступ к странице входа в систему будет запрещен! Это распространенная ошибка конфигурации, которая ведет к бесконечному циклу в приложении. Spring Security запишет предупреждение в лог если доступ к странице входа в систему будет закрыт системой безопасности. Возможно также, чтобы все запросы, соответствующие некоторому шаблону, шли в обход цепочки фильтров безопасности:

 

<http auto-config='true'>

<intercept-url pattern="/css/**" filters="none"/>

<form-login login-page='/login.jsp'/>

</http>

 

Важно понимать, что эти запросы не будут ничего «знать» о конфигурациях Spring Security, связанных c веб-безопасностью или дополнительных атрибутах, таких как <code>requires-channel</code>, так что во время обработки такого запроса вы не сможете получить доступ к информации о текущем пользователе или вызвать защищенные методы. Используйте <code>access='IS_AUTHENTICATED_ANONYMOUSLY'</code>, как альтернативу, если вы хотите чтобы к запросу применялась цепочка фильтров безопасности.

Если вместо веб-формы вы хотите использовать базовую аутентификацию, то измените конфигурацию следующим образом:

 

<http auto-config='true'>

<intercept-url pattern="/**" access="ROLE_USER" />

<http-basic />

</http>

 

Базовая аутентификация будет иметь приоритет и будет выдавать запрос для логина, когда пользователь попытается получить доступ к защищенному ресурсу. В этой конфигурации по прежнему будет доступна веб-форма для выполнения логина, например если вы захотите чтобы пользователь выполнит аутентификацию через форму встроенную в другую веб-страницу.

Если при попытке получить доступ к защищенному ресурсу, пользователю не будет показана форма аутентификации, то тогда в игру вступает опция <code>default-target-url</code>. Пользователь после входа в систему будет отправлен по этому URL, по умолчанию это "/". Вы также можете настроить поведение таким образом, чтобы пользователь всегда перемещался на эту страницу (независимо от того выполнял он вход в систему "по требованию", либо явно вошел в систему), путем установки значения атрибута <code>always-use-default-target</code> в <code>"true"</code>. Это полезно, если ваше приложение требует чтобы пользователь всегда начинал работу с "домашней" страницы, например:

 

<http>

<intercept-url pattern='/login.htm*' filters='none'/>

always-use-default-target='true' />

</http>

 

== Использование других провайдеров аутентификации ==

На практике могут потребоваться более масштабируемые источник информации о пользователях, чем несколько имен, добавленных в файл контекста приложения. Скорее всего, вы будете хранить информацию о пользователях в чем-то вроде базы данных или LDAP сервера. Конфигурирование с помощью пространства имен LDAP рассматривается в главе LDAP, поэтому мы не будем рассматривать его здесь. Если у вас есть собственная реализация интерфейса <code>UserDetailsService</code>, которая в контексте вашего приложения называется "myUserDetailsService", то вы можете выполнять аутентификацию с его помощью, используя

 

<authentication-manager>

<authentication-provider user-service-ref='myUserDetailsService'/>

</authentication-manager>

 

Если вы хотите использовать базу данных, то тогда задайте:

 

<authentication-manager>

<authentication-provider>

</authentication-provider>

</authentication-manager>

 

Где "securityDataSource" это имя бина <code>DataSource</code>, заданного в контексте приложения, указывающего на базу данных, содержащую стандартные таблицы данных Spring Security с информацией о пользователе. Кроме того, можно настроить бин Spring Security <code>JdbcDaoImpl</code> и указать его, используя атрибут <code>user-service-ref</code>:

 

<authentication-manager>

<authentication-provider user-service-ref='myUserDetailsService'/>

<beans:property name="dataSource" ref="dataSource"/>

</beans:bean>

 

Можно также использовать стандартный <code>AuthenticationProvider</code>:

 

<authentication-manager>

<authentication-provider ref='myAuthenticationProvider'/>

</authentication-manager>

 

где <code>myAuthenticationProvider</code> имя бина в контексте вашего приложения, который реализует <code>AuthenticationProvider</code>. См. раздел 2.6, “Менеджер аутентификации и пространство имен” для получения дополнительной информации как конфигурировать <code>AuthenticationManager</code> в Spring Security с использованием пространства имен.

Часто данные пароля шифруются с помощью алгоритма хеширования. Эта возможность поддерживается элементом <code><password-encoder></code>. Конфигурация провайдера аутентификации с поддержкой алгоритма шифрования SHA будет выглядеть следующим образом:

 

<authentication-manager>

<authentication-provider>

</authentication-provider>

</authentication-manager>

 

Когда используются шифрованные пароли, то хорошей идеей будет «добавить соли» к паролю, что позволит защититься от атак с использованием словарей паролей, эта возможность так же поддерживается Spring Security. В идеале вы должны использовать случайным образом сгенерированные значения «соли» для каждого пользователя, но можно использовать и любое из свойств объекта <code>UserDetails</code>, который загружается <code>UserDetailsService</code>.

 

<password-encoder hash="sha">

<salt-source user-property="username"/>

</password-encoder>

 

Вы можете установить свой собственный шифратор паролей с помощью атрибута <code>ref</code> элемента <code>password-encoder</code>. Он должен содержать имя бина из контекста приложения, который является экземпляром Spring Security интерфейса <code>PasswordEncoder</code>.

Если ваше приложение поддерживает доступ как по HTTP, так и по HTTPS, и вам требуется чтобы к отдельным URL можно было получить доступ только через HTTPS, то тогда можно воспользоваться атрибутом <code>requires-channel</code> в элементе <code><intercept-url></code>:

 

<http>

<intercept-url pattern="/secure/**" access="ROLE_USER" requires-channel="https"/>

...

</http>

 

Если будет использована данная конфигурация, то если пользователь попробует обратиться по протоколу HTTP по адресу, совпадающему с шаблоном, то он сперва будет перенаправлена на HTTPS URL. Возможные значения атрибута "http", "https" или "any". Использование значения "any"означает что можно использовать как HTTP так и HTTPS.

Вы можете настроить Spring Security так, чтобы автоматически обнаруживать что присланный ID сессии является не корректным и перенаправлять пользователя на соответствующий URL. Это достигается с помощью элемента <code>session-management</code>:

 

<http>

...

<session-management invalid-session-url="/sessionTimeout.htm" />

</http>

 

=== Управление параллельными сессиями ===

Если вы хотите ввести ограничения на способность одного пользователя войти в приложение, то Spring Security поддерживает эту возможность "из коробки" с помощью следующего простого дополнения. Прежде всего, необходимо добавить следующий слушатель в файл <code>web.xml</code>, чтобы Spring Security получал информацию о событиях в течение жизненного цикла сессии:

 

<listener>

<listener-class>

</listener-class>

</listener>

 

Затем добавить следующие строки в контекст приложения:

 

<http>

...

</session-management>

</http>

 

Это предотвратит возможность многократного входа в систему одного пользователя — второй вход в систему приведет к тому, что предыдущий вход будет считаться недействительным. Вам может потребоваться предотвратить возможность выполнить второй вход в систему, в этом случае вы можете использовать:

 

<http>

...

</session-management>

</http>

 

Попытка выполнить второй вход в систему будет отклонена. Под «отклонена» мы понимает, что пользователь будет отправлен на страницу <code>authentication-failure-url</code>, если используется аутентификация с помощью веб-форм. Если попытка выполнить повторную аутентификацию будет предпринята с помощью не интерактивного механизма, такого например, как «запомни меня», то клиенту будет отправлена ошибка 402 «не авторизован». Если вместо сообщения об ошибке вы хотите использовать собственную страницу для показа ошибок, то используйте атрибут <code>session-authentication-error-url</code> элемента <code>session-management</code>.

Пространство имен поддерживает использование входа в систему с помощью OpenID, вместо или совместно со входом в систему с помощью веб-формы, с помощью небольшого изменения конфигурации:

 

<http>

<intercept-url pattern="/**" access="ROLE_USER" />

<openid-login />

</http>

 

Затем вы должны зарегистрировать у себя OpenID провайдера (такого например, как myopenid.com), и добавить информацию о пользователе в in-memory <code><user-service></code>:

 

 

Теперь вы можете войти в систему, используя сайт myopenid.com сайт для аутентификации. Кроме того, для работы с OpenID можно выбрать конкретный бин <code>UserDetailsService</code>, установив атрибут <code>user-service-ref</code> элемента <code>openid-login</code>. Для дополнительной информации см. предыдущий раздел об аутентификационных провайдерах. Обратите внимание, что в приведенной выше конфигурации, мы опустили атрибут <code>password</code>, так как этот набор данных пользователя используется только для загрузки полномочий пользователя. Случайный пароль генерируется внутри системы, предохраняя от случайного использования пользовательских данных как источника аутентификации в другом месте конфигурации.

Для OpenID поддерживается обмен атрибутами. Как пример, следующая конфигурация будет пытаться получить значения электронной почты и полного имени пользователя из провайдера OpenID и использовать их в своем приложении:

 

<openid-login>

<attribute-exchange>

</attribute-exchange>

</openid-login>

«Тип» каждого OpenID атрибута это URI, заданный определенной схемой, в нашем случае это http://axschema.org/. Если для успешной аутентификации какой-то атрибут должен быть получен в обязательном порядке, то тогда можно установить атрибут <code>required</code>. Поддерживаемая схема и набор возможных атрибутов зависят от вашего OpenID провайдера. Значения атрибутов возвращаются как часть процесса аутентификации и впоследствии могут быть доступными с помощью следующего кода:

 

OpenIDAuthenticationToken token = (OpenIDAuthenticationToken)SecurityContextHolder.getContext().getAuthentication();

List<OpenIDAttribute> attributes = token.getAttributes();

 

<code>OpenIDAttribute</code> содержит: тип атрибута и запрашиваемое значение (или значения, в случае если атрибут допускает множество значений). Мы сможет увидеть больше примеров использования класса <code>SecurityContextHolder</code> когда будет рассматривать ключевые компоненты Spring Security в главе «Технический обзор».

Вы можете добавить собственный фильтр в стек, используя элемент <code>custom-filter</code> и одно из этих имен, чтобы указать в какой позиции должен появиться ваш фильтр

 

<http>

<custom-filter position="FORM_LOGIN_FILTER" ref="myFilter" />

 

<beans:bean id="myFilter" class="com.mycompany.MySpecialAuthenticationFilter"/>

 

Вы можете так же использовать атрибуты <code>after</code> или <code>before</code> если вы хотите чтобы ваш фильтр был вставлен после или перед другим фильтром в стеке. Имена "FIRST" и "LAST" могут быть использованы с атрибутом <code>position</code>, чтобы указать что вы хотите чтобы ваш фильтр появился перед или после всего стека соответственно.

Этот элемент используется чтобы включить возможность использования системы безопасности, основанной на аннотациях (путем установки соответствующих атрибутов у элементов), а также для того чтобы собрать в одном месте все объявления системы безопасности, которые будут действовать в контексте всего приложения. Вы должны только объявить один элемент <code><global-method-security></code>. Для включение поддержки Spring Security потребуется аннотация @Secured:

 

 

Добавление аннотации к методу (класса или интерфейса) будет соответственно ограничивать доступ к этому методу. Родная поддержка аннотаций Spring Security определяет несколько атрибутов для метода. Эти атрибуты затем передаются в <code>AccessDecisionManager</code>, чтобы принять фактическое решение:

 

public interface BankService {

 

public Account post(Account account, double amount);

}

 

Поддержка аннотаций JSR-250 может быть включена с помощью:

 

 

Они основаны на стандартах и позволяет легко создавать ограничения на основе ролей, которые будут применяться к методам, но они не имеют таких возможностей, как родные аннотации Spring Security. Чтобы воспользоваться новым синтаксисом, основанным на выражениях, вы должны использовать

 

 

и Java код будет выглядеть

 

public interface BankService {

 

public Account post(Account account, double amount);

}

 

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

Особенно мощный инструмент, это использование <code>protect-pointcut</code>, т. к. это позволяет применить систему безопасности ко множеству бинов с помощью одного простого объявления. Рассмотрим следующий пример:

 

<global-method-security>

<protect-pointcut expression="execution(* com.mycompany.*Service.*(..))"

access="ROLE_USER"/>

</global-method-security>

 

Это защитит все методы в бинах, объявленных в контексте приложения, чьи классы расположены в пакете com.mycompany и чьи имена заканчиваются на "Service". Только пользователи с ролью ROLE_USER смогу вызывать эти методы. Как и в случае соответствия URL шаблону, самые важные шаблоны для поиска совпадений должны идти первыми в списке срезов, будет использовано первое выражение, которое совпадет с шаблоном.

Вы можете захотеть зарегистрировать дополнительные бины <code>AuthenticationProvider</code> для <code>ProviderManager</code> и вы можете сделать это используя элемент <code><authentication-provider></code> с атрибутом <code>ref</code>, где значение атрибута это имя бина провайдера, который вы хотите добавить. Например:

 

<authentication-manager>

<authentication-provider ref="casAuthenticationProvider"/>

...

</bean>

 

Другим общим требованием является то, что другой компонент в контексте может потребовать ссылку на <code>AuthenticationManager</code>. Вы можете легко зарегистрировать псевдоним для <code>AuthenticationManager</code> и использовать это имя в других местах контекста приложения.

 

<security:authentication-manager alias="authenticationManager">

...

...

</bean>

 

= Примечания =