声明：本文档基于Spring Security4.1的官方文档进行翻译，在官方文档的基础之上，添加一些源码解析的内容。因为有源码解读部分的内容，以及本人对内容安排原因，教程的顺序可能与官方文档略微有所不同。
官方网址：http://projects.spring.io/spring-security/
文档地址：http://docs.spring.io/spring-security/site/docs/4.1.x/reference/htmlsingle/
Spring Security为J2EE应用提供了一个全面的安全解决方案。当你在阅读这个教程的时，你会发现，我们尝试向你展示的是一个有用的和高度可配置的安全系统。
安全是一个不断演进的目标，追求一个全面的、系统级别的安全方案是非常重要的。站在安全领域的角度，我们鼓励分层的概念，每一层都只管理自己职责范围内的安全问题，每一层的安全机制越严格，我们的应用就越健壮、越安全。
1、在最底层，我们需要处理传输层安全和系统识别，从而避免中间人(man-in-the-middle )攻击。
2、接着我们会使用防火墙，可能会联合VPN或者IP安全机制来保证只有被授权的系统才能进行连接。
3、在企业环境中，我们需要部署一个DMZ( demilitarized zone )服务来隔离对外提供访问的接口的服务器与内部数据库和应用服务器。
4、我们的操作系统也扮演了安全中的一环，例如使用不具有特定权限的用户运行进程，限制用户最大可以操作的文件数量等。操作系统通常也会配置自己的防火墙。
5、我们可能还会尝试使阻止DDOS( DistributedDenialofService)分布式拒绝服务和暴力破解攻击（brute force attacks ）。一个入侵检测系统对于攻击的监控和响应是非常有用的，可以帮助我们实时的拒绝某些TPC/IP地址的访问。
6、从更高的层面即JVM的层面来说，我们可以通过配置最小化一个Java类可以具有的权限(译者注：通过JAVA_HOME/jre/lib/security/java.policy文件进行配置)
7、最后我们在应用层面添加一些领域特定的安全配置。
Spring Security可以让最后一点，即应用相关的安全( application security )设置变得更加容易。
当然，我们需要适当的处理上面的提到的每一层的安全机制，并考虑一些管理方面的问题。以下列出了一些需要考虑的管理因素(并不是所有)如： personnel vetting（人工审核）、审计、灾难恢复，性能benchmark、负载监控、日志聚集、应急响应步骤等（ incident response procedures ）。
由于Spring Security聚焦于应用级别的安全，你会发现处理不同领域的应用会有不同的安全需求。一个银行应用和一个电子商务应用就会有着不同的安全需求。不同的应用需要不同的安全特性，让应用层安全充满了挑战。
第二部分"入门"，作为学习Spring Security的开始完全足够了。这一章会向你介绍SpringSecurity框架和基于命名空间的配置系统，以便你能快速上手。要想知道更多Spring Security如何工作的知识，以及可能会使用到的类，需要阅读第三部分"架构和实现"。
本教程的剩余部分内容将按照传统的参考手册的方式进行组织，这样设计是为了让你掌握必要的基础知识。我们同样建议你尽可能的掌握一些应用中可能会遇到的安全问题。Spring Security不是可以解决所有的安全问题的万能药。从应用开始设计的时候就应该考虑安全方面的问题，尝试进行改造并不是好的想法。特别的，如果你正在构建一个WEB应用，你应该知道一些潜在的薄弱点，例如：跨站脚本攻击(cross-site scripting，CSS又叫XSS攻击)、跨站请求伪造(cross-site request-forgery)、session劫持(session-hijacking)，这些问题在应用设计的一开始就应该考虑。OWASP(http://www.owasp.org/)站点上维护了web应用最容易受到攻击的10个薄弱点，并且有很多有用的参考文档。
我们希望你发现这个参考指南的确是有用的，并且希望得到你的反馈和建议。
本教程接下来的部分将会深入的介绍spring security的架构和实现，我们需要对此有所了解，以便进行严谨的定制。在本节中，我们首先会介绍 Spring Security 3.0，简要的介绍spring security的历史以及快速浏览如何使用 Spring Security。我们同时也会介绍 Spring Security的基于命名空间的配置系统，相对于传统的基于Spring Bean的方式，这种方式更为简单。
我们同样会介绍一些可用的案例程序。在你阅读接下来章节之前，这些程序是值得你提前进行运行和体验的。随着你对Spring Security框架的了解更加深入，你可以深挖这些案例程序背后的原理。同样也建议你查看项目站点(http://static.springsource.org/spring-security/site/index.html)，上面有一些有用的信息，包括：项目构建 、相关文章、视频和手册等。
Spring Security是什么
Spring Security为J2EE企业级应用提供了全面的安全服务。这里有一个特别的强调的地方，应用是基于Spring框架开发的。如果你没有使用过Spring来开发J2EE应用，我们强烈的建议你尝试一下。对于Spring框架的熟悉(特别是依赖注入原则)，会让你在学习 Spring Security的时候更加容易上手。
人们使用 Spring Security的原因有很多，但是大部分项目是发现 Java EE的Servlet 规范或者EJB规范对企业级应用场景提供的安全特性不够深入。提到这些规范，要认识到的一点是，在war包或者ear包的级别上，这些安全机制是不可以移植的。意思就是，如果我们使用了不同的服务器环境，我们通常需要为新的服务器环境重新配置或者开发系统的安全机制。使用Spring Security可以克服这些问题，并且可以给你带来大量的其他有用的、可以自定义的特性。
你可能已经知道，应用级别的安全主要分为“验证( authentication) ”和“(授权) authorization ”两个部分。这也是Spring Security主要需要处理的两个部分。“ Authentication ”指的是建立规则( principal )的过程。规则可以是一个用户、设备、或者其他可以在我们的应用中执行某种操作的其他系统。" Authorization "指的是判断某个 principal 在我们的应用是否允许执行某个操作。在 进行授权判断之前，要求其所要使用到的规则必须在验证过程中已经建立好了。这些概念是通用的，并不是只针对"Spring Security"。
在验证(Authentication )层面， Spring Security 提供了不同的验证模型。大部分的authentication模型来自于第三方或者权威机构或者由一些相关的标准制定组织(如IETF)开发。此外，Spring Security也提供了一些验证特性。特别的，Spring Security目前支持对以下所有验证方式的整合：
HTTP BASIC authentication headers (an IETF RFC-based standard)
HTTP Digest authentication headers (an IETF RFC-based standard)
HTTP X.509 client certificate exchange (an IETF RFC-based standard)
LDAP (a very common approach to cross-platform authentication needs, especially in large environments)
Form-based authentication (for simple user interface needs)
OpenID authentication
Authentication based on pre-established request headers (such as Computer Associates Siteminder)
JA-SIG Central Authentication Service (otherwise known as CAS, which is a popular open source single sign-on system)
Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker (a Spring remoting protocol)
Automatic "remember-me" authentication (so you can tick a box to avoid re-authentication for a predetermined period of time)
Anonymous authentication (allowing every unauthenticated call to automatically assume a particular security identity)
Run-as authentication (which is useful if one call should proceed with a different security identity)
Java Authentication and Authorization Service (JAAS)
JEE container autentication (so you can still use Container Managed Authentication if desired)
Kerberos
Java Open Source Single Sign On (JOSSO) *
OpenNMS Network Management Platform *
AppFuse *
AndroMDA *
Mule ESB *
Direct Web Request (DWR) *
Grails *
Tapestry *
JTrac *
Jasypt *
Roller *
Elastic Path *
Atlassian Crowd *
Your own authentication systems (see below)
注：*号标记的部分由第三方提供。
很多独立软件厂家(ISV)接受 Spring Security 的原因就是可以灵活的选择验证模型。这样无论客户的需求是什么，他们都可以快速的整合进自己的解决方案，不需要进行太多额外的研究或者要求客户改变他们的运行环境。如果上述 验证模型都不能满足我们的需求，由于Spring Security是一个开放的平台，我们也可以很容易的就编写出自己的验证机制。许多Spring Security的 企业用户需要将一些并不遵循任何安全标准的"遗留"系统中整合进安全特性，Spring Security很适合用来处理这类系统。
除了验证机制， Spring Security 也提供了一系列的授权能力。主要感兴趣的是以下三个方面：
1、对web请求进行授权
2、授权某个方法是否可以被调用
3、授权访问单个领域对象实例
为了理解其中的不同，考虑一下Servlet规范web模式安全中的授权能力、EJB容器管理的安全、文件系统安全。SpringSecurity对于这些重要的方面提供了深入的支持，在接下来的章节中我们将进行讲解。
Spring Security历史
Spring Security 起源于2003年，当时称之为 "The Acegi Security System for Spring" 。当时，Spring开发者邮件列表接收到一个咨询，是否会开发一个基于Spring的安全机制的实现。当时Spring社区的团队还很小（特别是与如今相比），而事实上在2003年的时候,Spring自身也仅仅是 SourceForge 中的一个项目而已。Spring团队当时的回应是，这件事是值得做的，但是由于缺乏人力物力财力，无法进行这方面的研究。
由于一直记着这件事，后来一个简单的 security 实现完成了，但是没有进行正式的发布。几个星期之后，Spring社区另外一个成员咨询安全相关方面的问题，然后这些代码就提供了给他。其他几个人随后请求加入，到了2004年，大概有20个人左右在使用这些代码。这些先驱用户随后在Source Forge中申请了新项目，在2004年3月也在正式立项。
当时，这个项目还没有任何自己的验证模型。 验证 过程主要还是依赖于容器管理的安全， Acegi Security 着重关注的是 授权。刚开始这是OK的，但是随后越来越多的用户请求提供容器之外安全支持，容器验证模型的不足也越来越明显。将jar包添加到容器的classpath，是很多用户迷惑或者配置错误的根源。
Acegi Security的验证服务随后被引入。大概一年以后， Acegi Security 成为spring的官方子项目。经过大约2年半的时间，通过大量软件产品使用和数以百计的改进和社区贡献，到了2006年五月发布了1.0.0正式发行版。
在2007年末，Acegi Security成为Spring大家庭的一个正式项目，并被重命名为： Spring Security 。
如今，Spring Security拥有强大并且活跃的开源社区。论坛上有数以千计的关于Spring Security的信息。有一支活跃的核心开发人员专注于Spring Security的代码开发，一个活跃的社区经常性的共享补丁，并对其他的SpringSecurity用户提供支持。
Spring Security版本
了解的 Spring Security 的发行版本号是有用的，这会帮助你了解未来的版本中将会包含进那些功能。 Spring Security每个版本的发布都遵循3个整数的标准：MAJOR.MINOR.PATCH。
主版本MAJOR不同，说明是版本之间是不兼容的，API进行了大幅度的升级。
小版本MINOR会在MAJOR相同的情况下，保留对之前的MINOR的兼容(可能也会有设计改变或者不兼容的更新的情况)。
PATCH 级别的升级，是完全兼容的，主要是修复一些bug。
使用不同版本可能会造成的影响，主要依赖于你再代码中与Spring Secuirty的耦合程度。如果你进行了大量的定制，而不仅仅是使用namespace配置文件进行配置，你就越有可能受到影响。
在你更新到一个新的版本之后，你总是应该对应用进行全面的测试。
免费学习视频欢迎关注云图智联：https://e.yuntuzhilian.com/
