本应用遵循标准的三层结构，包括web层、服务层和数据访问层，如下图所示：
web层封装了MVC的代码和功能。在示例代码中，我们使用了Spring MVC框架，但是我们可以一样容易的使用Spring Web Flow，Struts甚至是一个对Spring友好的web stack如Apache Wicket。
在一个典型使用Spring Security的web应用中，大量配置和参数代码位于web层。所以，如果你没有web应用开发，尤其是Spring MVC的经验，在我们进入更复杂的话题前，你最好仔细看一下基础代码并确保你能理解。再次强调，我们已经尽力让我们的应用简单，把它构建成一个pet store只是为了给它一个合理的名字和轻量级的结构。可以将其与复杂的Java EE Pet Clinic示例作为对比，那个示例代码展现了很多技术的使用指导。
服务层封装了应用的业务逻辑。在示例应用中，我们在数据访问层前做了一个很薄的faade用来描述如何在特殊的点周围保护应用的服务方法。
在典型的web工程中，这一层将会包括业务规则校验，组装和分解BO以及交叉的关注点如审计等。
数据访问层封装了操作数据库表的代码。在很多基于Spring的工程中，这将会在这里发现使用了ORM技术如hibernate或JPA。它为服务层暴露了基于对象的API。在示例代码中，我们使用基本的JDBC功能完成到内存数据库HSQL的持久化。
在典型的web工程中，将会使用更为复杂的数据访问方式。因为ORM，即数据访问，开发人员对其很迷惑。所以为了更清晰，这一部分我们尽可能的对其进行了简化。
为了Spring Security的使用更高效，在开始评估和提高我们应用的安全状况之前，先了解一些关键的概念和术语是很重要的。
认证
正如我们在第一章所讨论的那样，认证是鉴别我们应用中的用户是他们所声明的那个人。你可能在在线或线下的日常生活中，遇到不同场景的认证：
- 凭据为基础的认证：当你登录e-mail账号时，你可能提供你的用户名和密码。E-mail的提供商会将你的用户名与数据中的记录进行匹配，并验证你提供的密码与对应的记录是不是匹配。这些凭证（用户名和密码，译者注）就是e-mail系统用来鉴别你是一个合法用户的。首先，我们将首先使用这种类型的认证来保护我们JBCP Pet在线商店的敏感区域。技术上来说，e-mail系统能够检查凭证信息不一定非要使用数据库而是各种方式，如一个企业级的目录服务器如Microsoft Active Directory。一些这种类型的集成方式将在本书的第二部分讲解。
- 两要素认证：当你想从自动柜员机取钱的时候，你在被允许取钱和做其他业务前，你必须先插卡并输入你的密码。这种方式的认证与用户名和密码的认证方式很类似，与之不同的是用户名信息被编码到卡的磁条上了。联合使用物理磁卡和用户输入密码能是银行确认你可能有使用这个账号的权限。联合使用密码和物理设备（你的ATM卡）是一种普遍存在的两要素认证形式。专业来看，在安全领域，这种类型的设备在安全性要求高的系统中很常见，尤其是处理财务或个人识别信息时。硬件设备如RSA的SecurId联合使用了基于时间的硬件和服务端的认证软件，使得这样的环境极难被破坏。
- 硬件认证：早上当你启动汽车时，你插入钥匙并打火。尽管和其他的两个例子很类似，但是你的钥匙和打火装置的匹配是一种硬件认证的方式。
其实会有很多种的认证方式来解决硬件和软件的安全问题，它们各自也有其优缺点。我们将会在本书的后面章节中介绍它们中的一些，因为它们适用于Spring Security。事实上，本书的后半部分基本上都是原来介绍很多通用的认证方式用Spring Security的实现。
Spring Security扩展了java标准概念中的已认证安全实体（对应单词principal）（java.security.Principal），它被用来唯一标识一个认证过的实体。尽管一个典型的安全实体通常一对一的指向了系统中的一个用户，但它也可能对应系统的各种客户端，如web service的客户端、自动运行的feed聚合器（automated batch feed）等等。在大多数场景下，在你使用Spring Security的过程中，一个安全实体（Principal）只是简单地代表一个用户（user），所以我当我们说一个安全实体的时候，你可以将其等同于说用户。
授权
授权通常涉及到两个不同的方面，他们共同描述对安全系统的可访问性。
第一个是已经认证的安全实体与一个或多个权限（authorities）的匹配关系（通常称为角色）。例如，一
个非正式的用户访问你的网站将被视为只有访问的权限而一个网站的管理员将会被分配管理的权限。
第二个是分配权限检查给系统中要进行安全保护的资源。通常这将会在系统的开发过程中进行，有可能会
通过代码进行明确的声明也可能通过参数进行设置。例如，在我们应用中管理宠物商店详细目录的界面只能对
具有管理权限的用户开放。
【要进行安全保护的资源可以是系统的任何内容，它们会根据用户的权限进行有选择的可访问控制。web
应用中的受保护资源可以是单个的页面、网站的一个完整部分或者一部分界面。相反的，受保护的业务资源可
能会是业务对象的一个方法调用或者单个的业务对象。】
你可能想象的出对一个安全实体的权限检查过程，查找它的用户账号并确定它是不是真的为一个管理员。如
果权限检查确定这个试图访问受保护区区域的安全实体实际上是管理员，那么这个请求将会成功，否则，这个
安全实体的请求将会因为它缺少足够的权限而被拒绝。
我们更近距离的看一个特定的受保护资源——产品目录的编辑界面。目录的编辑界面需要管理员才能访问
（毕竟，我们不希望普通的用户能够调整我们的目录层次），因此当一个安全实体访问它的时候会要求特定等
级的权限。
当我们思考一个网站的管理员试图访问受保护的资源时，权限控制决定是如何做出的时候，我们猜想对受保
护资源的权限的检查过程可以用集合理论很简明的进行表述。我们将会使用维恩图来展现对管理用户的这个决
策过程：
对这个页面来说，在用户权限（普通用户和管理员）和需要权限（管理员）之间有一个交集，所以在交集中的用户将能够进行访问。
可以与没有授权的访问者进行对比：
权限集合没有交集，没有公共的元素。所以，用户将会被拒绝访问这个界面。至此，我们已经介绍了对资源授权的简单原理。
实际上，会有真正的代码来决定用户是允许还是被拒绝访问受保护的资源。下面的图片在整体上描述了这个过程，正如Spring Security所使用的那样：
我们可以看到，有一个名为访问决策管理器（access decision manager）的组件来负责决定一个安全实体是不是有适当的访问权限，判断基于安全实体具备的权限与被请求资源所要求资源的匹配情况。
安全访问控制器对访问是否被允许的判断过程可能会很简单，就像查看安全实体所拥有的权限集合与被访问资源所要求的资源集合是不是有交集。
以上文章来自网络关于Spring Security3翻译。