Spring Security参考文档：安全指南

需积分: 0 51 浏览量更新于2024-08-02 收藏 588KB PDF 举报

"这是一本关于Spring Security的PDF文档，由Ben Alex和Luke Taylor撰写，版本为3.0.0.M2。文档详细介绍了Spring Security框架的各个方面，包括入门、安全命名空间配置、高级Web功能、方法安全等内容。" 在Spring Security这个强大的安全框架中，它提供了全面的解决方案来保护基于Spring的应用程序。该文档的【标题】"Spring 安全文档 PDF"暗示了其主要焦点是深入理解Spring Security的机制和用法。【描述】中提到，这是一个英文文档，适合对Spring Security感兴趣或需要学习的人阅读。Spring Security是Java开发者广泛使用的安全库，它提供了身份验证、授权和访问控制等功能，确保应用程序的安全性。在【部分内容】中，文档首先介绍了**Getting Started**部分，包括Spring Security是什么，它的历史，版本编号以及如何获取源代码。这部分帮助读者建立起对Spring Security的基本认识。接着，文档详细阐述了**Security Namespace Configuration**，这是Spring Security配置的核心部分。通过安全命名空间，开发者可以方便地在XML配置文件中设置安全规则。例如，`<http>`元素用于配置Web应用的安全，可以实现基本的登录选项、自定义认证提供者、密码编码器等。此外，文档还讨论了高级Web特性，如记住我（Remember-Me）认证、HTTP/HTTPS通道安全、并发会话控制、OpenID登录等，这些功能增强了用户体验并提供了更精细的安全控制。在**Method Security**部分，文档提到了`<global-method-security>`元素，这使得可以在方法级别实施安全策略。通过`protect-pointcut`，开发者可以添加安全切点，实现细粒度的权限控制。这对于业务逻辑层的安全管理至关重要。文档中还有其他章节未提及，但通常会涵盖更多内容，比如权限决策管理（Access Decision Management）、用户权限分配、过滤链配置、异常处理等。Spring Security的灵活性和强大功能使得它成为企业级应用开发中的首选安全框架。这份Spring Security的参考文档为开发者提供了详尽的指南，无论你是初学者还是经验丰富的开发者，都能从中获益，提升对Spring Security的理解和应用能力。通过深入学习，你将能够构建出更安全、更健壮的Spring应用程序。

Spring Security

3.0.0.M2 Spring Security 6

2. Security Namespace Configuration

2.1 Introduction

Namespace configuration has been available since version 2.0 of the Spring framework. It allows you

to supplement the traditional Spring beans application context syntax with elements from additional

XML schema. You can find more information in the Spring Reference Documentation [http://

static.springframework.org/spring/docs/2.5.x/reference/xsd-config.html]. A namespace element can be

used simply to allow a more concise way of configuring an individual bean or, more powerfully, to

define an alternative configuration syntax which more closely matches the problem domain and hides

the underlying complexity from the user. A simple element may conceal the fact that multiple beans and

processing steps are being added to the application context. For example, adding the following element

from the security namespace to an application context will start up an embedded LDAP server for testing

use within the application:

<security:ldap-server />

This is much simpler than wiring up the equivalent Apache Directory Server beans. The most common

alternative configuration requirements are supported by attributes on the ldap-server element and

the user is isolated from worrying about which beans they need to be set on and what the bean property

names are.

. Use of a good XML editor while editing the application context file should provide

information on the attributes and elements that are available. We would recommend that you try out

