《Spring Security3》第二章第一部分翻译

第二章   Spring Security 起步

在本章中，我们将要学习 Spring Security 背后的核心理念，包括重要的术语和产品架构。我们将会关注配置 Spring Security 的一些方式以及对应用的作用。

最重要的是为了解决工作中的问题，我们要开始使得 JBCP Pets 的在线商店系统变得安全。我们将会通过分析和理解认证如何保护在线商店的适当区域来解决在第一章：一个不安全应用的剖析 中审计人员发现的第一个问题，即缺少 URL 保护和统一的认证造成的权限扩散 。

在本章的内容中，我们将会涉及：

l 了解应用中安全的重要概念；

l 使用 Spring Security 的快速配置功能，为 JBCP Pets 在线商店实现基本层次的安全；

l 理解 Spring Security 的全貌；

l 探讨认证和授权的标准配置和选项；

l 在 Spring Security 访问控制中使用 Spring 的表达式语言（ Spring Expression Language ）

 

 

安全的核心概念

         由于安全审计结果的启示作用，你研究了 Spring Security 并确定它能够提供一个坚实的基础，以此可以构建一个安全的系统来解决在安全审计 JBCP Pet 在线商店中发现的问题，而那个系统是基于 Spring Web MVC 开发的。

         为了 Spring Security 的使用更高效，在开始评估和提高我们应用的安全状况之前，先了解一些关键的概念和术语是很重要的。

认证

         正如我们在第一章所讨论的那样，认证是鉴别我们应用中的用户是他们所声明的那个人。你可能在在线或线下的日常生活中，遇到不同场景的认证：

l  凭据为基础的认证：当你登录 e-mail 账号时，你可能提供你的用户名和密码。 E-mail 的提供商会将你的用户名与数据中的记录进行匹配，并验证你提供的密码与对应的记录是不是匹配。这些凭证（用户名和密码，译者注）就是 e-mail 系统用来鉴别你是一个合法用户的。首先，我们将首先使用这种类型的认证来保护我们 JBCP Pet 在线商店的敏感区域。技术上来说， e-mail 系统能够检查凭证信息不一定非要使用数据库而是各种方式，如一个企业级的目录服务器如 Microsoft Active Directory 。一些这种类型的集成方式将在本书的第二部分讲解。

l  两 要素认证：当你想从自动柜员机取钱的时候，你在被允许取钱和做其他业务前，你必须先插卡并输入你的密码。这种方式的认证与用户名和密码的认证方式很类似， 与之不同的是用户名信息被编码到卡的磁条上了。联合使用物理磁卡和用户输入密码能是银行确认你可能有使用这个账号的权限。联合使用密码和物理设备（你的 ATM 卡）是一种普遍存在的两要素认证形式。专业来看，在安全领域，这种类型的设备在安全性要求高的系统中很常见，尤其是处理财务或个人识别信息时。硬件设备如 RSA 的 SecurId 联合使用了基于时间的硬件和服务端的认证软件，使得这样的环境极难被破坏。

l  硬件认证：早上当你启动汽车时，你插入钥匙并打火。尽管和其他的两个例子很类似，但是你的钥匙和打火装置的匹配是一种硬件认证的方式。

 

其实会有很多种的认证方式来解决硬件和软件的安全问题，它们各自也有其优缺点。我们将会在本书的后面章节中介绍它们中的一些，因为它们适用于 Spring Security 。事实上，本书的后半部分基本上都是原来介绍很多通用的认证方式用 Spring Security 的实现。

Spring Security 扩展了 java 标准概念中的已认证安全实体（对应单词 principal ）（ java.security.Principal ），它被用来唯一标识一个认证过的实体。尽管一个典型的安全实体通常一对一的指向了系统中的一个用户，但它也可能对应系统的各种客户端，如 web service 的客户端、自动运行的 feed 聚合器（ automated batch feed ）等等。在大多数场景下，在你使用 Spring Security 的过程中，一个安全实体（ Principal ）只是简单地代表一个用户（ user ），所以我当我们说一个安全实体的时候，你可以将其等同于说用户。

授权

         授权通常涉及到两个不同的方面，他们共同描述对安全系统的可访问性。

        

         第一个是已经认证的安全实体与一个或多个权限（ authorities ）的匹配关系（通常称为角色）。例如，一个非正式的用户访问你的网站将被视为只有访问的权限而一个网站的管理员将会被分配管理的权限。

         第二个是分配权限检查给系统中要进行安全保护的资源。通常这将会在系统的开发过程中进行，有可能会通过代码进行明确的声明也可能通过参数进行设置。例如，在我们应用中管理宠物商店详细目录的界面只能对具有管理权限的用户开放。

         【要进行安全保护的资源可以是系统的任何内容，它们会根据用户的权限进行有选择的可访问控制。 web 应用中的受保护资源可以是单个的页面、网站的一个完整部分或者一部分界面。相反的，受保护的业务资源可能会是业务对象的一个方法调用或者单个的业务对象。】

        

你可能想象的出对一个安全实体的权限检查过程，查找它的用户账号并确定它是不是真的为一个管理员。如果权限检查确定这个试图访问受保护区区域的安全实体实际上是管理员，那么这个请求将会成功，否则，这个安全实体的请求将会因为它缺少足够的权限而被拒绝。

我们更近距离的看一个特定的受保护资源——产品目录的编辑界面。目录的编辑界面需要管理员才能访问（毕竟，我们不希望普通的用户能够调整我们的目录层次），因此当一个安全实体访问它的时候会要求特定等级的权限。

当我们思考一个网站的管理员试图访问受保护的资源时，权限控制决定是如何做出的时候，我们猜想对受保护资源的权限的检查过程可以用集合理论很简明的进行表述。我们将会使用维恩图来展现对管理用户的这个决策过程：

 

<!--[endif]-->

对这个页面来说，在用户权限（普通用户和管理员）和需要权限（管理员）之间有一个交集，所以在交集中的用户将能够进行访问。

可以与没有授权的访问者进行对比：

 

权限集合没有交集，没有公共的元素。所以，用户将会被拒绝访问这个界面。至此，我们已经介绍了对资源授权的简单原理。

 

实际上，会有真正的代码来决定用户是允许还是被拒绝访问受保护的资源。下面的图片在整体上描述了这个过程，正如 Spring Security 所使用的那样：

 

 

我们可以看到，有一个名为访问决策管理器（ access decision manager ）的组件来负责决定一个安全实体是不是有适当的访问权限，判断基于安全实体具备的权限与被请求资源所要求资源的匹配情况。

安全访问控制器对访问是否被允许的判断过程可能会很简单，就像查看安全实体所拥有的权限集合与被访问资源所要求的资源集合是不是有交集。

让我们在 JBCP Pets 应用中简单使用 Spring Security ，并将会更详细的阐述认证和授权。