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

Материал из Викиучебника — открытых книг для открытого мира
Содержимое удалено Содержимое добавлено
Строка 70: Строка 70:


=== Минимальная <http> конфигурация ===
=== Минимальная <http> конфигурация ===
Все что нужно чтобы начала работать веб-безопасность, это написать следующие строки:

<source lang="xml">
<http auto-config='true'>
<intercept-url pattern="/**" access="ROLE_USER" />
</http>
</source>
Которые говорят о том, что мы хотим, чтобы в нашем приложение все 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>.

<blockquote>
'''''Примечание:'''''
Вы можете использовать несколько элементов <code><intercept-url></code> для задания различных требований контроля доступа для различных наборов URL-адресов, но они будут обрабатываться в том порядке как они заданы в файле и будет использовано первое совпадение. Так что вы должны размещать наиболее важные шаблоны в самом начале списка. Вы также можете добавить атрибут <code>method</code> , чтобы ограничить совпадение конкретным видом HTTP запроса (GET, POST, PUT и т. д.). Если запрос соответствует нескольким шаблонам, то совпадение с конкретным типом запроса будет иметь приоритет над порядком расположения.
</blockquote>

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

<source lang="xml">
<authentication-manager>
<authentication-provider>
<user-service>
<user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
<user name="bob" password="bobspassword" authorities="ROLE_USER" />
</user-service>
</authentication-provider>
</authentication-manager>
</source>

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

С этого момента вы можете запустить ваше приложение и получите запрос для выполнения аутентификации (логина). Попробуйте выполнить это или поэкспериментируйте с "учебным" приложением, которое поставляется вместе с проектом. Приведенная выше конфигурация, по факту добавляет не сильно много сервисов, потому что мы использовали атрибут <code>auto-config</code>. Например, автоматически включается обработка логина на основе веб-форм.

==== Что делает включение auto-config? ====
Атрибут <code>auto-config</code>, который мы уже использовали, это просто сокращенный синтаксис:
<source lang="xml">
<http>
<form-login />
<http-basic />
<logout />
</http>
</source>
Эти элементы отвечают соответственно за установку логина на основе веб-формы, базовый логин и выход из приложения <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>. Каждый из них имеет атрибуты, которые могут быть использованы для изменения их поведения.

==== Базовый вход в систему и вход на основе веб-форм ====


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

Версия от 12:40, 10 июня 2010

Эта статья представляет собой перевод Spring Security Reference Documentation, Ben Alex, Luke Taylor 3.0.2.RELEASE, Глава 2, Конфигурирование пространства имен Security.

Введение

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

  <security:ldap-server />

Это гораздо проще, чем настраивать зависимости эквивалентных бинов Apache Directory Server бобов. Атрибуты элемента ldap-server большинство типовых конфигурационных требований и пользователь освобожден от необходимости беспокоиться о том, какие бины необходимо создавать и какие соответственно какие имена бинов.[1]. При использовании хорошего XML-редактора при редактировании файла контекста приложения будет предоставлена информация о имеющихся атрибутах и элементах. Мы рекомендуем вам попробовать SpringSource Tool Suite, который имеет специальные возможности для работы со стандартными пространствами имен Spring'а.

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

<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:security="http://www.springframework.org/schema/security"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
          http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
          http://www.springframework.org/schema/security
          http://www.springframework.org/schema/security/spring-security-3.0.xsd">
    ...
</beans>

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

<beans:beans xmlns="http://www.springframework.org/schema/security"
  xmlns:beans="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
           http://www.springframework.org/schema/security
           http://www.springframework.org/schema/security/spring-security-3.0.xsd">
    ...
</beans:beans>

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