the SpringSource Tool Suite [http://www.springsource.com/products/sts] as it has special features for

working with standard Spring namespaces.

To start using the security namespace in your application context, all you need to do is add the schema

declaration to your application context file:

<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>

In many of the examples you will see (and in the sample) applications, we will often use "security"

as the default namespace rather than "beans", which means we can omit the prefix on all the security

namespace elements, making the context easier to read. You may also want to do this if you have your

application context divided up into separate files and have most of your security configuration in one

of them. Your security application context file would then start like this

You can find out more about the use of the ldap-server element in the chapter on LDAP.

Spring Security

3.0.0.M2 Spring Security 7

<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>

We'll assume this syntax is being used from now on in this chapter.

Design of the Namespace

The namespace is designed to capture the most common uses of the framework and provide a simplified

and concise syntax for enabling them within an application. The design is based around the large-scale

dependencies within the framework, and can be divided up into the following areas:

• Web/HTTP Security - the most complex part. Sets up the filters and related service beans used to

apply the framework authentication mechanisms, to secure URLs, render login and error pages and

much more.

• Business Object (Method) Security - options for securing the service layer.

• AuthenticationManager - handles authentication requests from other parts of the framework.

• AccessDecisionManager - provides access decisions for web and method security. A default one will

be registered, but you can also choose to use a custom one, declared using normal Spring bean syntax.

• AuthenticationProviders - mechanisms against which the authentication manager authenticates users.

The namespace provides supports for several standard options and also a means of adding custom

beans declared using a traditional syntax.

• UserDetailsService - closely related to authentication providers, but often also required by other

beans.

We'll see how these work together in the following sections.

2.2 Getting Started with Security Namespace

Configuration

In this section, we'll look at how you can build up a namespace configuration to use some of the main

features of the framework. Let's assume you initially want to get up and running as quickly as possible

and add authentication support and access control to an existing web application, with a few test logins.

Then we'll look at how to change over to authenticating against a database or other security information

repository. In later sections we'll introduce more advanced namespace configuration options.

web.xml Configuration

The first thing you need to do is add the following filter declaration to your web.xml file:

Spring Security

3.0.0.M2 Spring Security 9

If you are familiar with pre-namespace versions of the framework, you can probably already

guess roughly what's going on here. The <http> element is responsible for creating a

FilterChainProxy and the filter beans which it uses. Common issues like incorrect filter

ordering are no longer an issue as the filter positions are predefined.

The <authentication-provider> element creates a

DaoAuthenticationProvider bean and the <user-service> element creates an

InMemoryDaoImpl. All authentication-provider elements must be within the

authentication-manager element, which creates a ProviderManager and registers

the authentication providers with it. You can find more detailed information on the beans that are

created in the namespace appendix.

The configuration above defines two users, their passwords and their roles within the application (which

will be used for access control). It is also possible to load user information from a standard properties file

using the properties attribute on user-service. See the section on in-memory authentication for

more details. Using the <authentication-provider> element means that the user information

will be used by the authentication manager to process authentication requests.

At this point you should be able to start up your application and you will be required to log in to proceed.

Try it out, or try experimenting with the "tutorial" sample application that comes with the project. The

above configuration actually adds quite a few services to the application because we have used the

auto-config attribute. For example, form-based login processing is automatically enabled.

What does auto-config Include?

The auto-config attribute, as we have used it above, is just a shorthand syntax for:

<http>

<form-login />

<http-basic />

</http>

These other elements are responsible for setting up form-login, basic authentication and logout handling

services respectively

. They each have attributes which can be used to alter their behaviour.

Form and Basic Login Options

You might be wondering where the login form came from when you were prompted to log in, since

we made no mention of any HTML files or JSPs. In fact, since we didn't explicitly set a URL for the

standard values for the URL which processes the submitted login, the default target URL the user will

In versions prior to 3.0, this list also inluded 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 AnonymousProcessingFilter was made part of the

default <http> configuration, so the <anonymous /> element is effectively added regardless of whether auto-config

is enabled.

Spring Security

3.0.0.M2 Spring Security 10

be sent to and so on. However, the namespace offers plenty of suppport to allow you to customize these

options. For example, if you want to supply your own login page, you could use:

<intercept-url pattern="/login.jsp*" filters="none"/>

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

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

</http>

Note that you could still use auto-config. The form-login element just overrides the default

settings. Also note that we've added an extra intercept-url element to say that any requests for

the login page should be excluded from processing by the security filters. Otherwise the request would

be matched by the pattern /** and it wouldn't be possible to access the login page itself! If you want

to use basic authentication instead of form login, then change the configuration to

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

<http-basic />

</http>

Basic authentication will then take precedence and will be used to prompt for a login when a user

attempts to access a protected resource. Form login is still available in this configuration if you wish to

use it, for example through a login form embedded in another web page.

Setting a Default Post-Login Destination

If a form login isn't prompted by an attempt to access a protected resource, the default-target-

url option comes into play. This is the URL the user will be taken to after logging in, and defaults to

"/". You can also configure things so that they user always ends up at this page (regardless of whether

the login was "on-demand" or they explicitly chose to log in) by setting the always-use-default-

target attribute to "true". This is useful if your application always requires that the user starts at a

"home" page, for example:

<http>

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

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

<form-login login-page='/login.htm' default-target-url='/home.htm'

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

</http>

Using other Authentication Providers

In practice you will need a more scalable source of user information than a few names added to

the application context file. Most likely you will want to store your user information in something

like a database or an LDAP server. LDAP namespace configuration is dealt with in the LDAP

chapter, so we won't cover it here. If you have a custom implementation of Spring Security's

剩余120页未读，继续阅读

pengrongxin

粉丝: 1
资源: 4

Spring Security参考文档：安全指南

spring官方文档pdf

spring经典文档pdf

spring cloud 文档 pdf 英文版

spring PDF文档

spring cloud文档pdf版（带书签）

spring中文文档.pdf

Spring中文文档.pdf

Spring Boot官方文档pdf

SpringSecurity.pdf

Spring 4.2文档（pdf格式）

最新资源