Acegi Security Reference Documentation Part I. Overall Architecture
和大多數軟件一樣，Acegi Security也有一些核心接口、類、抽象類在框架中普遍使用。In this part of the reference guide we will introduce Acegi Security, before examining these central elements that are necessary to successfully planning and executing an Acegi Security integration.
第一張：介紹
1.1. Acegi Security是什么?
Acegi Security provides comprehensive security services for J2EE-based enterprise software applications. There is a particular emphasis on supporting projects built using The Spring Framework,which is the leading J2EE solution for enterprise software development. If you're not using Spring for developing enterprise applications, we warmly encourage you to take a closer look at it. Some familiarity with Spring - and in particular dependency injection principles - will help you get up to speed with Acegi Security more easily.People use Acegi Security for many reasons, but most are drawn to the project after finding the security features of J2EE's Servlet Specification or EJB Specification lack the depth required for typical enterprise application scenarios. Whilst mentioning these standards, it's important to recognise
that they are not portable at a WAR or EAR level. Therefore, if you switch server environments, it is typically a lot of work to reconfigure your application's security in the new target environment. Using Acegi Security overcomes these problems, and also brings you dozens of other useful, entirely customisable security features.
你也許知道，安全驗證包含兩個主要操作。第一個就是身份驗證(authentication")，which is the process of establishing a principal is who they claim to be. A "principal" 通常意思是一個用戶、設備或者其他系統，能夠執行一些操作在你的應用程序中。授權(Authorization)則是指決定一個principal是否有權限在你的應用程序中執行某個動作的處理。要達到這點（執行這個操作）必須要先通過身份驗證(authorization )，該principal的身份已經通過authentication處理流程并建立了連接。這些都是普通的概念，并不是Acegi Security中特有的。對于身份驗證，Acegi Security提供了a range of authentication models.大部分身份驗證模型是第三方提供的或者相關的標準框架開發的，例如the Internet Engineering 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 "remember-me" 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)
許多獨立的軟件賣家 (ISVs)采用Acegi Security的原因就是它豐富的身份驗證模型可供選擇。Doing so allows them to quickly integrate their solutions with whatever their end clients need, without undertaking a lot of engineering or requiring the client to change their environment. If none of the above authentication mechanisms suit your needs, Acegi Security is an open platform and it is quite simple to write your own authentication mechanism. Many corporate users of Acegi Security need to integrate with "legacy" systems that don't follow any particular security standards, and Acegi Security is happy to "play nicely" with such systems.
有時候僅僅身份驗證是不夠的。Sometimes you need to also differentiate
security based on the way a principal is interacting with your application. For example, you might want to ensure requests only arrive over HTTPS, in order to protect passwords from eavesdropping or end users from man-in-the-middle attacks. 或者你
希望確認是一個真實的人在做請求而不是什么自動機器或者其他的什么自動程序在做請求操作。這個對于保護密碼不被暴力破解還是很有幫助的，同樣也會使得那些想復制你的應用程序內容變得很困哪。為了幫助你來完成這些功能，Acegi Security fully supports automatic "channel security", together with JCaptcha integration for human user detection.。
不管身份驗證是如何實現的，Acegi Security提供了一套完整(a deep set)的身份驗證能力。在身份驗證中有三個主要的方面，他們是授權web請求（authorizing web request），授權方法響應(authorizing methods can be invoked)和授權單個領域對象訪問權限(authorizing access to individual domain object instances)。To help you understand the differences, consider the authorization capabilities found in the Servlet Specification web pattern security, EJB Container Managed Security and file system security respectively. Acegi Security provides deep capabilities in all of these important areas, which we'll explore later in this reference guide.
1.2. 歷史
Acegi Security開始于2003年，Spring開發郵件列表收到這樣一個問題，是否有考慮過基于Spring的安全實現方案。當時的Spring環境相對現在來說是很小的，而且Spring最早也是2003年作為一個SourceForge項目存在罷了。問題的回復是，這是一個非常有價值的領域，盡管現在沒有什么時間，但也不能停止這方面的研究。
很快，一個簡單的安全實現搞定了，但并沒有發布。幾周以后另外一個Spring團隊詢問到安全問題，這樣這個簡單的安全框架代碼交給了他們。
Several other requests followed, and by January 2004 around twenty people were using the code. These pioneering users were joined by others who suggested a SourceForge project was in order, which was duly established in March 2004.
In those early days, the project didn't have any of its own authentication modules. Container Managed Security was relied upon for the authentication process, with Acegi Security instead focusing on authorization. This was suitable at first, but as more and more users requested additional container support, the fundamental limitation of container-specific authentication realm interfaces was experienced. There was also a related issue of adding new JARs to the container's classpath, which
was a common source of end user confusion and misconfiguration.
Acegi Security-specific authentication services were subsequently introduced. Around a year later, the Acegi Security became an official Spring Framework subproject. The 1.0.0 final release was published in May 2006 - after more than two and a half years of active use in numerous production software projects and many hundreds of improvements and community contributions. Today Acegi Security enjoys a strong and active open source community. There are thousands of messages about Acegi Security on the support forums. Fourteen developers work on the code itself, with an active community who also regularly share patches and support their peers.
1.3. Release Numbering
It is useful to understand how Acegi Security release numbers work, as it will help you identify the effort (or lack thereof) involved in migrating to future releases of the project. Officially, we use the Apache Portable Runtime Project versioning guidelines, which can be viewed at http://apr.apache.org/versioning.html. We quote the introduction contained on that page for your convenience: “Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards.”