1. Обзор
В этом руководстве показано, как установить, настроить и настроить дайджест-аутентификацию с помощью Spring. Как и в предыдущей статье, посвященной базовой аутентификации , мы собираемся использовать руководство по Spring MVC и защитить приложение с помощью механизма дайджест-аутентификации, предоставляемого Spring Security.
2. XML-конфигурация безопасности
Первое, что нужно понять о конфигурации, это то, что, хотя Spring Security имеет полную встроенную поддержку механизма аутентификации Digest, эта поддержка не так хорошо интегрирована в пространство имен , как это было в Basic Authentication.
В этом случае нам нужно вручную определить необработанные bean-компоненты , которые будут составлять конфигурацию безопасности — DigestAuthenticationFilter и DigestAuthenticationEntryPoint :
<beans:bean id="digestFilter"
class="org.springframework.security.web.authentication.www.DigestAuthenticationFilter">
<beans:property name="userDetailsService" ref="userService" />
<beans:property name="authenticationEntryPoint" ref="digestEntryPoint" />
</beans:bean>
<beans:bean id="digestEntryPoint"
class="org.springframework.security.web.authentication.www.DigestAuthenticationEntryPoint">
<beans:property name="realmName" value="Contacts Realm via Digest Authentication" />
<beans:property name="key" value="acegi" />
</beans:bean>
<!-- the security namespace configuration -->
<http use-expressions="true" entry-point-ref="digestEntryPoint">
<intercept-url pattern="/**" access="isAuthenticated()" />
<custom-filter ref="digestFilter" after="BASIC_AUTH_FILTER" />
</http>
<authentication-manager>
<authentication-provider>
<user-service id="userService">
<user name="user1" password="user1Pass" authorities="ROLE_USER" />
</user-service>
</authentication-provider>
</authentication-manager>
Затем нам нужно интегрировать эти bean-компоненты в общую конфигурацию безопасности — и в этом случае пространство имен все еще достаточно гибко, чтобы позволить нам это сделать.
Первая часть указывает на bean-компонент пользовательской точки входа через атрибут entry-point-ref основного элемента <http> .
Вторая часть — добавление вновь определенного дайджест-фильтра в цепочку фильтров безопасности . Поскольку этот фильтр функционально эквивалентен BasicAuthenticationFilter , мы используем ту же относительную позицию в цепочке — это определяется псевдонимом BASIC_AUTH_FILTER в общих стандартных фильтрах безопасности Spring .
Наконец, обратите внимание, что дайджест-фильтр сконфигурирован так, чтобы указывать на компонент пользовательской службы — и здесь пространство имен снова очень полезно, поскольку оно позволяет нам указать имя компонента для пользовательской службы по умолчанию, созданной элементом <user-service> :
<user-service id="userService">
3. Использование защищенного приложения
Мы собираемся использовать команду curl для использования защищенного приложения и понимания того, как клиент может взаимодействовать с ним.
Давайте начнем с запроса домашней страницы — без предоставления учетных данных безопасности в запросе:
curl -i http://localhost/spring-security-mvc-digest-auth/homepage.html
Как и ожидалось, мы получаем ответ с кодом состояния 401 Unauthorized :
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=CF0233C...; Path=/spring-security-mvc-digest-auth/; HttpOnly
WWW-Authenticate: Digest realm="Contacts Realm via Digest Authentication", qop="auth",
nonce="MTM3MzYzODE2NTg3OTo3MmYxN2JkOWYxZTc4MzdmMzBiN2Q0YmY0ZTU0N2RkZg=="
Content-Type: text/html;charset=utf-8
Content-Length: 1061
Date: Fri, 12 Jul 2013 14:04:25 GMT
Если бы этот запрос был отправлен браузером, запрос аутентификации запросил бы у пользователя учетные данные с помощью простого диалогового окна пользователя/пароля.
Давайте теперь предоставим правильные учетные данные и снова отправим запрос:
curl -i --digest --user
user1:user1Pass http://localhost/spring-security-mvc-digest-auth/homepage.html
Обратите внимание, что мы включаем дайджест-аутентификацию для команды curl с помощью флага –digest .
Первый ответ сервера будет таким же — 401 Unauthorized — но вызов теперь будет интерпретирован и обработан вторым запросом — который завершится успешно с 200 OK :
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=A961E0D...; Path=/spring-security-mvc-digest-auth/; HttpOnly
WWW-Authenticate: Digest realm="Contacts Realm via Digest Authentication", qop="auth",
nonce="MTM3MzYzODgyOTczMTo3YjM4OWQzMGU0YTgwZDg0YmYwZjRlZWJjMDQzZWZkOA=="
Content-Type: text/html;charset=utf-8
Content-Length: 1061
Date: Fri, 12 Jul 2013 14:15:29 GMT
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=55F996B...; Path=/spring-security-mvc-digest-auth/; HttpOnly
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Content-Length: 90
Date: Fri, 12 Jul 2013 14:15:29 GMT
<html>
<head></head>
<body>
<h1>This is the homepage</h1>
</body>
</html>
Последнее замечание по этому взаимодействию заключается в том, что клиент может упреждающе отправить правильный заголовок авторизации с первым запросом и, таким образом, полностью избежать проблемы безопасности сервера и второго запроса.
4. Зависимости Maven
Зависимости безопасности подробно обсуждаются в учебнике Spring Security Maven . Короче говоря, нам нужно определить spring-security-web и spring-security-config как зависимости в нашем pom.xml .
5. Вывод
В этом руководстве мы внедряем безопасность в простой проект Spring MVC, используя поддержку дайджест-аутентификации в фреймворке.
Реализацию этих примеров можно найти в проекте Github — это проект на основе Eclipse, поэтому его легко импортировать и запускать как есть.
Когда проект запускается локально, доступ к HTML-коду домашней страницы можно получить по адресу (или, при минимальной конфигурации Tomcat, по порту 80):
http://localhost:8080/spring-security-mvc-digest-auth/homepage.html
Наконец, приложению не нужно выбирать между базовой и дайджест-аутентификацией — обе можно настроить одновременно в одной и той же структуре URI таким образом, чтобы клиент мог выбирать между двумя механизмами при использовании веб-приложения.