Устройство пространства имен

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

  • Web/HTTP Security - наиболее сложная часть. Устанавливает фильтры и связанные с ними сервисные бины, используемые аутентификационными механизмами фреймворка, защитой URL, показом страниц ошибок и аутентификации и многое другое
  • Business Object (Method) Security — опции для защиты уровня сервисов.
  • AuthenticationManager — обрабатывает аутентификационные запросы от других частей фреймворка.
  • AccessDecisionManager — предоставляет решение о разрешении доступа к веб-страницам и методам. Всегда будет зарегистрированный по умолчанию менеджер, но вы также можете свой собственный менеджер, объявленный с помощью обычного <bean/> синтаксиса Spring.
  • AuthenticationProviders — механизмы, опираясь на которые, менеджер аутентификации выполняет фактическую аутентификацию пользователей. Пространство имен предоставляет поддержку нескольких стандартных вариантов, а так же средства добавления пользовательских бинов, объявленных с помощью традиционного синтаксиса.
  • UserDetailsService — тесно связан с провайдером аутентификации, но так же может запрашиваться другими бинами.

В последующих разделах мы увидим, как выполнять их конфигурирование.

Начинаем конфигурирование с помощью пространства имен Security

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

Конфигурация web.xml

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

<filter>
  <filter-name>springSecurityFilterChain</filter-name>
  <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

<filter-mapping>
  <filter-name>springSecurityFilterChain</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

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

Минимальная <http> конфигурация

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

 <http auto-config='true'>
    <intercept-url pattern="/**" access="ROLE_USER" />
 </http>

Которые говорят о том, что мы хотим, чтобы в нашем приложение все URL-адреса были защищенными, для доступа к ним требуется роль ROLE_USER. Элемент <http> является родительским для всей функциональности связанной с веб доступом в пространстве имен security. Элемент <intercept-url> задает шаблон, с которым сравниваются URL-адресов входящих запросов, для шаблона используется синтаксис в стиле Ant path. Атрибут access определяет требования к правам доступа для запросов, совпадающих с данным шаблоном для доступа просит соответствующие заданной модели. В конфигурации по умолчанию, это как правило список ролей, разделенных запятыми, пользователь должен обладать одной из них, чтобы иметь возможность выполнить запрос. Префикс "ROLE_" является маркером, который показывает что нужно выполнить простое сравнение с полномочиями пользователя. Иными словами, будет использоваться выполняться обычная проверка, основанная на ролях пользователей. Контроль доступа в Spring Security не ограничивается использованием простых ролей (отсюда использования префикса, чтобы различать различные типы атрибутов безопасности). Позже мы увидим, как может меняться их интерпретация [2].

Примечание: Вы можете использовать несколько элементов <intercept-url> для задания различных требований контроля доступа для различных наборов URL-адресов, но они будут обрабатываться в том порядке как они заданы в файле и будет использовано первое совпадение. Так что вы должны размещать наиболее важные шаблоны в самом начале списка. Вы также можете добавить атрибут method , чтобы ограничить совпадение конкретным видом HTTP запроса (GET, POST, PUT и т. д.). Если запрос соответствует нескольким шаблонам, то совпадение с конкретным типом запроса будет иметь приоритет над порядком расположения.

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

 <authentication-manager>
    <authentication-provider>
      <user-service>
        <user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
        <user name="bob" password="bobspassword" authorities="ROLE_USER" />
      </user-service>
    </authentication-provider>
 </authentication-manager>

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

С этого момента вы можете запустить ваше приложение и получите запрос для выполнения аутентификации (логина). Попробуйте выполнить это или поэкспериментируйте с "учебным" приложением, которое поставляется вместе с проектом. Приведенная выше конфигурация, по факту добавляет не сильно много сервисов, потому что мы использовали атрибут auto-config. Например, автоматически включается обработка логина на основе веб-форм.

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

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

<http>
   <form-login />
   <http-basic />
   <logout />
</http>

Эти элементы отвечают соответственно за установку логина на основе веб-формы, базовый логин и выход из приложения [3]. Каждый из них имеет атрибуты, которые могут быть использованы для изменения их поведения.

Базовый вход в систему и вход на основе веб-форм

Примечания

  1. You can find out more about the use of the ldap-server element in the chapter on LDAP.
  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.
  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.