前言
Acegi Security为基于J2EE的企业级应用提供了全面安全解决方案。只要阅读这份参考指南，将发现我们会确切的给你提供一个有用且高度可配置的安全系统。
安全性是一个经常需要的功能，重要的是寻找一个全面、系统的解决方案。在安全周期中，我们鼓励采用“安全层”这一概念，以便每层都在自己的领域内尽可能地安全，各个安全层连接起来提供了附加的安全性。“tighter”各个安全层将使应用程序更加健壮安全。为了减少中间层的人为攻击，在底层需要处理如：传输安全信息、系统标识等内容。下一步你将利用防火墙，可能是VPN或IP安全通道来保证只有通过认证的系统可以尝试连接。在企业环境中，可能配置了一个DMZ把后端数据库和应用程序服务器分隔成为面向公共的服务器。你的操作系统也将扮演一个重要部分，寻址问题例如：作为非特权用户运行处理和最大文件系统安全。一个操作系统也常常使用自己的防火墙来进行配置。通过这个方法希望你能够设法阻止服务的拒绝和对系统的恶性攻击。一个入侵检测系统对于监听和回应攻击也格外有用，这样一个系统能够执行保护动作，例如：实时阻塞非法入侵的TCP/IP地址。再来说说高层，你的JAVA虚拟机将希望被配置成最小的授与权限到不同的Java类型，并且然后你的应用程序将添加自己问题域的特殊安全配置。Acegi Security使高层的问题域－应用程序安全－更加简单。
当然，你还将需要上面提到的所有安全层的适当位置，与管理要素一同构成，管理要素包含于每个层。这样一个管理要素的不完全列表包括：安全通报监听，补丁，人事，审核，调度，工程管理系统，数据备份，灾难恢复，性能评测，负载监听，集中日志，意外响应处理等等。
Acegi Security主要用于帮助你解决企业应用中的安全层，你会发现其中有许多不同的需求被作为业务逻辑的问题域。一个银行应用具有和电子商务应用不同的需求。一个电子商务应用具有和企业销售自动化工具不同的需求。这些自定义的需求使得应用程序的安全性变得有趣，有挑战性，且意义非凡。
自从Acegi Security发布1.0.0版本以来，本参考指南做了较大调整。请阅读第一部分“总体架构”，里面介绍得很完整。参考指南的余下部分被组织成更为传统的参考形式，以作为阅读的必要基础。
我们希望本参考指南对你有用，并且欢迎你的反馈和建议。
最后，欢迎来Acegi Security社区。
总体架构
像其它很多软件一样，Acegi Security必然会有核心接口，类和抽象，这些元素贯穿
于整个框架中，并且是成功规划和完成Acegi Security集成的必要条件。在这部分的参考指南中，在学习这些核心元素之前，我们将首先介绍一下Acegi Security。
第一部分 介绍 1.1开始之前
为了你的安全性应用，每个Acegi Security的官方发布包（JAR）都由我们的项目主席签名。在软件许可协议中，这是任何方法都无法更改的责任承诺，但它保证了你所使用的是一个完整的，Acegi Security的官方版本。请参考位于发布包根目录中的readme.txt文件，来验证JAR包被正确的签名，签名即是用来标识它们的证明。
1.2什么是Acegi Security
Acegi Security为基于J2EE的企业级应用提供了全面的安全解决方案服务。这里特别要强调的是支持于使用Spring框架建立的项目之上，Spring是J2EE企业级应用开发的主要解决方案。如果你不使用Spring开发企业级应用，我们真诚地鼓励你研究一下Spring。与Spring有些相似，独特的依赖注入原理，将帮助你快速且更加容易地建立Acegi Security应用。
使用Acegi Security有很多原因，但大多数是由于发现了J2EE Servlet规范或EJB规范的不足，而需要更深入的更具代表性的企业应用脚本。当叙述这些标准时，尤为重要的是这些标准并不适合在WAR或EAR级别上使用。因此，如果改变了服务器环境，通常需要重新配置应用程序的安全性来附合新的目标环境。使用Acegi Security克服了这些问题，并且也给你带来了其他有用的，完全可自定义的安全特性。
你可能知道，安全包含了两个主要操作。第一个是“认证Authentication”，它建立了一个“个体Principal”所宣称它是什么的过程。这个个体，一般指一个用户，设备或其它系统，它们可以在应用程序中执行一系列动作。“认证”指明了一个“个体”是否被允许在应用程序中执行一系列动作的过程。对于完成这一过程，“认证”的判定是需要的，这个“个体”的标识已经由认证过程建立了。这些是很普通的概念，并且不是Acegi Security所特有的。
在认证层上，Acegi Security支持的认证模型很广。大多数这些认证模型是由第三方提供的，或者由相关的标准组织（如：Internet Enginnering Task Force）开发。另外还有Acegi Security自已的认证功能集。更为突出的是，Acegi Security当前支持所有这些技术的认证：
? HTTP BASIC authentication headers (an IEFT RFC-based standard) ? HTTP Digest authentication headers (an IEFT RFC-based standard) ? HTTP X.509 client certificate exchange (an IEFT 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) ? 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 \authentication (so you can tick a box to avoid
re-authentication for a predetermined period of time)
? Anonymous authentication (allowing every 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)
? Container integration with JBoss, Jetty, Resin and Tomcat (so you can still use
Container Manager Authentication if desired) ? Your own authentication systems (see below)
许多独立软件供应商（ISV）采用了Acegi Security，由于它可供选择的丰富的认证模型。同时也允许他们快速地集成到他们任何的客户最终解决方案中，而不用操作底层技术或需要客户改变运行环境。如果上面没有一种认证机制附合你的需要，你可以十分简单地自定义认证机制，因为Acegi Security是一个开源产品。许多Acegi Security企业用户需要与遗留系统进行集成，而不能遵循任何特定的安全标准，而Acegi Security恰恰合适。
有些时候，仅仅有认证过程并不够。有时基于“个体”与应用程序之间的交互也需要辨别安全方面。例如，可能需要保证请求仅能通过https传达，以此来保护密码不被监听或最终用户的拦截攻击。再有，可能需要保证真正的人为请求，而不是机器爬虫或其它自动的处理过程。这对于从恶意攻击中保护密码的恢复过程或防止人为复制应用程序的关键内容而言，是十分有用且简单的。为了帮助你完成这个目标，Acegi Security完全支持用户（人）自动检测的“通道安全channel security”和JCaptcha的集成。
认证是如何保证的并不重要，Acegi Security提供了深层次的认证能力。主要有三个方面的认证，他们是：WEB请求认证，方法认证（可被调用），和对独立域对象实体的认证访问。为了使你了解他们三者的不同，分别思考一下Servlet规范WEB模式安全，EJB容器管理的安全和文件系统安全的认证方式。Acegi Security在所有这些重要的领域都提供了深层次的认证能力，我们将在本参考指南的后面部分探究这些内容。
1.3历史
Acegi Security开始于2003年末，当时一个关于是否考虑提供一个基于Spring的安全机制的问题在Spring开发者邮件列表中被提出。在那个时候Spring组织相当较小，并且Spring本身在2003年早期只是做为一个SourceForge项目。对于这个问题回应是非常值得的，尽管当时探究它的时间有限。
延续这人想法，一个简单的安全实现机制被建立，但没有发布。几星期后，Spring组
织的另外一些成员问起此事，这时这个代码被提供给了他们。紧跟着其它几个请求，在2004年1月大约有20几个人在使用这个代码。这些先驱者加入了另一个开发团队，这个开发团队建议申请一个SourceForge项目，2004年3月顺利地通过了。
在早些时期，项目没有多少自己的认证模型。容器管理的安全依赖于认证过程之上，而Acegi Security正聚焦于认证上。起初这是合适的，但是越来越多的用户要求其它容器的支持，容器特定的认证领域接口是最根本的限制。还有一个相关的问题是添加新的JAR包到容器的类路径，这引起了最终用户的混乱和配置错误。
Acegi Security特定的认证服务在最后介绍。大约一年后，Acegi Security变成了Spring官方的子项目。2006年5月发布了1.0.0正式版，随着在大多数软件产品项目中的使用，在随后的半年左右时间将会有许多进一步的改良和软件团体的捐赠。
现在Acegi Security拥有一个稳固且活跃的开源社团。在所支持的论坛里有上千个关于Acegi Security的信息留言。十四人开发人员工作于Acegi Security，通过社团有规则地共享补丁和技术支持。
1.4产品发布编号
很有必要了解一下Acegi Security版本发布编号是怎样的，当将帮助你标识产品的相关信息，以便将来升级到新的版本。官方地，我们使用Apache Portable Runtime Project versioning guidelines，你可以在这个网址（http://apr.apache.org/versioning.html）看到更详细地信息。为了你的便利，我们引用了以上网址所包含介绍：
“版本号使用标准的三位整数来表示：主版本.次版本.补丁（MAJOR.MINOR.PATCH）。其含义是：主版本意味着不兼容的变化很大的API的升级；次版本意味着保留了和上一个次版本在源代码和二进制代码上的兼容；补丁意味着与前后版本的完全兼容。”
第二部分 技术预览 2.1运行环境
Acegi Security是在标准JAVA 1.3运行环境下编写运行的。它同样支持JAVA 5.0，但是针对这个JAVA版本的一些特殊类型被打包成了一个独立的包，在发行版本中以“tiger”为后缀。由于Acegi Security专注于操作自身包含的行为，所以没有必要在JAVA运行环境中放入任何的特殊配置文件。特别地，没有必要配置一个专门的JAVA认证和授权服务（JAAS）策略文件或将Acegi Security放入公共类路径上。
同样地，如果使用EJB容器或Servlet容器没有必要在任何地方放置任何特定的配置文件，也不用在服务器类路径上包含Acegi Security。
以上设计提供了最大的配置灵活性，可以很容易地复制目标应用（JAR，WAR，EAR）从一个系统到另一个系统，并且立即工作。
