版本：v1.1

修订：2007年12月25日2:24:53

出处：blog.kysf.net

版权：作者保留对本文的一切修改、发布等权力。任何人想要转载本文部分或全部内容时，必须保留包括作者、版本、修订、出处、版权，共五项信息。对本文的参考引用，则不受限制。

关键词：subversion, 安装配置, 权限, 目录访问

1 前言
2 基本概念
2.1 什么是版本控制
2.2 什么是 Subversion
2.3 版本库（repository）
3 安装配置
3.1 安装独立服务器 SVNServer
3.2 安装 ApacheSVN 服务器
4 FAQ
5 参考资料

1、前 言

花了72小时，终于把 Subversion 初步掌握了。从一个连“什么是版本控制”都不知道的门外汉，到配置出精确至每目录访问的入门者，中间还卡了一天时间。其中费了许多气力，摸索实验了多次， 还差点放弃了，但是收获是巨大的。现把我的配置和学习过程写下来，供大家参考，也让初学者少走弯路。

由于本人不会 Unix/Linux （正在学习中），故仅以 Windows 平台为例讲解，Unix/Linux 平台请参考相关资料。如其中有谬误的地方，包括错别字，请联系我修订。

技术在分享中进步！

2、基本概念

2.1、什么是版本控制

简单点来说，版本控制就是数据仓库，它可以记录你对文件的每次更改。这样，就算你在昏天黑地的改了几个月后老板说不要了，还是按照过去那样，你也不会抓狂，简单的恢复版本操作就搞定一切。

2.2、什么是 Subversion

Subversion是一个自由/开源版本控制系统，它管理文件和目录可以超越时间。一组文 件存放在中心版本库，这个版本库很像一个普通的文件服务器，只是它可以记录每一次文件和目录的修改，这便使你可以取得数据以前的版本，从而可以检查所作的 更改。从这个方面看，许多人把版本控制系统当作一种“时间机器”。

Subversion可以通过网络访问它的版本库，从而使用户可以在不同的电脑上使用。一定 程度上可以说，允许用户在各自的地方修改同一份数据是促进协作。进展可能非常的迅速，并没有一个所有的改变都会取得效果的通道，由于所有的工作都有历史版 本，你不必担心由于失去某个通道而影响质量，如果存在不正确的改变，只要取消改变。

一些版本控制系统也是软件配置管理（SCM）系统，这种系统经过特定的精巧设计来管理源代 码，有许多关于软件开发的特性—本身理解编程语言、或者提供构建程序的工具。然而，Subversion不是这样一个系统，它是一个通用系统，可以管理任 何类型的文件集，对你这可能是源代码，对别人，可能是一个货物报价单或者是书稿等。

2.3、版本库（repository）

Subversion 的核心就是 rpository ，中文翻译成“版本库”。就是位于服务器端，统一管理和储存数据的地方。

3、安装配置

3.1 安装独立服务器 SVNServer

环境

OS：Windows XP SP2

Web：Apache 2.2.6

SVN：svn-win32-1.4.6

一、准备工作

1、获取 Subversion 服务器程序

到官方网站（http://subversion.tigris.org/）下载最新的服务器安装程序。目前最新的是1.4.6版本，具体下载地址在：http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100&expandFolder=8100&folderID=91 ，注意找 for apache 2.2.x 版本的。

2、获取 TortoiseSVN 客户端程序

从官方网站 http://tortoisesvn.net/downloads 获取最新的 TortoiseSVN 。TortoiseSVN 是一个客户端程序，用来与 subvers 服务器端通讯。Subversion 自带一个客户端程序 svn.exe ,但 TortoiseSVN 更好操作，提高效率。

二、安装服务器端和客户端

首先安装 Apache 2.2.6 ，具体安装方法大家参考相关资料，或者参看我写的《Windows下安装Apache 2.2.x》。

其次安装 Subversion（以下简称SVN）的服务器端和客户端。下载下来的服务器端是个 zip压缩包，直接解压缩即可，比如我解压到 E:\subversion 。客户端安装文件是个 exe 可执行文件，直接运行按提示安装即可，客户端安装完成后提示重启。

三、建立版本库（Repository）

运行Subversion服务器需要首先要建立一个版本库（Repository）。版本库可以看作是服务器上集中存放和管理数据的地方。

开始建立版本库。首先建立 e:\svn 空文件夹作为所有版本库的根目录。然后，进入命令行并切换到subversion的bin目录。输入如下命令：

此命令在 E:\svn 下建立一个版本库 repos1 。repos1 下面会自动生成一些文件夹和文件。

我们也可以使用 TortoiseSVN 图形化的完成这一步：

先建立空目录 E:\svn\repos1 ，注意一定是要空的。然后在 repos1 文件夹上“右键->TortoiseSVN->Create Repository here...”，然后可以选择版本库模式，这里使用默认的FSFS即可，然后就创建了一系列文件夹和文件，同命令行建立的一样。

四、运行独立服务器

此时 subversion 服务还没有开始，只是通过它的命令建立了版本库。继续在刚才的命令窗口输入：

svnserve 将会在端口 3690 等待请求，--daemon（两个短横线）选项告诉 svnserve 以守护进程方式运行，这样在手动终止之前不会退出。注意不要关闭命令行窗口，关闭窗口会把 svnserve 停止。

为了验证svnserve正常工作，使用TortoiseSVN -> Repo-browser 来查看版本库。在弹出的 URL 对话框中输入：

点 OK 按钮后就可以看见 repo1 版本库的目录树结构了，只不过这时 repo1 是个空库。

你也可以使用--root选项设置根位置来限制服务器的访问目录，从而增加安全性和节约输入svnserve URL的时间：

以前面的测试作为例，svnserve 将会运行为：

然后TortoiseSVN中的版本库浏览器URL缩减为：

五、配置用户和权限

用文本编辑器打开E:\svn\repos1\conf目录，修改svnserve.conf：

将：

改为：

即去掉前面的 # 注释符，注意前面不能有空格。

然后修改同目录的passwd文件，增加一个帐号：

将：

增加帐号：

六、初始化导入

下面就是将我们的数据（项目）导入到这个版本库，以后就由版本库管理我们的数据。我们的任何改动都回被版本库记录下来，甚至我们自己丢失、改错数据时版本库也能帮我们找回数据。

比如，我在 d:\wwwroot 下有个 guestbook 文件夹，里面存放的是我编写的留言簿程序。在此文件夹上“右键 -> TortoiseSVN -> Import...” ，在弹出对话框的“URL of repository”输入“svn://localhost/repos1/guestbook”。在“Import message”输入“导入整个留言簿”作为注释。
点 OK 后要求输入帐号。我们在用户名和密码处都输入 test 。完成后 guestbook 中的内容全部导入到了 svn://localhost/svn/repo1/guestbook 。

我们看到在 e:\svn\repo1 没有任何变化，连个 guestbook 文件夹都没有建立，唯一的变化就是e:\svn\repo1容量变大了。实际上我们源guestbook中的内容已经导入 repo1 版本库了，源 guestbook 文件夹可以删除了。

需要注意的是，这一步操作可以完全在另一台安装了 TortoiseSVN 的客户机上进行。例如运行svnserve的主机的IP是133.96.121.22，则URL部分输入的内容就是“svn://133.96.121.22” 。

七、基本操作流程

1、取出（check out）

取出版本库到一个工作拷贝：

来到任意空目录下，比如在f分区建立一个空文件夹 f:\work 。“右键 -> SVN Checkout”。在“URL of repository”中输入“svn://localhost/svn/repo1/guestbook”，这样我们就得到了一份 guestbook 中内容的工作拷贝。

2、存入（check in）/提交（commit）

在工作拷贝中作出修改并提交：

在 guestbook 工作拷贝中随便打开一个文件，作出修改，然后“右键 -> SVN Commit... ”。这样我们就把修改提交到了版本库，版本库根据情况存储我们提交的数据。

在修改过的文件上“右键 -> TortoiseSVN -> Show Log” ，可以看到对这个文件所有的提交。在不同的 revision 条目上“右键 -> Compare with working copy”，我们可以比较工作拷贝的文件和所选 revision 版本的区别。

3.2 安装 ApacheSVN 服务器

Subversion的设计包括一个抽象的网络层，这意味着版本库可以通过各种服务器进程访问。理论上讲，Subversion可以使用无限数量的网络协议实现，目前实践中存在着两种服务器。

• SVNServer：svnserve 是一个小的（也叫轻型的）、独立服务器，使用自己定义的协议和客户端。（作者注：以下称这种服务器为“svnserver服务器”，上面的安装配置就是安装svnserver服务器。）
  
  
• ApacheSVN：Apache是最流行的web服务器，通过使用 mod_dav_svn 模块，Apache可以访问版本库，并且可以使客户端使用HTTP的扩展协议WebDAV/DeltaV进行访问。（作者注：以下称这种服务器为“ApacheSVN服务器”）

通过 Http 协议访问版本库是 Subversion 的亮点之一。ApacheSVN服务器 具备了许多 svnserve服务器 没有的特性，使用上更加灵活，但是有一点难于配置，灵活通常会带来复杂性。

由于 Subversion 需要版本化的控制，因此标准的 Http 协议不能满足需求。要让 Apache 与 Subversion 协同工作，需要使用 WebDAV（Web-based Distributed Authoring and Versioning：）Web 分布式创作和版本控制）。WebDAV 是 HTTP 1.1 的扩展，关于 WebDAV 的规范和工作原理，可以参考 IETF RFC 2518 （http://www.ietf.org/rfc/rfc2518.txt）。

一、必备条件

为了让你的版本库使用HTTP网络，你必需具备以下几个条件：

1. 配置好httpd 2.2.x，并且使用mod_dav启动。
2. 为mod_dav安装mod_dav_svn插件。
3. 配置你的httpd.conf，使http协议能访问版本库。

下面以我的配置过程详细讲解。

环境：

OS：Windows XP SP2

Web：Apache 2.2.6

SVN：svn-win32-1.4.6

二、安装

1、安装Apache

具体安装方法见：《Windows下安装Apache 2.2.x》

2、安装 Subversion

将下载下来的 svn-win32-1.4.6.zip 直接解压即可，比如我解压到 e:\subversion 。
从Subversion安装目录的 bin 子目录将 intl3_svn.dll、libdb44.dll、mod_authz_svn.so、mod_dav_svn.so 拷贝到Apache的模块目录（Apache 安装目录的 modules 文件夹）。

三、基本的Apache配置

修改Apache的配置文件 httpd.conf ，使用LoadModule来加载mod_dav_svn模块。

将：

改成：

即去掉前面的“#”号。

添加：

一定确定它在 mod_dav 之后。

现在你已经设置了Apache和Subversion，但是Apache不知道如何处理 Subversion客户端，例如TortoiseSVN。为了让Apache知道哪个目录是用来作为Subversion版本库，你需要使用编辑器（例 如记事本）编辑Apache的配置文件。

在配置文件最后添加如下几行：

这个配置告诉Apache首先需要启用 dav_module，然后加载 dav_svn_module 。版本库对外的URL是：http://服务器IP/repository ，所有的Subversion版本库在物理上位于e:/svn/repos1 。

配置完毕后重新启动 Apache，打开浏览器，输入 http://服务器IP/ repository 将会看到如下画面：

这表示 Apache 的 dav_svn 模块已经可以正常工作了。用户可以使用任何一种 Subversion 的客户端通过 Http 协议访问你的版本库。

如果想要指定多个版本库，可以用多个 Location 标签，也可以使用 SVNParentPath 代替 SVNPath，例如在 e:\svn 下有多个版本库 repos1，repos2 等等，用如下方式指定：

“SVNParentPath e:/svn ” 表示 e:\svn 下的每个子目录都是一个版本库。可以通过 http://服务器IP/repository/repos1，http://服务器IP/repository/repos2 来访问。

现在你的版本库任何人都可以访问，并且有完全的写操作权限。也就是说任何人都可以匿名读取， 修改，提交，以及删除版本库中的内容(注：这时不需要配置E:\svn\repos\conf\svnserve.conf 文件，并且也不需要启动E:\subversion\bin\svnserve.exe。因为提交是通过Apache的dav模块处理的，而不是由 svnservice处理。)。我们用 TortoiseSVN 客户端验证即知。

显然大部分场合这是不符合需求的。那么如何进行权限设置呢，Apache 提供了基本的权限设置：

四、认证选项

1、基本 HTTP 认证

最简单的客户端认证方式是通过 HTTP 基本认证机制，简单的使用用户名和密码来验证一个用户的身份。Apache提供了一个 htpasswd 工具来管理一个用户文件，这个文件包含用户名和加密后的密码，这些就是你希望赋予 Subversion 特别权限的用户。htpasswd 可以在 Apache 的 bin 安装目录下找到。具体使用方法如下：

接下来修改 httpd.conf，在 Location 标签中加入如下内容：

说明：

AuthType Basic：启用基本的验证，比如用户名/密码对。

AuthName "svn repos"：当一个认证对话框弹出时，出现在认证对话框中的信息。（最好用英文，TortoiseSVN 不支持中文，安装语言包除外。）

AuthUserFile E:/usr/Apache2.2/bin/passwd：指定E:\usr\Apache2.2\bin\passwd为用户文件，用来验证用户的用户名及密码。

Require valid-user：限定用户只有输入正确的用户名及密码后才能访问这个路径

重新启动 Apache ，打开浏览器访问版本库。Apache 会提示你输入用户名和密码来认证登陆了，现在只有 passwd 文件中设定的用户才可以访问版本库。也可以配置只有特定用户可以访问，替换上述 "Require valid-user" 为 "Require user tony robert" 将只有用户文件中的 tony 和 robert 可以访问该版本库。

有的时候也许不需要这样严格的访问控制，例如大多数开源项目允许匿名的读取操作，而只有认证用户才允许写操作。为了实现更为细致的权限认证，可以使用 Limit 和 LimitExcept 标签。例如：

以上配置将使匿名用户有读取权限，而限制只有 passwd 中配置的用户可以使用写操作。

如果这还不能满足你的要求，你希望精确的控制版本库目录访问，可以使用 Apache 的 mod_authz_svn 模块对每个目录进行认证操作。

2、用 mod_authz_svn 进行目录访问控制

首先需要让 Apache 将 mod_authz_svn 模块加载进来。在 Subversion 的安装目录中找到 mod_auth_svn 模块，将其拷贝到 Apache 安装目录的 modules 子目录下。修改 httpd.conf 文件，添加：

现在可以在 Location 标签中使用 authz 的功能了。一个基本的 authz 配置如下：

AuthzSVNAccessFile 指向的是 authz 的策略文件，详细的权限控制可以在这个策略文件中指定。访问文件 accesspolicy.conf 的语法与svnserve.conf和 Apache 的配置文件非常相似，以（#）开头的行会被忽略；在它的简单形式里，每一小节命名一个版本库和一个里面的路径；认证用户名是在每个小节中的选项名；每个选 项的值描述了用户访问版本库的级别：r（只读）或者rw（读写），如果用户没有提到或者值留空，访问是不允许的； * 表示所有用户，用它控制匿名用户的访问权限；@符号区分组和用户。如：

使用 SVNParentPath 代替 SVNPath 来指定多个版本库的父目录时，其中所有的版本库都将按照这个策略文件配置。例如上例中 tony 将对所有版本库里的 /tags 目录具有读写权限。如果要对具体每个版本库配置，用如下的语法：

这样项目1的 project1_committer 组只能对 repos1 版本库下的文件具有写权限而不能修改版本库 repos2 ，同样项目2的 project2_commiter 组也不能修改 repos1 版本库的文件。

4、FAQ

1、路径或权限不足时将出现错误信息提示：

http://localhost （路径不对）
Error * PROPFIND request failed on '/' PROPFIND of '/': 200 OK (http://localhost)

http://localhost/svn （权限不足）
Error * PROPFIND request failed on '/svn' PROPFIND of '/svn': 403 Forbidden (http://localhost)

http://localhost/svn/repos （正常显示）

http://localhost/repos （权限不允许）
Error * PROPFIND request failed on '/repos' PROPFIND of '/repos': 405 Method Not Allowed (http://localhost)

2、不启动E:\subversion\bin\svnserve.exe ，但启动了ApacheSVN ，访问（tortoiseSVN –> Repo – browser）或提交（SVN Commit）情形如下：

现象：svn://localhost/svn/repos 不能访问或提交，提示：Error * Can't connect to host 'localhost': 由于目标机器积极拒绝，无法连接。 但 file:///e:/svn/repos 和 http://localhost/svn/repos 可以访问或提交。

原因：svn:// 是独立服务器 svnserver 自己的协议。file:/// 是本地访问，即服务器端和客户端在一个机器上。

参考资料：
Subversion 官方网站：Subversion 的官方网站，提供最权威的介绍和最新的下载。
Subversion 中文手册：Subversion 简体中文官方网站翻译的中文手册。
TortoiseSVN 中文文档：Subversion 简体中文官方网站翻译的 TortoiseSVN 中文文档。
我用SVN中文论坛：国内人气非常旺的 SVN 中文交流论坛。
《用Apache和Subversion搭建安全的版本控制环境》：IBM 工程师写的基于 Linux 的教程。
百度百科：由全体网民共同撰写的百科全书

~ 全文完~

1. 修改authenticationViaFormAction以使用自己的Credentials

默认的org.jasig.cas.authentication.principal.UsernamePasswordCredentials只记录用户名和密码，在扩展一些属性如验证码时使用用自己的Credentials类替换

cas-servlet.xml:
<bean id="authenticationViaFormAction" class="org.jasig.cas.web.flow.AuthenticationViaFormAction"
   p:centralAuthenticationService-ref="centralAuthenticationService"
   p:warnCookieGenerator-ref="warnCookieGenerator"
   p:formObjectName="credentials"
   p:formObjectClass="com.nlcd.cas.authentication.principal.EcardCredentials">
      <property name="validator">  
          <bean class="com.nlcd.cas.validation.EcardCredentialsValidator"/>
      </property>
</bean>

EcardCredentialsValidator:
import org.springframework.validation.Errors;
import org.springframework.validation.ValidationUtils;
import org.springframework.validation.Validator;
import com.nlcd.cas.authentication.principal.EcardCredentials;

public final class EcardCredentialsValidator implements Validator {

     public boolean supports(final Class clazz) {
         return EcardCredentials.class.isAssignableFrom(clazz);
     }

     public void validate(final Object o, final Errors errors) {
         ValidationUtils.rejectIfEmptyOrWhitespace(errors, "username",
             "required.username", null);
         ValidationUtils.rejectIfEmptyOrWhitespace(errors, "password",
             "required.password", null);
     }
}

EcardCredentials: (加入一个idtype属性)
import org.jasig.cas.authentication.principal.Credentials;

public class EcardCredentials implements Credentials {

/** Unique ID for serialization. */
private static final long serialVersionUID = -7863273946921255486L;

private String idtype;

/** The username. */
     private String username;

     /** The password. */
     private String password;

     public String getIdtype() {
   return idtype;
}

public void setIdtype(String idtype) {
   this.idtype = idtype;
}

/**
      * @return Returns the password.
      */
     public final String getPassword() {
         return this.password;
     }

     /**
      * @param password The password to set.
      */
     public final void setPassword(final String password) {
         this.password = password;
     }

     /**
      * @return Returns the userName.
      */
     public final String getUsername() {
         return this.username;
     }

     /**
      * @param userName The userName to set.
      */
     public final void setUsername(final String userName) {
         this.username = userName;
     }

     public String toString() {
         return this.username;
     }

     public boolean equals(final Object obj) {
         if (obj == null || !obj.getClass().equals(this.getClass())) {
             return false;
         }

         final EcardCredentials c = (EcardCredentials) obj;

         return this.idtype.equals(c.getIdtype()) && this.username.equals(c.getUsername())
             && this.password.equals(c.getPassword());
     }

     public int hashCode() {
         return this.idtype.hashCode() ^ this.username.hashCode() ^ this.password.hashCode();
     }
}

2. 部署自己的authenticationHandlers

deployerConfigContext.xml:
<property name="credentialsToPrincipalResolvers">
    <list>
     <bean
      class="com.nlcd.cas.authentication.principal.EcardCredentialsToPrincipalResolver" />
     <bean
      class="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver" />
    </list>
   </property>

   <property name="authenticationHandlers">
    <list>
     <bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler"
      p:httpClient-ref="httpClient" />
     <bean
      class="com.nlcd.cas.authentication.handler.support.EcardAuthenticationHandler" />
    </list>
   </property>

EcardCredentialsToPrincipalResolver:
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.jasig.cas.authentication.principal.CredentialsToPrincipalResolver;
import org.jasig.cas.authentication.principal.Credentials;
import org.jasig.cas.authentication.principal.Principal;
import org.jasig.cas.authentication.principal.SimplePrincipal;

public final class EcardCredentialsToPrincipalResolver implements
     CredentialsToPrincipalResolver {

     /** Logging instance. */
     private final Log log = LogFactory.getLog(getClass());

     public Principal resolvePrincipal(final Credentials credentials) {
         final EcardCredentials ecardCredentials = (EcardCredentials) credentials;

         if (log.isDebugEnabled()) {
             log.debug("Creating SimplePrincipal for ["
                 + ecardCredentials.getUsername() + "]");
         }

         return new SimplePrincipal(ecardCredentials.getUsername());
     }

     public boolean supports(final Credentials credentials) {
         return credentials != null
             && EcardCredentials.class.isAssignableFrom(credentials
                 .getClass());
     }
}

EcardAuthenticationHandler:
import org.jasig.cas.authentication.handler.AuthenticationException;
import org.jasig.cas.authentication.handler.AuthenticationHandler;
import org.jasig.cas.authentication.principal.Credentials;
import org.jasig.cas.util.annotation.NotNull;
import com.nlcd.cas.authentication.principal.EcardCredentials;

public final class EcardAuthenticationHandler implements AuthenticationHandler {

private static final Class<EcardCredentials> DEFAULT_CLASS = EcardCredentials.class;

/** Class that this instance will support. */
@NotNull
private Class<?> classToSupport = DEFAULT_CLASS;

private boolean supportSubClasses = true;

public EcardAuthenticationHandler() {
}

public final boolean authenticate(final Credentials credentials)
    throws AuthenticationException {
   //TODO: your code here
   return true;
}

public final boolean supports(final Credentials credentials) {
   return credentials != null
     && (this.classToSupport.equals(credentials.getClass()) || (this.classToSupport
       .isAssignableFrom(credentials.getClass()))
       && this.supportSubClasses);
}
}

3. 配置Tomcat使用SSL安全认证

生成服务器端密钥:
keytool -genkey -alias nlcdcas -keyalg RSA -keypass changeit -storepass changeit -keystore server.keystore
您的名字与姓氏是什么？
  [192.168.61.56]：  192.168.61.56
您的组织单位名称是什么？
  [nlce]：  nlcd
您的组织名称是什么？
  [Unknown]：  nlcd
您所在的城市或区域名称是什么？
  [Unknown]：  beijing
您所在的州或省份名称是什么？
  [Unknown]：  beijing
该单位的两字母国家代码是什么
  [Unknown]：  cn
CN=192.168.61.56, OU=nlcd, O=nlcd, L=beijing, ST=beijing, C=cn 正确吗？
  [否]：  y

生成服务器端证书:
keytool -export -alias nlcdcas -storepass changeit -file server.cer -keystore server.keystore

导入证书文件到cacerts 文件中:
keytool -import -trustcacerts -alias server -file server.cer -keystore cacerts -storepass changeit

把cacerts文件，拷贝到<JAVA_HOME>\jre\lib\security目录下;server.keystore拷贝到Tomcat安装目录下

修改Tomcat的配置文件server.xml把以下补注释的内容打开

<Connector port="8443" maxHttpHeaderSize="8192"

               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

               enableLookups="false" disableUploadTimeout="true"

               acceptCount="100" scheme="https" secure="true"

               clientAuth="false" sslProtocol="TLS" />

加入红字部份后的内容如下：

         <Connector port="8443" maxHttpHeaderSize="8192"

keystorePass="changeit" keystoreFile="/server.keystore"

               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

               enableLookups="false" disableUploadTimeout="true"

               acceptCount="100" scheme="https" secure="true"

               clientAuth="false" sslProtocol="TLS" />

大部分开发者都应该熟悉基于Windows NT内核的Windows操作系统，比如Windows 2000、2003、XP。事实上，Windows操作系统本身充当了管理千万个领域对象的角色，这里的领域对象就是那些文件夹和文件。各个文件夹可以含有子文件夹，也可以含有大量的文件。文件是叶节点，它不再包含任何子元素。从领域对象的角度出发，文件夹和文件自身都持有各自的访问控制列表（Access Control List，ACL），ACL用于给定操控这些领域对象的权限信息，比如marissa用户可以操作shared目录，而scott用户不能够操作shared目录等。

为了同基于角色授权区分开，对于领域对象而言，访问控制列表（Access Control List，ACL）成为了各个领域对象的“专有名词”。这意味着，角色授权适用于Web资源和业务方法，而ACL授权适用于领域对象。各个ACL可能持有若干个ACE，即Access Control Entry（访问控制项）。总之，各个领域对象都会存在对应它的ACL，而各个ACL会持有若干个ACE，ACE真正给出了操控当前领域对象的具体权限信息。

14.1.1  保护领域对象概述

Acegi于org.acegisecurity.acls.domain包内置了表示ACL的如下Acl接口。通过这一接口，我们能够获得ACL持有的ACE集合、当前ACL对应的领域对象、这一ACL的持有人（主人）、当前ACL的父ACL等。

public interface Acl extends Serializable {

     //获得当前ACL持有的ACE集合

    public AccessControlEntry[] getEntries();

     //当前ACL对应的领域对象

    public ObjectIdentity getObjectIdentity();

     //持有这一ACL的主人

    public Sid getOwner();

     //获得当前ACL的父ACL

    public Acl getParentAcl();

     //父ACL是否允许被当前ACL继承

    public boolean isEntriesInheriting();

     //用于ACL授权决定

    public boolean isGranted(Permission[] permission, Sid[] sids,

               boolean administrativeMode)

        throws NotFoundException, UnloadedSidException;

     //判断当前ACL是否已持有传入的sids

    public boolean isSidLoaded(Sid[] sids);

}

图14-1展示了Acegi内置的Acl继承链，处于继承链中的各个接口及类各有各的用途。比如，借助于MutableAcl能够修改当前的AclImpl实例，借助于AuditableAcl能够完成ACL中ACE的审计，借助于OwnershipAcl能够修改当前AclImpl实例的主人。

图14-1  Acl继承链

下面给出了Acegi内置的用于表示ACE的AccessControlEntry策略接口。通常，Acl同AccessControlEntry具有1:N的关系，单个Acl持有若干个AccessControlEntry。

public interface AccessControlEntry {

    //获得其所在的ACL

    public Acl getAcl();

    //标识当前的ACE

    public Serializable getId();

    //表示的ACL（ACE）权限信息

    public Permission getPermission();

    //当前ACL（ACE）权限信息的持有人，比如marissa用户

    public Sid getSid();

    //当前ACL（ACE）权限信息是否已经授给了Sid

    public boolean isGranting();

}

图14-2展示了Acegi内置的AccessControlEntry继承链。

图14-2  AccessControlEntry继承链

在借助Acegi保护领域对象期间，开发者几乎不用同Acl和AccessControlEntry打交道，至少不用同AclImpl和AccessControlEntryImpl实现类交互。Acl和AccessControlEntry都使用到Sid接口，而Acl还使用到ObjectIdentity接口。Sid用于表示ACL授权过程中的授权对象，比如marissa用户、ROLE_USER角色都可以成为Sid的表示对象。图14-3展示了Acegi内置的Sid继承链。开发者将用户名、Authentication对象传入PrincipalSid构建器便能够构建出PrincipalSid对象；同理，将角色、GrantedAuthority对象传入GrantedAuthoritySid构建器便能够构建出GrantedAuthoritySid对象。ObjectIdentity用于标识单个领域对象，这一对象的存在使得目标企业应用同Acegi间的耦合得到降低，ObjectIdentityImpl是Acegi内置的唯一ObjectIdentity实现类。

图14-3  Sid继承链

Acegi提供的ACL子系统正是围绕Acl、AccessControlEntry、Sid、ObjectIdentity展开的，这些对象存活于业务系统与RDBMS间。也正是这些接口的存在，我们才能够将Acegi提供的ACL子系统作用到任何RDBMS中。也就是说，Acegi提供的领域对象支持适合于所有的RDBMS、O/R Mapping技术。为了能够从RDBMS装载到相关对象，我们需要使用Acegi内置的如下AclService接口。

//获得ACL

public interface AclService {

     //查找到parentIdentity的所有子ObjectIdentity，ACL管理工具经常要使用到它

    public ObjectIdentity[] findChildren(ObjectIdentity parentIdentity);

     //通过ObjectIdentity获得单个Acl对象

    public Acl readAclById(ObjectIdentity object) throws NotFoundException;

     //通过ObjectIdentity获得仅适合于sids的单个Acl对象

    public Acl readAclById(ObjectIdentity object, Sid[] sids)

        throws NotFoundException;

     //获得ObjectIdentity[]对应的Acl对象集合

    public Map readAclsById(ObjectIdentity[] objects) throws NotFoundException;

     //通过ObjectIdentity[]获得仅适合于sids的Acl对象集合

    public Map readAclsById(ObjectIdentity[] objects, Sid[] sids)

        throws NotFoundException;

}

图14-4展示了Acegi内置的AclService继承链，处于这一继承链中的各个接口及实现类各有各的用途。比如，JdbcAclService用于实现AclService策略接口。

图14-4  AclService继承链

MutableAclService用于维护Acl实例，开发者经常要同这一策略接口打交道，其定义如下。JdbcMutableAclService实现了MutableAclService。注意，开发者也可以提供O/R Mapping技术对应的AclService实现，比如Hibernate、JPA。Acegi仅仅实现了JDBC版本的AclService，开发者可以在自身的应用中同时使用O/R Mapping技术和JDBC。

//维护Acl实例

public interface MutableAclService extends AclService {

     //在RDBMS中创建不含ACE的ACL，即Acl对象

    public MutableAcl createAcl(ObjectIdentity objectIdentity)

        throws AlreadyExistsException;

     //从RDBMS中删除objectIdentity对应的ACL

    public void deleteAcl(ObjectIdentity objectIdentity, boolean deleteChildren)

        throws ChildrenExistException;

     //将现有的acl实例同步到RDBMS中

    public MutableAcl updateAcl(MutableAcl acl) throws NotFoundException;

}

通过本节内容，我们大致了解了Acegi提供的用于ACL子系统的各主要接口。本章后续内容将围绕这些接口展开论述。

14.1.3  ACL权限的定义

我们可以对领域对象进行各种操作，比如新增、删除、修改、浏览、管理等。Acegi将各种ACL权限信息建模在BasePermission对象中，相关的ACL权限信息摘录如下。开发者经常需要同READ、WRITE、CREATE、DELETE、ADMINISTRATION等ACL权限打交道，这些权限的含义非常容易理解。借助于FieldRetrievingFactoryBean，开发者能够在DI容器中配置它们。

public static final Permission READ =

      new BasePermission(1 << 0, 'R'); // 1

public static final Permission WRITE =

      new BasePermission(1 << 1, 'W'); // 2

public static final Permission CREATE =

      new BasePermission(1 << 2, 'C'); // 4

public static final Permission DELETE =

      new BasePermission(1 << 3, 'D'); // 8

public static final Permission ADMINISTRATION =

      new BasePermission(1 << 4, 'A'); // 16

图14-7展示了Acegi内置的Permission继承链。BasePermission将基本的权限建模好了，而借助于CumulativePermission，开发者能够建构复合权限。比如，我们可以对READ、WRITE等权限进行逻辑或运算，进而在RDBMS中存储复合权限，从而简化了ACL授权操作。

图14-7  Permission继承链

下面摘录了ADMINISTRATION、READ、DELETE权限的定义示例，这些配置信息同样摘自于applicationContext-common-authorization.xml配置文件。各个AclEntryVoter投票器和AbstractAclProvider子类需要引用到这些ACL权限定义。

<bean id="BasePermission.ADMINISTRATION"

      class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean">

      <property name="staticField">

               <value>org.acegisecurity.acls.domain.BasePermission.ADMINISTRATION</value>

      </property>

</bean>

<bean id="BasePermission.READ"

      class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean">

      <property name="staticField">

               <value>org.acegisecurity.acls.domain.BasePermission.READ</value>

      </property>

</bean>

<bean id="BasePermission.DELETE"

      class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean">

      <property name="staticField">

               <value>org.acegisecurity.acls.domain.BasePermission.DELETE</value>

      </property>

</bean>

在熟悉Acegi中ACL子系统的各个术语及基本概念后，我们需要通过实际企业应用验证它们，从而加深对它们的理解。

14.2.1  RDBMS表的建立

为了实施基于Acegi ACL领域对象授权支持的企业应用，开发者必须建立好同ACL相关的4张RDBMS表。它们的名字和含义如下。

l  acl_class：用于存储领域对象对应的全限定名，比如sample.contact.Contact。

l  acl_sid：用于存储ACL授权对象，或者是用户名，或者是角色名。比如，marissa用户、ROLE_USER角色。

l  acl_object_identity：用于存储领域对象对应的Acl信息。

l  acl_entry：用于存储Acl（acl_object_identity）对应的AccessControlEntry信息。默认时，acl_object_identity同acl_entry构成了主从表关系，并以1:N关系存在。

图14-8展示了这4张表间的具体关系，这是采用Hibernate Tools获得的图形化表示，此外，图中还展示了Acegi contacts示例存储领域对象的contacts表、存储用户和角色信息的users和authorities表。值得开发者注意的是，contacts、users、authorities表与ACL对应的4张表并无直接联系。接下来，我们来一一研究这些表的设计和内容。由于Acegi contacts示例采用了HSQLDB RDBMS，因此这些表对应的SQL DDL语句不能够直接用于其他生产数据库，比如Oracle 10g、SQL Server 2005。在领会Acegi ACL的思想后，开发者能够很轻松地给出特定数据库版本的ACL表定义。

图14-8  contacts示例设计的RDBMS表

其一，users表的定义如下：username列用于存储用户名，password列用于存储密码，enabled列用于存储启用标志位。

create table users(

      username varchar_ignorecase(50) not null primary key,

      password varchar_ignorecase(50) not null,

      enabled boolean not null

);

图14-9给出了users表中已存储的示例数据。这里的password列的内容经过了MD5加密处理。

图14-9  users表已存储的示例数据

其二，authorities表的定义如下：username列用于存储用户名，authority列用于存储角色名。

create table authorities(

      username varchar_ignorecase(50) not null,

      authority varchar_ignorecase(50) not null,

      constraint fk_authorities_users foreign key(username) references users(username)

);

create unique index ix_auth_username on authorities(username,authority);

图14-10给出了authorities表中已存储的示例数据，其中的username列数据引用到users表中username列的数据。默认时，users和authorities表处于1:N的关系。

图14-10  authorities表已存储的示例数据

其三，contacts表的定义如下：id列用于标识领域对象，contact_name列存储联系人的姓名，而email列用于存储联系人的邮件地址。

create table contacts(

      id bigint not null primary key,

      contact_name varchar_ignorecase(50) not null,

      email varchar_ignorecase(50) not null

);

图14-11给出了contacts表中已存储的示例数据。

图14-11  contacts表已存储的示例数据

在实际企业应用中，存在大量的领域对象，因而会存在大量的RDBMS表来存储它们。类似地，实际企业应用存储用户、角色信息的RDBMS表也不一定是users、authorities表，相信仔细阅读过本书相关章节的开发者都知道如何自定义它们。好了，再来研究4张ACL表的SQL DDL语句及相应的示例数据。

其四，acl_class表的定义如下：id列用于标识领域对象对应的全限定名，而class列用于存储领域对象对应的全限定名。

create table acl_class(

      id bigint generated by default as identity(start with 100) not null primary key,

      class varchar_ignorecase(100) not null,

      constraint unique_uk_2 unique(class)

);

图14-12给出了acl_class表中已存储的示例数据。由于Acegi contacts示例仅仅存在单个Contact领域对象类型，因此这一表仅仅存在单条记录。

图14-12  acl_class表已存储的示例数据

其五，acl_sid表的定义如下：principal列用于给定sid列的类型，即同一记录中存储了用户名还是角色名。相比之下，sid列存储用户名或者角色名。如果sid列存储了用户名，则principal列取值为true；如果sid列存储了角色名，则principal列取值为false。

create table acl_sid(

      id bigint generated by default as identity(start with 100) not null primary key,

      principal boolean not null,

      sid varchar_ignorecase(100) not null,

      constraint unique_uk_1 unique(sid,principal)

);

图14-13给出了acl_sid表中已存储的示例数据。由于sid列存储的数据都是用户名，因此principal列取值都为true。在某种程度上，acl_sid对应于Sid对象。

图14-13  acl_sid表已存储的示例数据

其六，acl_object_identity表的定义如下：id列为主键。其中，object_id_class引用到acl_class中的id列取值，图14-14中的object_id_class列取值都是100，即Contact领域对象类型。类似地，object_id_identity列的内容起到绑定特定领域对象的作用。比如，在contacts示例应用中，object_id_identity列的内容同contacts表中id列的内容保持一致。注意，开发者也可以通过其他策略维护object_id_identity列同特定领域对象间的绑定关系。默认时，我们建议领域对象都能够含有id属性，因为ObjectIdentityImpl可能会通过反射机制调用到领域对象的getId()方法，并将返回结果存储到object_id_identity列。最后，parent_object列用于指定当前ACL的父ACL，而own_sid列用于存储当前ACL的主人，entries_inheriting列用于指定当前ACL是否继承父ACL（含有的ACE集合）。可以看出，owner_sid列取值引用到acl_sid中id列取值。

create table acl_object_identity(

      id bigint generated by default as identity(start with 100) not null primary key,

      object_id_class bigint not null,

      object_id_identity bigint not null,

      parent_object bigint,

      owner_sid bigint,

      entries_inheriting boolean not null,

      constraint unique_uk_3 unique(object_id_class,object_id_identity),

      constraint foreign_fk_1 foreign key(parent_object)references acl_object_identity(id),

      constraint foreign_fk_2 foreign key(object_id_class)references acl_class(id),

      constraint foreign_fk_3 foreign key(owner_sid)references acl_sid(id)

);

图14-14给出了RDBMS acl_object_identity表中已存储的示例数据。在某种程度上，acl_object_identity对应于Acl对象。

图14-14  acl_object_identity表已存储的示例数据

其七，acl_entry表的定义如下：id列是主键。其中，acl_object_identity表指定当前ACE所属的ACL，即对应到acl_object_identity表中的id列。类似地，sid列用于存储当前ACE所属的授权对象，它对应于acl_sid表中的id列；ace_order列对ACE集合进行排序；mask列存储ACE权限信息，具体情况请参考BasePermission和CumulativePermission类；granting列表明当前的ACE权限是否已经授给了同一记录持有的sid列（用户名或角色）；audit_success和audit_failure列用于审计目的，供各种基于Acegi ACL的管理工具在审计ACL（ACE）时使用。开发者可以借助于Acegi暴露的API开发出相应的审计（管理）工具。

create table acl_entry(

      id bigint generated by default as identity(start with 100) not null primary key,

      acl_object_identity bigint not null,

      ace_order int not null,

      sid bigint not null,

      mask integer not null,

      granting boolean not null,

      audit_success boolean not null,

      audit_failure boolean not null,

      constraint unique_uk_4 unique(acl_object_identity,ace_order),

      constraint foreign_fk_4 foreign key(acl_object_identity) references acl_object_identity(id),

      constraint foreign_fk_5 foreign key(sid) references acl_sid(id)

);

图14-15给出了RDBMS acl_entry表中已存储的示例数据。在某种程度上，acl_entry对应于AccessControlEntry对象。

图14-15  acl_entry表已存储的示例数据

    <bean id="aclBeanReadVoter" class="org.acegisecurity.vote.BasicAclEntryVoter">
        <property name="processConfigAttribute">
            <value>ACL_READ</value>
        </property>
        <property name="processDomainObjectClass">
            <value>org.springside.modules.security.acl.domain.AclDomainAware</value>
        </property>
        <property name="aclManager">
            <ref local="aclManager"/>
        </property>
        <property name="requirePermission">
            <list>
                <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/>
                <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.READ"/>
            </list>
        </property>
    </bean>

1. ACL_READ指的是这个Voter对哪些SecurityConfig起作用，我们可以把ACL_READ配置在想要拦截的Method上。比方说我们要拦截readOrder这个方法，以实现ACL控制，可以这样配置。
   orderManager.readOrder=ACL_READ
2. processDomainObjectClass指出哪些DomainObject是要进行ACL校验的。
3. aclManager是一个比较重要的概念，主要负责在权限列表中根据用户和DomainObject取得acl列表。
4. requirePermission指出要进行这个操作必须具备的acl权限，比方说read操作就必须有ADMINISTRATION或READ两个权限。

其实整个过程看下来比较清晰，下面来看一下AclManager如何配置。

    <!-- ========= ACCESS CONTROL LIST LOOKUP MANAGER DEFINITIONS ========= -->

    <bean id="aclManager" class="org.acegisecurity.acl.AclProviderManager">
        <property name="providers">
            <list>
                <ref local="basicAclProvider"/>
            </list>
        </property>
    </bean>

    <bean id="basicAclProvider" class="org.acegisecurity.acl.basic.BasicAclProvider">
        <property name="basicAclDao">
            <ref local="basicAclExtendedDao"/>
        </property>
    </bean>

    <bean id="basicAclExtendedDao" class="org.acegisecurity.acl.basic.jdbc.JdbcExtendedDaoImpl">
        <property name="dataSource">
            <ref bean="dataSource"/>
        </property>
    </bean>

在数据库中取得。既然提到了数据库，那我们就来看一下Acegi默认提供的ACL在数据库里的保存表结构：

CREATE TABLE acl_object_identity (
id IDENTITY NOT NULL,
object_identity VARCHAR_IGNORECASE(250) NOT NULL,
parent_object INTEGER,
acl_class VARCHAR_IGNORECASE(250) NOT NULL,
CONSTRAINT unique_object_identity UNIQUE(object_identity),
FOREIGN KEY (parent_object) REFERENCES acl_object_identity(id)
);
CREATE TABLE acl_permission (
id IDENTITY NOT NULL,
acl_object_identity INTEGER NOT NULL,
recipient VARCHAR_IGNORECASE(100) NOT NULL,
mask INTEGER NOT NULL,
CONSTRAINT unique_recipient UNIQUE(acl_object_identity, recipient),
FOREIGN KEY (acl_object_identity) REFERENCES acl_object_identity(id)
);

1. acl_object_identity表存放了所有受保护的domainObject的信息。其中object_identity字段保存了domainObject的class和id，默认的保存格式是：domainClass:domainObjectId。
2. acl_permission 就是ACL权限列表了，recipient 是用户或角色信息，mask表示了这个用户或角色对这个domainObject的访问权限。注意这些信息的保存格式都是可以根据自己的需要改变的。

这样读取和删除的时候Acegi就能很好的完成拦截工作，但是读取一个List的时候，如何才能把该用户不能操作的domainObject剔除掉呢？这就需要afterInvocationManager来完成这个工作。下面来看下配置：

    <!-- ============== "AFTER INTERCEPTION" AUTHORIZATION DEFINITIONS =========== -->

    <bean id="afterInvocationManager" class="org.acegisecurity.afterinvocation.AfterInvocationProviderManager">
        <property name="providers">
            <list>
                <ref local="afterAclCollectionRead"/>
            </list>
        </property>
    </bean>
    <!-- Processes AFTER_ACL_COLLECTION_READ configuration settings -->
    <bean id="afterAclCollectionRead" class="org.acegisecurity.afterinvocation.BasicAclEntryAfterInvocationCollectionFilteringProvider">
        <property name="aclManager">
            <ref local="aclManager"/>
        </property>
        <property name="requirePermission">
            <list>
                <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/>
                <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.READ"/>
            </list>
        </property>
    </bean>

      <bean id="bankManagerSecurity" 
                     class="net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor">
             <property name="validateConfigAttributes">
                    <value>true</value>
            </property>
            <property name="authenticationManager">
                   <ref bean="authenticationManager"/>
            </property>
            <property name="accessDecisionManager">
                  <ref bean="accessDecisionManager"/>
            </property>
            <property name="objectDefinitionSource">
                  <value>
                     net.sf.acegisecurity.context.BankManager.delete*=
                             ROLE_SUPERVISOR,RUN_AS_SERVER
                     net.sf.acegisecurity.context.BankManager.getBalance=
                             ROLE_TELLER,ROLE_SUPERVISOR,BANKSECURITY_CUSTOMER,RUN_
                  </value>
            </property>
      </bean> 

<bean id="authenticationDao" class="net.sf.acegisecurity.providers.dao.jdbc.JdbcDaoImpl">
               <property name="dataSource"><ref bean="dataSource"/></property>
      </bean>
      <bean id="daoAuthenticationProvider" 
                     class="net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider">
               <property name="authenticationDao"><ref bean="authenticationDao"/></property>
      </bean>
      <bean id="authenticationManager" class="net.sf.acegisecurity.providers.ProviderManager">
               <property name="providers">
                      <list><ref bean="daoAuthenticationProvider"/></list>
               </property>
      </bean>
      <bean id="roleVoter" class="net.sf.acegisecurity.vote.RoleVoter"/>
      <bean id="accessDecisionManager" class="net.sf.acegisecurity.vote.AffirmativeBased">
               <property name="allowIfAllAbstainDecisions"><value>false</value></property>
               <property name="decisionVoters">
                      <list><ref bean="roleVoter"/></list>
               </property>
      </bean>

 log4j.rootLogger=debug, stdout, R
  log4j.appender.stdout=org.apache.log4j.ConsoleAppender
  log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

  # Pattern to output the caller's file name and line number.
  log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n

  log4j.appender.R=org.apache.log4j.RollingFileAppender
  log4j.appender.R.File=example.log
  log4j.appender.R.MaxFileSize=100KB

  # Keep one backup file
  log4j.appender.R.MaxBackupIndex=1

  log4j.appender.R.layout=org.apache.log4j.PatternLayout
  log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n

 import com.foo.Bar;
  import org.apache.log4j.Logger;
  import org.apache.log4j.PropertyConfigurator;
  public class MyApp {
    static Logger logger = Logger.getLogger(MyApp.class.getName());
    public static void main(String[] args) {
      // BasicConfigurator replaced with PropertyConfigurator.
      PropertyConfigurator.configure(args[0]);
      logger.info("Entering application.");
      Bar bar = new Bar();
      bar.doIt();
      logger.info("Exiting application.");
    }
  }

<filter>
  <filter-name>Acegi Channel Processing Filter</filter-name>
  <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
  <init-param>
    <param-name>targetClass</param-name>
    <param-value>net.sf.acegisecurity.securechannel.ChannelProcessingFilter</param-value>
  </init-param>
</filter>
<filter>
  <filter-name>Acegi Authentication Processing Filter</filter-name>
  <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
  <init-param>
    <param-name>targetClass</param-name>
    <param-value>net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter</param-value>
  </init-param>
</filter>
<filter>
  <filter-name>Acegi HTTP BASIC Authorization Filter</filter-name>
  <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
  <init-param>
    <param-name>targetClass</param-name>
    <param-value>net.sf.acegisecurity.ui.basicauth.BasicProcessingFilter</param-value>
  </init-param>
</filter>
<filter>
  <filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
  <filter-class>net.sf.acegisecurity.ui.AutoIntegrationFilter</filter-class>
</filter>
<filter>
  <filter-name>Acegi HTTP Request Security Filter</filter-name>
  <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
  <init-param>
    <param-name>targetClass</param-name>
    <param-value>net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter</param-value>
  </init-param>
</filter>

<filter-mapping>
  <filter-name>Acegi Channel Processing Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
  <filter-name>Acegi Authentication Processing Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
  <filter-name>Acegi HTTP BASIC Authorization Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
  <filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
  <filter-name>Acegi HTTP Request Security Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

CREATE TABLE users (
    username VARCHAR(50) NOT NULL PRIMARY KEY,
    password VARCHAR(50) NOT NULL,
    enabled BIT NOT NULL
);
CREATE TABLE authorities (
    username VARCHAR(50) NOT NULL,
    authority VARCHAR(50) NOT NULL
);
CREATE UNIQUE INDEX ix_auth_username ON authorities ( username, authority );
ALTER TABLE authorities ADD CONSTRAINT fk_authorities_users foreign key (username) REFERENCES users
(username);

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
  <property name="driverClassName"><value>${jdbc.driverClassName}</value></property>
  <property name="url"><value>${jdbc.url}</value></property>
  <property name="username"><value>${jdbc.username}</value></property>
  <property name="password"><value>${jdbc.password}</value></property>
</bean>
<bean id="jdbcDaoImpl" class="net.sf.acegisecurity.providers.dao.jdbc.JdbcDaoImpl">
  <property name="dataSource"><ref bean="dataSource"/></property>
</bean>

<bean id="daoAuthenticationProvider" class="net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider">
  <property name="authenticationDao"><ref bean="authenticationDao"/></property>
  <property name="userCache"><ref bean="userCache"/></property>
</bean>

<bean id="userCache" class="net.sf.acegisecurity.providers.dao.cache.EhCacheBasedUserCache">
  <property name="minutesToIdle"><value>5</value></property>
</bean>

<bean id="authenticationManager" class="net.sf.acegisecurity.providers.ProviderManager">
  <property name="providers">
    <list>
      <ref bean="daoAuthenticationProvider"/>
    </list>
   </property>
</bean>

<bean id="accessDecisionManager" class="net.sf.acegisecurity.vote.AffirmativeBased">
  <property name="allowIfAllAbstainDecisions">
    <value>false</value>
  </property>
  <property name="decisionVoters">
    <list><ref bean="roleVoter"/></list>
  </property>
</bean>
<bean id="roleVoter" class="net.sf.acegisecurity.vote.RoleVoter"/>

<bean id="authenticationProcessingFilterEntryPoint" 
class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">
  <property name="loginFormUrl"><value>/acegilogin.jsp</value></property>
  <property name="forceHttps"><value>false</value></property>
</bean>

<%@ taglib prefix='c' uri='http://java.sun.com/jstl/core' %>
<%@ page import="net.sf.acegisecurity.ui.AbstractProcessingFilter" %>
<%@ page import="net.sf.acegisecurity.AuthenticationException" %>
<html>
  <head>
    <title>Login</title>
  </head>

  <body>
    <h1>Login</h1>
    <form action="<c:url value='j_acegi_security_check'/>" method="POST">
      <table>
        <tr><td>User:</td><td><input type='text' name='j_username'></td></tr>
        <tr><td>Password:</td><td><input type='password' name='j_password'></td></tr>
        <tr><td colspan='2'><input name="submit" type="submit"></td></tr>
        <tr><td colspan='2'><input name="reset" type="reset"></td></tr>
      </table>
    </form>
  </body>
</html>

<bean id="filterInvocationInterceptor" 
class="net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor">
  <property name="authenticationManager">
    <ref bean="authenticationManager"/>
  </property>
  <property name="accessDecisionManager">
    <ref bean="accessDecisionManager"/>
  </property>
  <property name="objectDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      \A/sec/administrator.*\Z=ROLE_SUPERVISOR
      \A/sec/user.*\Z=ROLE_TELLER
    </value>
  </property>
</bean>

<bean id="securityEnforcementFilter" class="net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter">
  <property name="filterSecurityInterceptor">
    <ref bean="filterInvocationInterceptor"/>
  </property>
  <property name="authenticationEntryPoint">
    <ref bean="authenticationProcessingFilterEntryPoint"/>
  </property>
</bean>

<bean id="authenticationProcessingFilter" 
class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
  <property name="authenticationManager">
    <ref bean="authenticationManager"/>
  </property>
  <property name="authenticationFailureUrl">
    <value>/loginerror.jsp</value>
  </property>
  <property name="defaultTargetUrl">
    <value>/</value>
  </property>
  <property name="filterProcessesUrl">
    <value>/j_acegi_security_check</value>
  </property>
</bean>

<bean id="channelProcessingFilter" class="net.sf.acegisecurity.securechannel.ChannelProcessingFilter">
  <property name="channelDecisionManager">
    <ref bean="channelDecisionManager"/>
  </property>
  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      \A/sec/administrator.*\Z=REQUIRES_SECURE_CHANNEL
      \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
      \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
      \A.*\Z=REQUIRES_INSECURE_CHANNEL
    </value>
  </property>
</bean>

<bean id="channelDecisionManager" class="net.sf.acegisecurity.securechannel.ChannelDecisionManagerImpl">
  <property name="channelProcessors">
    <list>
      <ref bean="secureChannelProcessor"/>
      <ref bean="insecureChannelProcessor"/>
    </list>
  </property>
</bean>
<bean id="secureChannelProcessor" class="net.sf.acegisecurity.securechannel.SecureChannelProcessor"/>
<bean id="insecureChannelProcessor" class="net.sf.acegisecurity.securechannel.InsecureChannelProcessor"/>

<bean name="/shop/newAccount.do" class="org.springframework.samples.jpetstore.web.spring.AccountFormController">
    <property name="petStore"><ref bean="petStore"/></property>
    <property name="validator"><ref bean="accountValidator"/></property>
    <property name="successView"><value>index</value></property>
  </bean>

<bean name="/shop/signon.do" class="org.springframework.samples.jpetstore.web.spring.SignonController">
    <property name="petStore"><ref bean="petStore"/></property>
  </bean>
  <bean name="/shop/signonForm.do" class="org.springframework.web.servlet.mvc.ParameterizableViewController">
    <property name="viewName"><value>SignonForm</value></property>
  </bean>

<bean id="secureHandlerMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="interceptors">
      <list>
        <ref bean="signonInterceptor"/>
      </list>
    </property>
    <property name="urlMap">
      <map>
        <entry key="/shop/editAccount.do"><ref local="secure_editAccount"/></entry>
        <entry key="/shop/listOrders.do"><ref local="secure_listOrders"/></entry>
        <entry key="/shop/newOrder.do"><ref local="secure_newOrder"/></entry>
        <entry key="/shop/viewOrder.do"><ref local="secure_viewOrder"/></entry>
      </map>
    </property>
  </bean>

  原来，上面的signonInterceptor实现了preHandle，因此在请求上面的map页面时，首先要经过这个Interceptor，看看 SignonInterceptor的源码，原来在其中为signon.jsp赋予一个signonForwardAction对象，呵呵，总算明白了。
3). 接下来去学习一下SignonController，其主体部分中可以看出，首先取出用户输入的username和password，然后到数据库中验证 有没有这个用户，如果没有这个用户，返回各错误页面；如果成功，首先生成一个UserSession对象，在request的session加入这个 userSession，注意这部分代码中给出了PagedListHolder分页的简单使用方法，关于分页显示，以后再学习吧。
3、登录成功后，就可以根据不同的用户设施不同的行为了，取得用户信息，无非就是从session取出userSession即可。

链接：http://www.matrix.org.cn/resource/article/1/1730_Acegi.html

序言

    译者：leondu ，作者保留版权，转载请注明出处。

    Acegi Security为基于J2EE的企业应用软件提供全面的安全解决方案。正如你在本手册中看到的那样，我们尝试为您提供有用的，高可配置的安全系统。

    安全是一个永无止境的目标，获取一个全面的，系统级的实现方式是至关重要的。在安全界，我们鼓励你采用"分层安全"，这样每个层都确保自身尽可能的安全，另 外的层提供另外的安全。每个层自身越"紧密"，你的系统就越鲁棒和安全。在底层，你要处理传输入安全和系统认证，减少"中间人攻击"（man-in-the-middle attacks）。接下来你要使用防火墙，结合VPN或者IP安全来确保只有认证过的系统能够尝试连接。在企业环境中，你可能部署DMZ（demilitarized zone，隔离区）来把面向公众的服务器和后端的数据和应用服务器分隔开。在以非授权用户运行进程和文件系统安全最大化上，你的操作系统也将扮演一个关键的角色。接下来你要防止针对系统的拒绝服务和暴力攻击。入侵检测系统在检测和应对攻击方面尤其有用，这些系统可以实时屏蔽恶意TCP/IP地址。在更高层上，你的Java虚拟机需要进行配置，将授予不同Java类型的权限最小化，然后，你的应用程序要对添加针对自身特定问题域的安全配置。Acegi Security使后者－应用程序安全变得容易。

    当然，你要正确对待上述提到的每个安全层，以及包含于每个层的管理因素。这样的管理因素具体包括：安全公告监测，补丁，人工诊断，审计，变更管理，工程管理系统，数据备份，灾难恢复，性能评测，负载监测，集中日志，应急反应程序等等。

    Acegi Security专注于在企业应用安全层为您提供帮助，你将会发现和各式各样的需求和商业问题领域一样多。银行系统的需求和电子商务应用的需求不同。电子商务应用和售卖军用自动工具的公司的需求不同。这些客户化的需求使得应用安全显得有趣，富有挑战性而且物有所值。

    本手册为Acegi Security 1.0.0的发布而大规模重新组织。请先阅读Part I 架构概览。手册的其余部分按照传统的手册方式编排，需要一定的基础才能阅读。

    我们希望您会觉得手册有用，并且欢迎您提供反馈意见和建议。

    最后，欢迎加入Acegi Security社区。

Part I. 架构概览

    象其他的软件一样，Acegi Security也有在整个框架中都会使用的特定核心接口，类，和概念抽象。在手册的这一部分，在检视这些规划和执行Acegi Security集成所必须的核心要素之前，我们先介绍Acegi Security。

第一章. 简介

1.1. Acegi Security是什么?

    Acegi Security为基于J2EE的企业软件应用提供全面的安全服务。特别是使用领先的J2EE解决方案－Srping框架开发的项目。如果您不是使用Spring开发企业应用，我们温馨提醒您仔细研究一下。熟悉Spring，尤其是依赖注射原理，会极大的帮助你快速掌握Acegi Security。

    人们使用Acegi Security有很多种原因，不过通常吸引他们到这个项目的原因是他们在J2EE的 Servlet Specification 或者 EJB Specification中找不到迫切需要的典型企业应用场景。提到这些规范，特别要提出的是他们不是在WAR或者EAR级别可移植的。这样，如果你切换服务器环境，一般来说你要在目标环境中花费很多工夫来重新配置你的应用安全。使用Acegi Security解决了这些问题，并且为你提供了很多其他有用的，完全可定制的安全特性。

    如你所知，安全包含两个主要操作。第一个被称为"认证"，是为用户建立一个它所声明的principal。Principal通常代表用户，设备，或者其他能在你的应用中执行操作的其他系统。"授权"指判定一个principal能否在你的系统中执行某个操作。在到达授权判断之前，principal的的身份认证已经由认证过程执行过了。这些概念是通用的，不是Acegi Security特有的。

    在认证层面，Acegi Security广泛支持各种认证模块。这些认证模块绝大多数是第三方提供，或者相关的标准组织开发的，例如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)

• 你自己的认证系统 (如下所示)

    很多独立软件供应商(ISVs)选择Acegi Security是因为它具有丰富的认证模块。这样无论他们的终端客户需要什么，他们都可以快速集成到他们的系统中，不用花很多工夫或者让终端客户改变环境。如果Acegi Security System for Spring的7个认证模块还没有满足你的需求的话，Acegi Security是一个开放的系统，很容易写你自己的认证机制。许多Acegi Security的企业用户需要和"遗留"系统集成，这些遗留系统不遵循任何安全标准，Acegi Security能够和这样的系统"合作愉快"。

    有时候基本的认证是不够的。有时候你需要根据principal和应用交互的方式来应用不同的安全措施。例如，你可能为了防止密码被窃取，或者防止终端用户受到"中间人"攻击，需要保证到达的是请求通过HTTPS的。或者，你要确保是一个真正的人而不是某种机器人或者自动进程在发送请求。这对于保护密码恢复不受暴力破解攻击，或者防止他人很容易的复制你应用的关键内容。为了帮助你实现这些目标，Acegi Security完全支持自动"通道安全"("channel security")，以及集成Jcaptcha来检测是否是真正人类用户。

    Acegi Security不仅提供了认证功能，而且提供了完备的授权功能。在授权方面主要有三个领域，授权web请求，授权方法调用，授权存取单个领域对象实例。为了帮助你理解这些区别，对照考虑一下Servlet 规范中的web模式安全的授权功能，EJB容器管理安全以及文件系统安全。Acegi Security提供了所有这些重要领域的完备功能，我们将在本手册的后面介绍。

1.2. 历史

    Acegi Security始于2003年晚期，当时在Spring Developers邮件列表中有人提问是否有人考虑提供一个基于Spring的安全实现。当时，Srping的社区是相对比较小的（尤其是和今天相比！），实际上Spring本身也是2003年早期才作为一个SourceForge项目出现的。对此问题的回应是它确实是一个值得研究的领域，虽然限于时间无法进行深入。

    有鉴于此，这个简单的安全实现虽然构建了但是并没有发布。几周以后，Spring社区的其他成员询问了安全框架，代码就被提供给了他们。

随后又有人请求，到了2004年一月，大约有20人左右在使用这些代码。另外一些人加入到这些先行的用户中来，并建议建立一个SourceForge项目，这个项目在2004年3月建立起来。

    在早期，该项目自身并不具备任何认证模块。认证过程依赖容器管理安全（Container Managed Security）而Acegi Security注重授权。在一开始这样是合适的，但是随着越来越多的用户要求额外的容器支持，基于容器的认证的限制就显示出来了。另外一个相关的问题是添加新的JAR文件到容器的classpath，通常会让最终用户感到困惑并且配置错误。

    随后，Acegi Security加入了认证服务。大约一年后，Acegi Security成为了一个Spring Framework官方子项目。在2年半多的在多个软件项目中的活跃使用以及数以百计的改进和社区贡献，1.0.0最终版在2006年5月发布。

   今天，Acegi Security成为一个强大而活跃的社区。在支持论坛上有数以千计的帖子。14个开发人员专职开发，一个活跃的社区也定期共享补丁并支持他们的同侪。

1.3. 发行版本号

    理解Acegi Security的版本号是非常好处的，它可以帮助你判定升级的到新的版本是否需要花费很大精力。我们的正式发行版本使用Apache Portable Runtime Project版本指引，可以在下述网站查看http://apr.apache.org/versioning.html。为了您查看方便，我们引用该页的说明部分如下：

    "版本号由三个部分的整数组成：主版本号（MAJOR）、副版本号（MINOR）、补丁版本号（PATCH）。主要的含义是主版本号（MAJOR）是不兼容的，API大规模升级。副版本号（MINOR）在源文件和可执行版和老版本保持兼容，补丁版本号（PATCH）则意味着向前和向后的完全兼容"。

第二章. 技术概览

2.1. 运行时环境

    Acegi Security可以在JRE1.3中运行。这个发行版本中支持也Java 5.0，尽管对应的Java类型被分开打包到一个后缀是"tiger"的包中。因为Acegi Security致力于以一种自包含的方式运行，因此不需要在JRE中放置任何特殊的配置文件。特别无需配置Java Authentication and Authorization Service (JAAS)策略文件或者将Acegi Security放置到通用的classpath路径中。

    同样的，如果你使用EJB容器或者Servlet容器，同样无需放置任何特别的配置文件或者将Acegi Security包含在服务器的类加载器（classloader）中。

    上述的设计提供了最大的部署灵活性，你可以直接把目标工件（JAR, WAR 或者 EAR)）直接从一个系统copy到另一个系统，它马上就可以运行起来。

2.2. 共享组件

    让我们来看看Acegi Security中最重要的一些共享组件。所谓共享组件是指在框架中处于核心地位，系统脱离了它们之后就不能运行。这些Java类型代表了系统中其他部分的构建单元，因此理解它们是非常重要的，即使你不需要直接和它们打交道。

    最基础的对象是SecurityContextHolder。在这里存储了当前应用的安全上下文（security context），包括正在使用应用程序的principal的详细信息。SecurityContextHolder默认使用ThreadLocal来存储这些详细信息，这意味着即便安全上下文（security context）没有被作为一个参数显式传入，它仍然是可用的。如果在当前principal的请求处理后清理线程,那么用这种方式使用ThreadLocal是非常安全的。当然， Acegi Security自动为你处理这些，所以你无需担心。

    有些应用程序由于使用线程的方式而并不是完全适用ThreadLocal。例如，Swing客户端可能需要一个Java Virtual Machine中的所有线程都使用同样的安全上下文（security context）。在这种情况下你要使用SecurityContextHolder.MODE_GLOBAL模式。另外一些应用程序可能需要安全线程产生的线程拥有同样的安全标识符（security identity）。这可以通过SecurityContextHolder.MODE_INHERITABLETHREADLOCAL来实现。你可以通过两种方法来修改默认的SecurityContextHolder.MODE_THREADLOCAL。第一种是设置一个系统属性。或者，调用SecurityContextHolder的一个静态方法。大部分的应用程序不需要修改默认值，不过如果你需要，那么请查看SecurityContextHolder的JavaDocs获取更多信息。

    我们在SecurityContextHolder中存储当前和应用程序交互的principal的详细信息。Acegi Security使用一个Authentication对象来代表这个信息。尽管你通常不需要自行创建一个Authentication对象，用户还是经常会查询Authentication对象。

你可以在你的应用程序中的任何地方使用下述的代码块：

Object obj =SecurityContextHolder.getContext().getAuthentication().getPrincipal();if (obj instanceof UserDetails) {String username =((UserDetails)obj).getUsername();} else {String username =obj.toString();}

    上述的代码展示了一些有趣的联系和关键的对象。首先，你会注意到在SecurityContextHolder和Authentication之间有一个媒介对象。SecurityContextHolder.getContext() 方法实际上返回一个SecurityContext。Acegi Security使用若干个不同的SecurityContext实现，以备我们需要存储一些和principal无关的特殊信息。一个很好的例子就是我们的Jcaptcha集成，它需要知道一个需求是否是由人发起的。这样的判断和principal是否通过认证完全没有关系，因此我们将它保存在SecurityContext中。

    从上述的代码片段可以看出的另一个问题是你可以从一个Authentication对象中获取一个principal。Principal只是一个对象。通常可以把它cast为一个UserDetails对象。UserDetails在Acegi Security中是一个核心接口，它以一种扩展以及应用相关的方式来展现一个principal。可以把UserDetails看作是你的用户数据库和Acegi Security在SecurityContextHolder所需要的东西之间的一个适配器（adapter）。作为你自己用户数据库的一个展现，你可能经常要把它cast到你应用程序提供的原始对象，这样你就可以调用业务相关的方法(例如 getEmail(), getEmployeeNumber())。

    现在你可能已经开始疑惑，那我什么时候提供UserDetails对象呢？我要如何提供呢？

    我想你告诉过我这个东西是声明式的，我不需要写任何Java代码－那怎么做到呢？对此的简短回答就是有一个叫做UserDetailsService的特殊接口。这个接口只有一个方法，接受一个Sring类型的参数并返回一个UserDetails。Acegi Security提供的大多数认证提供器将部分认证过程委派给UserDetailsService。UserDetailsService用来构建保存在SecurityContextHolder中的Authentication对象。好消息是我们提供若干个UserDetailsService的实现，包括一个使用in-memory map和另一个使用JDBC的。

    大多数用户还是倾向于写自己的实现，这样的实现经常就是简单的构建于已有的Data Access Object (DAO)上，这些DAO展现了他们的雇员、客户、或者其他企业应用程序中的用户。要记得这样做的好处，不论你的UserDetailsService返回什么，它总是可以从SecurityContextHolder中获取，象上面的代码显示的那样。

    除了principal，Authentication提供的另一个重要方法就是getAuthorities（）。这个方法返回一个GrantedAuthority对象数组。GrantedAuthority，毫无疑问，就是授予principal的权限。这些权限通常是"角色"，例如ROLE_ADMINISTRATOR 或者ROLE_HR_SUPERVISOR。这些角色稍后配置到web授权，方法授权和领域对象授权。Acegi Security的其他部分能够处理这些权限，并且期待他们被提供。通常你会从UserDetailsService中返回GrantedAuthority对象。

    通常GrantedAuthority对象都是应用范围的权限。它们都不对应特定的领域对象。因此，你应该不会有一个代表54号员工对象的GrantedAuthority，因为这样会有数以千计的authority，你马上就会用光所有内存（或者，至少会让系统花太长时间来认证一个用户）。当然，Acegi Security会高效的处理这种普遍的需求，但是你不会使用领域对象安全功能来实现这个目的。

    最后，但不是不重要，你有时候需要在HTTP 请求之间存储SecurityContext。另外有些时候你在每次请求的时候都会重新认证principal，不过大部分时候你会存储SecurityContext。HttpSessionContextIntegrationFilter在HTTP之间存储SecurityContext。正如类名字显示的那样，它使用HttpSession来进行存储。基于安全原因，你永远都不要直接和HttpSession交互。没有理由这么做，所以记得使用SecurityContextHolder来代替。

让我们回忆一下，Acegi Security的基本组成构件是：

• SecurityContextHolder,提供对SecurityContext的所有访问方式。

• SecurityContext, 存储Authentication以及可能的请求相关的安全信息。

• HttpSessionContextIntegrationFilter, 在web请求之间把SecurityContext存储在HttpSession中。

• Authentication, 以Acegi Security的方式表现principal。

• GrantedAuthority, 表示赋予一个principal的应用范围的权限。

• UserDetails, 为从你的应用程序DAO中获取必要的信息来构建一个Authentication 对象。

• UserDetailsService,用传入的String类型的username（或者认证ID，或类似）来创建一个UserDetails。

    现在你已经理解了这些重复使用的组件，让我们仔细看看认证过程吧。

2.3. 认证

    正如我们在手册开始部分所说的那样，Acegi Security适用于很多认证环境。虽然我们建议大家使用Acegi Security自身的认证功能而不是和容器管理认证（Container Managed Authentication）集成，但是我们仍然支持这种和你私有的认证系统集成的认证。让我们先从Acegi Security完全自行管理管理web安全的角度来探究一下认证，这也是最复杂和最通用的情形。

    想象一个典型的web应用的认证过程：

1．你访问首页，点击一个链接。

2．一个请求被发送到服务器，服务器判断你是否请求一个被保护的资源。

3．因为你当前未被认证，服务器发回一个回应，表明你必须通过认证。这个回应可能是一个HTTP回应代码，或者重定向到一个特定的网页。

4．基于不同的认证机制，你的浏览器会重定向到一个网页好让你填写表单，或者浏览器会用某种方式获取你的身份认证（例如一个BASIC认证对话框，一个cookie，一个X509证书等等。）。

5．浏览器会发回给服务器一个回应。可能是一个包含了你填写的表单内容的HTTP POST，或者一个包含你认证详细信息的HTTP header。

6．接下来服务器会判断提供的认证信息是否有效。如果它们有效，你进入到下一步。如果它们无效，那么通常请求你的浏览器重试一次（你会回到上两步）。

7．你引发认证的那个请求会被重试。但愿你认证后有足够的权限访问那些被保护的资源。如果你有足够的访问权限，请求就会成功。否则，你将会受到一个意味"禁止"的HTTP403错误代码。

    在Acegi Security中，对应上述的步骤，有对应的类。主要的参与者（按照被使用的顺序）是：ExceptionTranslationFilter， AuthenticationEntryPoint， 认证机制(authentication mechanism)， 以及AuthenticationProvider。

    ExceptionTranslationFilter是Acegi Security用来检测任何抛出的安全异常的过滤器(filter)。这种异常通常是由AbstractSecurityInterceptor抛出的，它是授权服务的主要提供者。我们将会在下一部分讨论AbstractSecurityInterceptor，现在我们只需要知道它产生Java异常，并且对于HTTP或者如何认证一个principal一无所知。反而是ExceptionTranslationFilter提供这样的服务，它负责要么返回403错误代码(如果principal通过了认证，只是缺少足够的权限，象上述第7步那样)，要么加载一个AuthenticationEntryPoint (如果principal还没有被认证，那么我们要从第3步开始)。

    AuthenticationEntryPoint负责上述的第3步。如你所想，每个web应用都有一个默认的认证策略（象Acegi Security中几乎所有的东西一样，它也是可配置的，不过我们现在还是还是从简单开始）。每个主流的认证系统都有它自己的AuthenticationEntryPoint实现，负责执行第3步中描述的动作。

    当浏览器确定要发送你的认证信息（HTTP 表单或者HTTP header），服务器上需要有什么东西来"收集"这些认证信息。现在我们在上述的第6步。在Acegi Security中对从用户代理（通常是浏览器）收集认证信息有一个特定的名字，这个名字是"认证机制（authentication mechanism）"。当认证信息从客户代理收集过来以后，一个"认证请求（Authenticationrequest）"对象被创建，并发送到AuthenticationProvider。

    Acegi Security中认证的最后一环是一个AuthenticationProvider。非常简单，它的职责是取用一个认证请求（Authentication request）对象，并且判断它是否有效。这个provider要么抛出一个异常，要么返回一个组装完毕的Authentication对象。还记得我们的好朋友UserDetails 和 UserDetailsService吧？如果没有，回到前一部分重新回忆一下。大部分的AuthenticationProviders都会要求UserDetailsService提供一个UserDetails对象。如前所述，大部分的应用程序会提供自己的UserDetailsService，尽管有些会使用Acegi Security提供的JDBC或者 in-memory实现。作为成品的UserDetails 对象，特别是其中的GrantedAuthority[]s，在构建完备的Authentication对象时会被使用。

    当认证机制（authentication mechanism）取回组装完全的Authentication对象后，它将会相信请求是有效的，将Authentication放到SecurityContextHolder中，并且将原始请求取回（上述第7步）。反之，AuthenticationProvider则拒绝请求，认证机制（authentication mechanism）会请求用户重试（上述第2步）。

    在讲述典型的认证流程的同时，有个好消息是Acegi Security不关心你是如何把Authentication放到SecurityContextHolder内的。唯一关键的是在AbstractSecurityInterceptor授权一个请求之前，在SecurityContextHolder中包含一个代表了principal的Authentication。

    你可以（很多用户确实）实现自己的过滤器（filter）或者MVC控制器（controller）来提供和不是基于Acegi Security的认证系统交互。例如，你可能使用使用容器管理认证（Container Managed Authentication），从ThreadLocal或者JNDI中获取当前用户信息，使得它有效。或者，你工作的公司有一个遗留的私有认证系统，而它是公司"标准"，你对它无能为力。在这种情况之下也是非常容易让Acegi Security运作起来，提供认证能力。你所需要做的是写一个过滤器（或等价物）从某处读取第三方用户信息，构建一个Acegi Security式的Authentication对象，把它放到SecurityContextHolder中。这非常容易做，也是一种广泛支持的集成方式。

2.4. 安全对象

    如果你熟悉AOP，你会知道有很多种advice可用：before, after, throws 和 around。around advice非常有用，因为它能够选择是否选择是否执行一个方法调用，是否修改返回值，以及是否抛出异常。Acegi Security对方法调用和web请求都提供around advice。我们使用AOP联盟实现对方法调用的around advice，对于web请求的around advice则是使用标准的过滤器（Filter）。

  对于那些不熟悉AOP的人来说，关键是要理解Acegi Security能够帮助你保护方法调用以及web请求。大多数人对保护他们服务层的方法调用感兴趣。这是因为在当前的J2EE应用中，服务层包含了大多数的业务逻辑（声明，作者不赞成这种设计，反而支持正确封装的领域模型以及DTO，assembly, facade 以及 transparent persistence patterns，而不是当前主流的贫血模型，我们将在这里讨论）。如果你需要保护service层的方法调用，使用标准的Spring AOP平台（或者被成为AOP 联盟（AOP Alliance））就足够了。如果你需要直接对领域模型进行保护，那么可以考虑使用AspectJ。

    你可以选择对使用AspectJ 或者AOP联盟（AOP Alliance）对方法进行授权，或者你可以选择使用过滤器（filter）来对web请求进行授权。你将0个，1个，2个或者3个这些方法一起使用。主流的用法是执行一些web请求授权，以及在服务层使用AOP联盟（AOP Alliance）对一些方法调用授权。

    Acegi Security使用"安全对象"（secure object）这个词来指任何能够将安全应用于其上的对象。每个Acegi Security支持的安全对象都有自己的类，它是AbstractSecurityInterceptor的子类。重要的一点是，如果一个principal通过认证，当AbstractSecurityInterceptor执行的时候，SecurityContextHolder中要包含一个有效的Authentication。

    AbstractSecurityInterceptor提供一个固定的工作流程来处理安全对象请求。这个工作流程包括查找和当前请求相关联的"配置属性（configuration attributes）"。配置属性（configuration attributes）可以被认为是对被AbstractSecurityInterceptor使用的类有特殊含义的字符串。他们通常针对AbstractSecurityInterceptor使用XML进行配置。反正，AbstractSecurityInterceptor会询问AccessDecisionManager "这是配置属性（configuration attributes），这是当前的认证对象（Authentication object），这是当前请求的详细信息－那么这个特定的principal可以执行这个特定的操作吗？"。

    假如AccessDecisionManager判定允许这个请求，那么AbstractSecurityInterceptor一般来说就继续执行请求。虽然这样，用户在少数情况之下可能需要替换SecurityContext中的Authentication，可以通过AccessDecisionManager调用一个RunAsManager来实现。在某些不常见的情形下这将非常有用，例如服务层的方法需要用另一种标识（身份）来调用远程系统。这可能有所帮助，因为Acegi Security自动在不同的服务器之间传播安全标识（假设你正确配置了RMI或者HttpInvoker remoting protocol client）。

    随着安全对象处理和返回－意味着方法调用完毕或者过滤器链（filter chain）处理完毕－AbstractSecurityInterceptor有最后的机会来处理调用。这时，AbstractSecurityInterceptor可能会修改返回的对象。我们可能要这样做，因为授权判断不能在安全对象调用途中执行。由于高度的可插拔性，如果需要AfterInvocationManager将控制权交给AfterInvocationManager来实际修改对象。这个类甚至可以彻底替换对象，或者抛出异常，或者根本不修改它。

    因为是AbstractSecurityInterceptor中心模版类，看起来第一副插图该献给它。（译注：原手册里的图画的太丑陋了，我用jude重新画了一遍）

图1 关键"安全对象"模型

    只有那些希望实现全新的对请求进行截取截取和授权方式的开发者才需要直接使用安全对象。例如，可能构建一个新的安全对象安全调用一个消息系统。任何需要安全并且能够提供一种截取调用的方式(例如AOP around advice semantics)的东西都可以成为安全对象。虽然如此，大部分的Spring应用都会只是透明应用当前支持的三种安全对象类型（AOP Alliance MethodInvocation, AspectJ JoinPoint 和 web request FilterInterceptor）。

2.5. 结论

    恭喜！你已经获取了Acegi Security足够的概括性的图景来开始着手你的项目。我们探究了共享组件，认证过程，以及对"安全对象"的通用授权概念。手册中的余下部分你可能用到也可能用不到，可以按照任意顺序阅读。

第三章. 协助系统

本章介绍一些Acegi Security使用的附加和协助系统。那些和安全无关，但是包含在Acegi Security项目中的部分，将会在本章中讨论

3.1. 本地化

Acegi Security支持对终端客户可能会看到的异常信息进行本地化。如果你的应用是为英文用户设计的，那么你什么都不用做，因为Acegi Security的所有消息默认都是英文的。如果你要支持其他区域用户，那么本节包含了你所需要了解的所有东西。

包括认证失败或者访问被拒绝（授权失败）的所有异常消息都可以被本地化。提供给开发者或者系统部署人员的异常或者日志信息(包括错误的属性、接口不符、构造器错误、debug级日志)没有被本地化，它们硬编码在Acegi Security的代码中。

在acegi-security-xx.jar（译注：xx代表版本号）的org.acegisecurity包中包含了一个messages.properties文件。这个文件会被你的application context引用，因为Acegi Security实现了Spring的MessageSourceAware接口，它期待在application context启动的时候注入一个message resolver。通常你所需要做的是在你的application context中注册一个引用这个消息的bean，如下所示：

<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource"><property name="basename"><value>org/acegisecurity/messages</value></property></bean>

messages.properties是按照资源包标准命名的，它代表了Acegi Securtiy支持的默认语言。文件默认是英文的。如果你不注册一个消息源，Acegi Security仍然可以正常工作，它会用回硬编码的英文消息。

如果你想定制messages.properties文件，或者支持其他语言，那么你应该copy这个文件，然后重命名，并在上述的bean定义中注册。因为文件中的key并不多，因此本地化花不了多少工夫。如果你针对消息文件进行了本地化，那么请和社区分享，你可以添加一个JIRA任务，将你正确命名的messages.properties本地化文件作为附件添加。

为了完善关于本地化的讨论需要知道Spring的ThreadLocal org.springframework.context.i18n.LocaleContextHolder。你应该为每个用户设置代表他区域的LocaleContextHolder。Acegi Security会尝试从这个ThreadLocal中获取的Locale来从消息源中获取消息。请参考Spring的文档以获取更多使用LocaleContextHolder和能够帮你自动设置它的辅助类(例如

AcceptHeaderLocaleResolver, CookieLocaleResolver, FixedLocaleResolver, SessionLocaleResolver 等)的详细信息。

3.2. Filters

正如你在整个手册中看到的那样，Acegi Security使用很多filter。你可以使用FilterToBeanProxy或者FilterChainProxy来确定这些是怎样加入到你的web应用中的，下面我们来看看。

大部分filter使用FilterToBeanProxy来配置。例如下面web.xml中配置所示：

<filter>    <filter-name>Acegi HTTP Request Security Filter</filter-name>    <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>    <init-param>        <param-name>targetClass</param-name>        <param-value>org.acegisecurity.ClassThatImplementsFilter</param-value>    </init-param></filter>

注意在web.xml中的filter实际上是一个FilterToBeanProxy，而不是真正实现filter逻辑的filter。FilterToBeanProxy所作的是代理Filter的方法到一个从Spring的application context 获取的bean。这使得这个bean可以享受Spring application context的生命周期支持以及配置灵活性。这个bean必须实现javax.servlet.Filter。

FilterToBeanProxy只需要一个简单的初始化参数，targetClass或者targetBean。targetClass会定位application context中指定的类的第一个对象，而FilterToBeanProxy按照bean的名字定位对象。象标准的Spring web应用一样，FilterToBeanProxy使用WebApplicationContextUtils.getWebApplicationContext(ServletContext)来访问application context，所以你应该在web.xml中配置一个ContextLoaderListener。

在IoC容器而不是servlet容器中部署Filter会有一个生命周期的问题。特别是，哪个容器应该负责调用Filter的"startup" 和 "shutdown"方法？注意到Filter的初始化和析构顺序随servlet容器不同而不同，如果一个Filter依赖于由另一个更早初始化的Filter的配置，这样就会出现问题。另一方面，Spring IoC具备更加完善的生命周期/IoC接口（例如InitializingBean, DisposableBean, BeanNameAware, ApplicationContextAware以及其他许多）以及一个容易理解的接口契约（interface contract），可预见的方法调用顺序，自动装配支持，以及可以避免实现Spring接口的选项（例如Spring XML中的destroy-method 属性）。因此，我们推荐尽可能使用Spring生命周期服务而不是servlet容器生命周期服务。FilterToBeanProxy默认不会将init(FilterConfig) 和 destroy()方法委派到被代理的bean。如果你需要这些调用被委派，那么将lifecycle初始化参数设置为servlet-container-managed。

我们强烈推荐你使用FilterChainProxy而不是FilterToBeanProxy。虽然FilterToBeanProxy是一个非常有用的类FilterToBeanProxy，问题是当web.xml中filter变多时，<filter> 和 <filter-mapping>项就会太多而变得臃肿不堪。为了解决这个问题，Acegi Security提供一个FilterChainProxy类。它在FilterToBeanProxy中被装配（正如上面例子中所示），但目标类（target class）是org.acegisecurity.util.FilterChainProxy。这样过滤器链（filter chain）可以在application context中按照如下代码配置：

<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">    <property name="filterInvocationDefinitionSource">        <value>            CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON            PATTERN_TYPE_APACHE_ANT            /webServices/*=httpSessionContextIntegrationFilterWithASCFalse,basicProcessingFilter,exceptionTranslationFilter,            /*=httpSessionContextIntegrationFilterWithASCTrue,authenticationProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor        </value>    </property></bean>

你可能注意到FilterSecurityInterceptor定义方式的相似之处。同时支持正则表达式和Ant Paths格式，越对应的URI越早出现。在运行时，FilterChainProxy会定位符合当前的web请求的第一个URI模式。每个对应的配置属性代表了在application context中定义的一个bean的名字。接着fiter会按照它们被指定的顺序，按照FilterChain的标准行为模式被调用(如果一个Filter决定停止处理，它可以不在chain中执行)。

如你所见，FilterChainProxy需要为不同的请求模式重复配置filter的名字（在上面的例子中，, exceptionTranslationFilter 和 filterSecurityInterceptor 是重复的）。这样的设计是为了让FilterChainProxy能够为不同的URI配置不同的filter调用顺序，同时也提高了表达力（针对正则表达式、Ant Paths、以及任何FilterInvocationDefinitionSource的特定实现）和清晰度，可以知道是哪个filter应该被调用。

你可能注意到了我们在filter chain定义了两个HttpSessionContextIntegrationFilter (ASC是allowSessionCreation的缩写,是HttpSessionContextIntegrationFilter的一个属性)。因为web服务不会为将来的请求提供一个jsessionid，为这样的用户创建HttpSessions是浪费的。如果你有一个需要最大限度的伸缩性的高容量的应用，我们建议你使用上述的方法。对于小的应用，使用单一的HttpSessionContextIntegrationFilter (默认的allowSessionCreation设为true)应该足够了。

说到生命周期问题，如果对FilterChainProxy自身调用init(FilterConfig) 和 destroy()方法，它会把它代理到底层的filter。这样FilterChainProxy保证只初始化和析构每个filter一次，不论它在FilterInvocationDefinitionSource中定义了多少次。你可以通过FilterToBeanProxy的lifecycle初始化参数来控制这些方法是否被调用。如上面所讨论的那样，默认所有servlet容器生命周期调用是不被代理到FilterChainProxy的。

在web.xml中定义的filter的顺序是非常重要的。不管你实际用到哪个filter，<filter-mapping>的顺序应该是如下所示的：

1．ChannelProcessingFilter，因为可能要重定向到另一种协议。

2．ConcurrentSessionFilter 因为不使用任何SecurityContextHolder的功能，但是需要更新SessionRegistry来表示当前的发送请求的principal。

3． HttpSessionContextIntegrationFilter, 这样当一个web请求开始的时候就可以在SecurityContextHolder中设置一个SecurityContext，当web请求结束的时候任何对SecurityContext的改动都会被copy到HttpSession（以备下一个web请求使用）。

4．Authentication processing mechanisms - AuthenticationProcessingFilter, CasProcessingFilter, BasicProcessingFilter, HttpRequestIntegrationFilter, JbossIntegrationFilter 等 - 修改SecurityContextHolder，使其中包含一个有效的认证请求令牌（token）。

5．SecurityContextHolderAwareRequestFilter, 如果你使用它来在你的servlet容器中安装一个Acegi Security aware HttpServletRequestWrapper。

6．RememberMeProcessingFilter, 如果早期的认证处理过程没有更新SecurityContextHolder，并且请求（request）提供了一个cookie启用remember-me服务，一个合适的被记住的Authentication对象会被放到SecurityContextHolder那里。

7．AnonymousProcessingFilter, 如果早期的认证处理过程没有更新SecurityContextHolder，, 一个匿名Authentication 对象会被放到SecurityContextHolder那里。

8．ExceptionTranslationFilter, 捕获所有的Acegi Security 异常，这样要么返回一个HTTP错误响应或者加载一个对应的AuthenticationEntryPoint。

9．FilterSecurityInterceptor, 保护 web URIs

所有上述的filter使用FilterToBeanProxy或FilterChainProxy。建议在一个应用中使用一个单个的FilterToBeanProxy代理到一个单个的FilterChainProxy。，在FilterChainProxy中定义所有的Acegi Security Filters。如果你使用SiteMesh，确保Acegi Security filters 在 SiteMesh filters调用前调用。这样使SecurityContextHolder在SiteMesh decorator使用前能够及时被装配。

第四章. 信道安全

4.1. 概述

Acegi Security不仅能满足你的认证和授权的请求，而且能够保证你的未认证的web请求也能拥有某些属性。这些属性可能包括使用特定的传输类型，在HttpSession设置特定的属性等等。Web请求的最普遍的需求是使用特定的传输协议，例如HTTPS。

在传输安全中的一个重要议题就是会话劫持（session hijacking）。Web容器通过一个jsessionid来引用一个HttpSession，这个jsessionid通过cookie 或者URL重写转向（URL rewriting）发送到到客户端。如果jsessionid是通过HTTP发送的，那么就存在被劫持以及在认证过程之后冒充被认证用户的可能。这是因为大部分的web容器为特定的用户维护同一个会话标识符，即便是用户从HTTP 切换到 HTTPS页面。

如果对于你的特定应用来说，会话劫持（session hijacking）是一个很严重的风险，那么唯一的解决方法就是对每一个请求都使用HTTPS。这意味着jsessionid不会使用非安全信道传输。你要保证你的web.xml中定义<welcome-file>，把它指向一个HTTPS位置，同时应用程序不把用户指向一个HTTP位置。Acegi Security提供一个解决方案帮助你实现后者。

4.2. 配置

启用Acegi Security的信道安全服务，需要在web.xml中增加如下行：

<filter><filter-name>Acegi Channel Processing Filter</filter-name><filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class><init-param><param-name>targetClass</param-name><param-value>org.acegisecurity.securechannel.ChannelProcessingFilter</param-value></init-param></filter><filter-mapping><filter-name>Acegi Channel Processing Filter</filter-name><url-pattern>/*</url-pattern></filter-mapping>

和平时一样，你同样需要在application context中配置filter

<bean id="channelProcessingFilter" class="org.acegisecurity.securechannel.ChannelProcessingFilter"><property name="channelDecisionManager"><ref bean="channelDecisionManager"/></property><property name="filterInvocationDefinitionSource"><value>CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON\A/secure/.*\Z=REQUIRES_SECURE_CHANNEL\A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL\A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL\A.*\Z=REQUIRES_INSECURE_CHANNEL</value></property></bean><bean id="channelDecisionManager" class="org.acegisecurity.securechannel.ChannelDecisionManagerImpl"><property name="channelProcessors"><list><ref bean="secureChannelProcessor"/><ref bean="insecureChannelProcessor"/></list></property></bean><bean id="secureChannelProcessor" class="org.acegisecurity.securechannel.SecureChannelProcessor"/><bean id="insecureChannelProcessor" class="org.acegisecurity.securechannel.InsecureChannelProcessor"/>

ChannelProcessingFilter和FilterSecurityInterceptor一样支持Apache Ant style paths。

ChannelProcessingFilter的工作方式是过滤所有的web请求，并将判断将适合的配置属性应用于其上。然后它代理到ChannelDecisionManager。默认的实现类ChannelDecisionManagerImpl应该能够满足大多数需求。它就代理到配置好的ChannelProcessor实例列表。ChannelProcessor会检视请求，如果它不满意请求（例如请求是发送自不正确的传输协议）它将会重定向，抛出异常或者采取其他任何恰当的措施。

Acegi Security 包括ChannelProcessor两个实体类实现：SecureChannelProcessor 保证配置了REQUIRES_SECURE_CHANNEL 属性的请求都是从HTTPS发送过来的。而InsecureChannelProcessor 保证配置了REQUIRES_INSECURE_CHANNEL 属性的请求都是从HTTP发送过来的。如果没有使用请求的协议，这两个实现都会转到ChannelEntryPoint，而两个ChannelEntryPoint 实现所作的就是简单的把请求相应按照HTTP 和 HTTPS重定向。

要注意重定向是绝对（例如http://www.company.com:8080/app/page）而不是相对的(例如 /app/page)。在测试中发现Internet Explorer 6 Service Pack 1 有一个bug，因此如果在重定向的时候也改变使用的端口，它就不能正确响应。对应这个bug，在很多Acegi Security bean中都会使用的PortResolverImpl也使用绝对URL。请参阅PortResolverImpl的JavaDoc以获取更多信息。

你要注意使用为了在登录过程中保证用户名和密码的安全，要使用安全信道。如果你配合基于表单的登录使用ChannelProcessingFilter，请记得一定要把你的登录页面设置为REQUIRES_SECURE_CHANNEL，并且AuthenticationProcessingFilterEntryPoint.forceHttps属性设置为true。

4.3. 结论

一旦配置好了，使用安全信道是非常简单的。只要请求页面，不用管使用什么协议（HTTP 或 HTTPS）或什么端口（80, 8080, 443, 8443等）。显然你只要确定初始请求(获取通过在web.xml 中的<welcome-file> 或一个众所周知的主页URL)，完成以后filter会执行你application context定义的重定向。

你也可以在ChannelDecisionManagerImpl中增加自己的ChannelProcessor实现。例如，你可能通过"输入图片中的内容"检测到一个个人类用户，然后在HttpSession中设置一个属性。

要判断一个安全检查应该是或者ChannelProcessor或是 AccessDecisionVoter 记得前者是设计用来处理认证或者未认证的请求，而后者是设计用来处理已认证的请求。因此后者可以访问已认证的principal被授予的权限。

另外，ChannelProcessor检测到问题后一般是引发一个HTTP/HTTPS重定向这样他的请求可以被满足，而AccessDecisionVoter将则会跑出一个AccessDeniedException异常(取决于支配的 AccessDecisionManager)。

文章来源:http://wiki.springside.org.cn/display/springside/Acegi+Reference+Preface 

前面的一篇文章我曾经介绍了使用Tomcat简单部署CAS的方法，但对于用户名和密码只是做相同性的校验匹配验证，下面我将一步步将其改变为使用Sun Directory Server进行用户认证的方式。

1. 下载esup-casgeneric-2.0.5-2，将其部署到CAS源代码中。方法很简单，修改其properties文件，指定CAS源代码的存储位置，在我机器中我将其指向了eclipse的workspace工作目录中的CAS应用。随后使用ant编译其build.xml脚本，实际上运行该教本只是做了一个复制拷贝工作，将ESUP的源代码文件和配置文件复制到CAS源码中。
2. 修改原有CAS的认证方式，在web.xml中，将CAS的认证控制器由默认的edu.yale.its.tp.cas.auth.provider.SampleHandler改为ESUP的GenericHandler，修改后的内容如下：
   <context-param>
           <param-name>edu.yale.its.tp.cas.authHandler</param-name>
           <param-value>org.esupportail.cas.server.GenericHandler</param-value>
   </context-param>
3. 修改ESUP的配置文件genericHandler.xml，将其默认的控密码和相同性验证方式改为LDAP验证方式，并同时配置LDAP相关信息，下面是修改前与修改后的内容：
   修改前：
   <authentication empty_password_accepted="on" debug="on">
       <handler>
           <classname>
               org.esupportail.cas.server.handlers.test.EmptyPasswordHandler</classname>
       </handler>
       <handler>
           <classname>
               org.esupportail.cas.server.handlers.test.PasswordEqualsUsernameHandler</classname>
       </handler>
   </authentication>
   修改后：
   <authentication debug="off">
       <handler>
           <classname>
               org.esupportail.cas.server.handlers.ldap.BindLdapHandler</classname>
           <config>
               <search_base>ou=People,dc=sjtu,dc=edu,dc=cn</search_base>
               <filter>uid=%u</filter>
               <scope>sub</scope>
               <bind_dn>cn=Directory Manager</bind_dn>
               <bind_password>password</bind_password>
               <server>
                   <url>ldap://yuanxz.sjtu.edu.cn:389/</url>
               </server>
               <disable_multiple_accounts/>
           </config>
       </handler>
   </authentication>
4. 修改ESUP日志记录配置文件LoggerConf.xml，修改名为File的参数，将其value指向希望的日志存储位置：<param name="File" value="c:/tomcat/logs/esup-casgeneric.log" />
5. 重新部署CAS应用到Tomcat，即再次运行build.xml的ant教本，重新启动Tomcat，进入Servlet-Examples的应用实例，点击执行后浏览器仍自动跳转到CAS的认证登录界面，在用户名和密码栏中输入位于LDAP中用户信息，即可通过验证。
6. 验证日志文件，打开步骤4中配置的日志文件，可以看到CAS成功地连接了LDAP数据库并通过了验证，日志示例如下：
   INFO [http-8443-Processor24] root.[] 三月/11 14:04:14 - ESUP-Portail Generic Handler 2.0.5-2, reading configuration file...
   INFO [http-8443-Processor24] root.[] 三月/11 14:04:15 - Configuration file read without any error.
   INFO [http-8443-Processor24] root.[] 三月/11 14:04:20 - Authentication succeeded for user `yuanxz'.

LDAP authentication with CAS GH

As LDAP became a standard for user referencials, authentication on an LDAP directory is the most widely used method nowadays. LDAP authentication configuration consists in specifying:

• the mode used to access LDAP servers (see bellow);
• an LDAP server or a list of LDAP servers (for redundancy);

Two access modes are provided (bind and fastbind), depending on the internal structure of the LDAP directory.

Direct access mode (fastbind)

The fastbind method can be used with LDAP directories of which the users' Distinguished Names can be directly deduced from their login name (practically, LDAP directories where all the users are stored at the same hierarchical level).

In this mode, CAS tries to connect to the LDAP directory with the user's DN and the password provided.

One may use:

<authentication debug="off">
  <handler>
    <classname>org.esupportail.cas.server.handlers.ldap.FastBindLdapHandler</classname>
    <config>
      <filter>uid=%u,ou=people,dc=esup-portail,dc=org</filter>
      <server>
        <url>ldap://ldap.esup-portail.org</url>
      </server>
      <server>
        <url>ldap://replica.esup-portail.org</url>
      </server>
</config>
  </handler>
</authentication>

When using the ldap_fastbind method, the administrator should only spécify the filter to find the users' DN in the directory. The following tokens (similar to ldap_saslauthd) can be used in the filter string:

• %% = %
• %u = user
• %U = user portion of %u (%U = test when %u = test@domain.tld)
• %d = domain portion of %u (%d = domain.tld when %u = test@domain.tld)
• %1-9 = domain tokens (%1 = tld, %2 = domain when %d = domain.tld)
• %s = service
• %r = realm

The %u token has to be used at minimum for the filter to be useful. Defaults to uid=%u.

Search mode (bind)

When users are located in different branches of the directory, deducing the users' DN from their login name is impossible. In this case, the ldap_bind mode should be used. It performs a search in the directory before trying to connect.

One may use:

<authentication debug="off">
  <handler>
    <classname>org.esupportail.cas.server.handlers.ldap.BindLdapHandler</classname>
    <config>
      <search_base>ou=people,dc=esup-portail,dc=org</search_base>
      <filter>uid=%u</filter>
      <scope>sub</scope>
      <bind_dn>admin</bind_dn>
      <bind_password>secret</bind_password>
      <server>
        <url>ldap://ldap.esup-portail.org</url>
      </server>
      <server>
        <url>ldap://replica.esup-portail.org</url>
      </server>
      <disable_multiple_accounts/>
    </config>
  </handler>
</authentication>

When using the bind method, the administrator should specify:

• the start point of the search (e.g. dc=univ-rennes1,dc=fr). Tokens described in the filter attribute (see above) can be used for substitution;
• the search scope (can be sub, one or base). Defaults to sub;
• the filter to find the users' DN in the directory;
• parameters to connect to the LDAP directory (when ommited, an anonymous connection is used);
• whether multiple accounts for users are allowed or not, thanks to the <enable_multiple_accounts> and <disable_multiple_accounts> tags (by default, they are not allowed). If the result of the LDAP search has more then one result, no connection to the LDAP directory is done and the authentication is refused. This feature was added in version 2.0.5.

LDAP servers

The LDAP servers are defined by:

• their LDAP URL.

When specifying several servers, all the servers are considered as replicates: when authentication fails on one directory, LDAP authentication fails because directories are intended to contain the same data; next (redundant) servers are tried only if the first one does not respond.

Specifying many replicas can be done by specifying a space-separated list of LDAP URLs in the <url> element (these URLs will be handled by JNDI (since JDK 1.4) as precised in http://java.sun.com/products/jndi/tutorial/ldap/misc/url.html. Alternatively, using several <server> elements can help debugging.

弄了一下午的cas安装终于成功了，，现在将步骤叙述一下
下载         
cas-server-3.0.4.zip               http://www.ja-sig.org/downloads/cas/cas-server-3.0.4.zip

cas-client-2.0.11.zip  http://www.ja-sig.org/downloads/cas-clients/cas-client-2.0.11.zip

环境为 winxp  tomcat5.5.17  jdk1.5.0_05
1. 生成服务端证书
keytool -genkey -alias casserver -keyalg RSA -keystore tomcat.jks
CN：localhost
其他的随便  
这里要注意姓名必须是服务器的域名 由于我是在本机所以是localhost
如果不这样写就会报如下异常：
java.io.IOException: HTTPS hostname wrong:  should be <localhost>

这个异常出现在创建证书的第一个问题 姓名。其实这个“姓名”应该是域名。比如说localhost或是blogjava.net之类的。输成了姓名，和真正运行的时候域名不符，就会出错。浏览器无所谓，弹出一个对话框，用户按一下就行了。但http client就直接抛出了异常。--google出来的

2. 导出证书
keytool -export -file cas.cer -alias tomcat -keystore tomcat.jks

3.把导出的证书导入到jre/lib/security的cacerts中
这里又有一点要注意的   可能由于我的jre在线升级过一次 现在的工作的jre目录在C:\Program Files\Java\jre1.5.0_06\ 所以要把证书导入到C:\Program Files\Java\jre1.5.0_06\lib\security的cacerts中去
我一开始就是因为 导入到了%JAVA_HOME%的jre中 结果弄了半天都不成功报异常如下：
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

4.配置tomcat使用ssl
<Connector port="8443" maxHttpHeaderSize="8192"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" disableUploadTimeout="true"
               acceptCount="100" scheme="https" secure="true"
               clientAuth="false"//单向SSL
               keystoreFile="C:\tomcat.jks" //我生成的keystore存放在c盘
               sslProtocol="TLS" />

5. 部署CAS应用
  解压 cas-server-3.0.4.zip, 提取 \target\cas.war 文件，将 cas.war 文件复制到 TOMCAT 的安装路径 webapps 下，启动 TOMCAT ，检查 CAS 应用是否正常启动。

6.客户端配置
下载cas-client-2.0.11.zip
把 java/lib/casclient.jar考到 你所发布的webapp的WEB-INF/lib下
修改WEB-INF/web.xml 在里面添加过滤器
    <filter>
        <filter-name>CASFilter</filter-name>
        <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
        <init-param>
           <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
           <param-value>https://localhost:8443/cas/login</param-value>
        </init-param>
        <init-param>
           <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
           <param-value>https://localhost:8443/cas/proxyValidate</param-value>
        </init-param>
        <init-param>
          <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
          <param-value>localhost:8443</param-value>
        </init-param>
    </filter>
   
    <filter-mapping>
        <filter-name>CASFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

把里面的localhost换成域名
8443换成你所使用的端口

接着连接 https://localhost:8443/app1    //app1是你要实现sso的web应用
接着页面就会跳转到cas的登陆页面 就像你在第5步看到的页面一样
随便用一个用户名登陆 只要 用户名和密码一样就可以登陆
可以在app2上重复步骤6 这样只要在app1上登陆后 再连接app2的url就不用再次登陆了
这就是单点登陆了。

 其实是一个很简单的事情 但是过程中要注意 步骤1和3

在liferay portal中集成CAS非常容易
1拷贝cas java client 的jar包到liferay\WEB-INF\lib下
2修改common\lib\ext\portal-ejb.jar\里的文件system.properties
     将poratl.properties里
auto.login.hooks=com.liferay.portal.auth.BasicAutoLogin,com.liferay.portal.auth.CASAutoLogin
3 修改liferay\WEB-INF里的web.xml文件增加
参数要根据实际情况修改
<filter>
     <filter-name>CASFilter</filter-name>
     <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
      <init-param>
     <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
<param-value>https://192.168.210.79:7443/CASServer/login</param-value>
     </init-param>
     <init-param>
   <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://192.168.210.79:7443/CASServer/serviceValidate</param-value>
     </init-param>
    <init-param>
  <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
    <param-value>localhost</param-value>
    </init-param>
   </filter>
    <filter-mapping>
    <filter-name>CASFilter</filter-name>
      <url-pattern>/*</url-pattern>
   </filter-mapping>

   CAS安装- -
                                      

看了网上很多CAS安装的步骤,结合自己的经验总结如下:

一、配置Tomcat，启用SSL协议。

1.在CAS要安装的机器上（也就是服务端）为Tomcat生成用于SSL通讯的密钥：keytool -genkey -alias tomcat -keyalg RSA，输入密钥密码和相应参数，（注意：第一个参数CN一定要输入CAS安装机器名，其他参数就随便了），结果是在用户目录中创建了名为.keystore的密钥文件。

2.从服务端导出密钥文件：keytool -export -file server.crt -alias tomcat，输入上一步中的密码，结果在当前目录生成server.crt密钥文件。（注意：这个文件是要导入客户端的JVM上的）

3.为客户端的JVM导入密钥：keytool -import -keystore $JAVA_HOME/jre/lib/security/cacerts -file server.crt -alias tomcat，输入密码（注意：这里的密码不是上面设定的密码，而是changeit），将创建cacerts文件。

4.修改服务端的Tomcat配置文件server.xml，去掉对于SSL的注释，即开放8443端口，注意这里需要在connector字段中加入keystorePass="password"参数，password即为上面几步中涉及到的密码，keystoreFile＝".keystorePath",.keystorePath即为在第一步中生成的文件.keystore的全路径，如/usr/java/bin/.keystore。

5.启动Tomcat，测试https://server:8443/是否是需经过验证方可访问（注意：server为服务端的IP地址或机器名）。

二、部署CAS Server 2.0.12到Tomcat

1.一种简单的方法是将下载包中的cas.war文件直接复制到Tomcat的webapps目录下。

2.另外一种方法，从sourceforge上找到ESUP-Portail CAS Generic Handler项目，利用esup-cas-quick-start生成一个最简的TOMCAT，详见我的下一篇文章。

3.启动Tomcat，测试https://server:8443/cas，是否可访问CAS主页面（注意：server为服务端的IP地址或机器名）。

三、部署CAS Client 2.0.11到Servlet-Examples

1.利用Servlet-Examples实例进行测试，将下载包中的casclient.jar文件复制到Servlet-Examples中WEB-INF目录的lib下，这里需要手工建立lib目录。

2.修改Servlet-Examples的配置文件web.xml，加入以下的过滤器：

<!-- CAS Filters -->
    <filter>
        <filter-name>CASFilter</filter-name>
        <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
        <init-param>
            <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
            <param-value>https://server:8443/cas/login</param-value>
        </init-param><!--这里的server是服务端的IP-->
        <init-param>
            <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
            <param-value>https://serName:8443/cas/proxyValidate</param-value>
        </init-param><!--这里的serName是服务端的主机名，而且必须是-->
        <init-param>
          <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
          <param-value>client:port</param-value><!--client:port就是需要CAS需要拦截的地址和端口，一般就是这个TOMCAT所启动的IP和port-->
        </init-param>
    </filter>
   
    <filter-mapping>
        <filter-name>CASFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

四、测试

1.启动Tomcat，定位到Servlet-Examples应用，点击Execute；

2.浏览器跳转至CAS登录首页，注意在URL中已经附上了Servlet-Examples的Service名

3.输入用户名和密码，这里没有对其验证条件做修改，因此只要用户名和密码相同即可通过验证。

4.验证通过后浏览器又重新定位至Servlet-Examples并显示该Servlet的内容。

5.点击Http Header的Servlet应用，可以看到里面对当前用户的用户名信息做了记录。

6.以后访问Servlet-Examples应用都无需再次输入用户名和密码了。

至此，CAS Server和Client已经在Tomcat上成功部署与配置，并达到了预期的SSO效果。

Introduction
The following are a set of instructions for integrating Liferay Portal with CAS Server to setup single sign on (SSO) between Liferay and an existing web application.

[edit]Setting up CAS server
We will begin with setting up JA-SIG CAS server on Tomcat 5.x.x.

Download cas-server WAR from Liferay's download page or the whole distribution from here and drop the cas-web.war file into Tomcat's webapps dir. In a production environment The CAS server should really run on its own tomcat instance but for testing purposes we'll drop it in the same instance as our Liferay portal.

We'll need to edit the server.xml file in tomcat and uncomment the SSL section to open up port 8443.

xml 代码

[edit]Setting up the CAS client
Next we need to download the Yale CAS client from here. Get cas-client-2.0.11. Place the casclient.jar in ROOT/web-inf/lib of the Liferay install.

[edit]Generate the SSL cert with Java keytool
Now that we have everything we need, it's time to generate an SSL cert for our CAS server. Instructions and more information on SSL certs can be found here(http://www.ja-sig.org/products/cas/downloads/index.html)

（我下载的就是这个版本，3.0应该也是可以的，我没有测试。）

But I found some typos and errors on that page. So following the instructions below should get you what you need.

In any directory ( I use my root ) enter the command:

keytool -genkey -alias tomcat -keypass changeit -keyalg RSA

Answer the questions: (note that your firstname and lastname MUST be hostname of your server and cannot be a IP address; this is very important as an IP address will fail client hostname verification even if it is correct)

Enter keystore password:  changeit
What is your first and last name?
[Unknown]:  localhost
What is the name of your organizational unit?
[Unknown]:
What is the name of your organization?
[Unknown]:
What is the name of your City or Locality?
[Unknown]:
What is the name of your State or Province?
[Unknown]:
What is the two-letter country code for this unit?
[Unknown]:
Is CN=localhost, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct?
[no]: yes

（这点需要注意，都需要添上，否则不能通过，不会生成.keystore目录；下面的文件名随便输入一个）
Then enter the command:

keytool -export -alias tomcat -keypass changeit -file %FILE_NAME%
I use server.cert for %FILE_NAME%. This command exports the cert you generated from your personal keystore (In windows your personal keystore is in C:\Documents and Settings\\.keystore)

Finally import the cert into Java's keystore with this command. Tomcat uses the keystore in your JRE (%JAVA_HOME%/jre/lib/security/cacerts)

keytool -import -alias tomcat -file %FILE_NAME% -keypass changeit -keystore %JAVA_HOME%/jre/lib/security/cacerts
Startup the CAS server

Now you are ready to startup your CAS server. Simply startup Tomcat and access CAS with https://localhost:8443/cas You should see the CAS login screen and no errors in your catalina logs.

[edit]Setting up Liferay Portal
[edit]web.xml
Note: If you are using Liferay 4.2, this filter is already defined. All you have to do is modify the URL parameters, if your CAS server is at a different location.

It's time to move on to configuring Liferay. In the web.xml file you will need to add a new filter and its mapping directly above the first existing auto login filter mapping. This new filter we just added will redirect all login attempts to the CAS server. If your hostname is different you can modify the init-params accordingly. 
 

xml 代码

If you use a ...serviceUrl param like above, after logging in with CAS, the browser will be redirected back to that serviceUrl. However, you can change it to the following and it will redirect back to the full URL that was originally requested. This allows you to have a deep link (e.g. to a certain layout with parameters for a portlet even) that is preserved through the CAS login process:

xml 代码

Then add the following to the rest of the auto login filters

xml 代码

[edit]system-ext.properties
Note: this is only needed in Liferay 4.2

Set the com.liferay.filters.sso.cas.CASFilter setting to true.

( system-ext.properties这个文件不存在，新建一个\ROOT\WEB-INF\classes\system-ext.properties，然后填入该内容)

Place the following in system-ext.properties:

   #
   # The CAS filter will redirect the user to the CAS login page for SSO. See
   # http://www.ja-sig.org/products/cas for more information.
   #
   com.liferay.filters.sso.cas.CASFilter=true

（portal-ext.properties 该文件存在，仅仅添加内容即可）
[edit]portal-ext.properties
Put this in portal-ext.properties.

##
## Auto Login
##
#
# Input a list of comma delimited class names that implement
# com.liferay.portal.security.auth.AutoLogin. These classes will run in
# consecutive order for all unauthenticated users until one of them return a
# valid user id and password combination. If no valid combination is
# returned, then the request continues to process normally. If a valid
# combination is returned, then the portal will automatically login that
# user with the returned user id and password combination.
#
# For example, com.liferay.portal.security.auth.BasicAutoLogin reads from a
# cookie to automatically log in a user who previously logged in while
# checking on the "Remember Me" box.
#
# This interface allows deployers to easily configure the portal to work
# with other SSO servers. See com.liferay.portal.security.auth.CASAutoLogin
# for an example of how to configure the portal with Yale's SSO server.
#
#auto.login.hooks=com.liferay.portal.security.auth.BasicAutoLogin
auto.login.hooks=com.liferay.portal.security.auth.BasicAutoLogin,com.liferay.portal.security.auth.CASAutoLogin
Comment the first auto.login.hooks property and uncomment the second to add CASAutoLogin to the list of AutoLogin implementations.

[edit]Startup Liferay and Test
Startup the portal and when the homepage loads up hit the login link. If all goes well you should be redirected to the CAS server's login screen. Login to CAS with liferay.com.1 as your username and liferay.com.1 as your password. You should now be logged into the portal.

The current auth scheme for CAS is quite simple but in production an auth scheme which taps into an LDAP repository or some other auth service will be required.

[edit]Troubleshooting
If you created a cert with the %FILE_NAME%, you'll probably run into problems. Here are 2 commands to delete the tomcat alias from the keystore so you can start fresh:

keytool -delete -alias tomcat -keystore %JAVA_HOME%/jre/lib/security/cacerts
keytool -delete -alias tomcat -file server.cert
You may not be able to get https://localhost:8443/cas up and running after the cert key generation. If so, skip the test and try it after you've finished all the steps. If you can't login at that point, you've probably generated your cert incorrectly.
I've had problems with certs on IE7, make sure you try it out on Firefox and Opera.
[edit]Lifecast
CAS Setup - Integrate Liferay Portal with a CAS server to access multiple applications with a single sign on.

Retrieved from "http://wiki.liferay.com/index.php/Single_SignOn_-_Integrating_Liferay_With_CAS_Server"
Category: Customization

       解压缩acegi-security-1.0.1.zip，拷贝acegi-security-sample-tutorial.war到%CATALINA_HOME%/webapps目录下，重启tomcat，acegi-security-sample-tutorial即已发布。现在我们将其改造为使用CAS进行用户的登录和认证。

    用编辑器打开WEB-INF/applicationContext-acegi-security.xml，找到

       <bean id="authenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">

                  <property name="authenticationManager" ref="authenticationManager"/>

                  <property name="authenticationFailureUrl" value="/acegilogin.jsp?login_error=1"/>

              <property name="defaultTargetUrl" value="/"/>

              <property name="filterProcessesUrl" value="/j_acegi_security_check"/>

              <property name="rememberMeServices" ref="rememberMeServices"/>

       </bean>

将其替换为：

       <bean id="authenticationProcessingFilter" class="org.acegisecurity.ui.cas.CasProcessingFilter">

              <property name="authenticationManager" ref="authenticationManager"/>

              <property name="authenticationFailureUrl" value="/acegilogin.jsp?login_error=1"/>

              <property name="defaultTargetUrl" value="/"/>

              <property name="filterProcessesUrl" value="/j_acegi_cas_security_check"/>

              <property name="rememberMeServices" ref="rememberMeServices"/>

       </bean>

其中，authenticationFailureUrl是认证失败时显示的页面，acegi-security-sample-tutorial登录失败时会在登录页(acegilogin.jsp)显示失败原因，现改为使用CAS之后，acegi-security-sample-tutorial使用CAS的登录页面，故acegilogin.jsp可去掉。接下来，找到

              <bean class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">

                     <property name="loginFormUrl" value="/acegilogin.jsp"/>

                     <property name="forceHttps" value="false"/>

              </bean>

替换为：

              <bean class="org.acegisecurity.ui.cas.CasProcessingFilterEntryPoint">

                     <property name="loginUrl">

                            <value>https://localhost:8443/cas/login</value>

                     </property>

                     <property name="serviceProperties">

                            <ref bean="serviceProperties"/>

                     </property>

              </bean>

再接下来，找到

       <bean id="authenticationManager" class="org.acegisecurity.providers.ProviderManager">

              <property name="providers">

                     <list>

                            <ref local="daoAuthenticationProvider"/>

                            <bean class="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider">

                                   <property name="key" value="changeThis"/>

                            </bean>

                            <bean class="org.acegisecurity.providers.rememberme.RememberMeAuthenticationProvider">

                                   <property name="key" value="changeThis"/>

                            </bean>

                     </list>

              </property>

       </bean>

将<ref local="daoAuthenticationProvider"/>修改为<ref local="casAuthenticationProvider"/>，并添加以下bean：

       <bean id="casAuthenticationProvider" class="org.acegisecurity.providers.cas.CasAuthenticationProvider">

              <property name="ticketValidator">

                     <ref bean="ticketValidator"/>

              </property>

              <property name="casProxyDecider">

                     <ref bean="casProxyDecider"/>

              </property>

              <property name="statelessTicketCache">

                     <ref bean="statelessTicketCache"/>

              </property>

              <property name="casAuthoritiesPopulator">

                     <ref bean="casAuthritiesPopulator"/>

              </property>

              <property name="key">

                     <value>some_unique_key</value>

              </property>

       </bean>

       <bean id="ticketValidator" class="org.acegisecurity.providers.cas.ticketvalidator.CasProxyTicketValidator">

              <property name="casValidate">

                     <value>https://localhost:8443/cas/proxyValidate</value>

              </property>

              <property name="serviceProperties">

                     <ref bean="serviceProperties"/>

              </property>

       </bean>

       <bean id="serviceProperties" class="org.acegisecurity.ui.cas.ServiceProperties">

              <property name="service">

                     <value>https://localhost:8443/acegi-security-sample-tutorial/j_acegi_cas_security_check</value>

              </property>  

       </bean>

       <bean id="casProxyDecider" class="org.acegisecurity.providers.cas.proxy.RejectProxyTickets"/>

       <bean id="statelessTicketCache" class="org.acegisecurity.providers.cas.cache.EhCacheBasedTicketCache">

              <property name="cache">

                     <bean class="org.springframework.cache.ehcache.EhCacheFactoryBean">

                            <property name="cacheManager">

                                   <bean class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"/>

                            </property>

                            <property name="cacheName" value="userCache"/>

                     </bean>

              </property>

       </bean>

       <bean id="casAuthritiesPopulator" class="org.acegisecurity.providers.cas.populator.DaoCasAuthoritiesPopulator">

              <property name="userDetailsService">

                     <ref bean="userDetailsService"/>

              </property>

       </bean>

改造完毕！

    五．配置CAS使用JDBC数据源进行用户认证

       CAS默认设置为只要用户名和密码相同，即可进行登录，这在现实使用中是不允许的。我们修改为使用MySQL的test数据库中的app_user表作为用户数据源。首先，我们在test库中创建一个表：

CREATE TABLE `app_user` (

  `username` varchar(30) NOT NULL default '',

  `password` varchar(45) NOT NULL default '',

  PRIMARY KEY  (`username`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

并添加如下用户：

INSERT INTO `app_user` (`username`,`password`) VALUES

 ('dianne','emu'),

 ('marissa','koala'),

 ('peter','opal'),

 ('scott','wombat');

用编辑器打开%CATALINA_HOME%/webapps/cas/WEB-INF/deployerConfigContext.xml，找到

    <bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" />

注释掉该行，在其下加入：

<bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler">

                            <property name="sql" value="select password from app_user where username=?" />

                            <property name="dataSource" ref="dataSource" />

                     </bean>

并添加一个bean：

    <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource" destroy-method="close">

       <property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property>

       <property name="url"><value>jdbc:mysql://localhost:3306/test</value></property>

       <property name="username"><value>test</value></property>

       <property name="password"><value>test</value></property>

    </bean>

拷贝cas-server-jdbc-3.0.5-rc2.jar和mysql-connector-java-3.1.12-bin.jar到%CATALINA_HOME%/webapps/cas/WEB-INF/lib下。

    重新启动tomcat，在浏览器中输入http://localhost:8080/acegi-security-sample-tutorial，你会发现，一旦你访问了受保护的页面，请求就会被重定向到CAS的登录页面，登录成功之后请求会被再被定向到最初访问的页面，如果有多个系统，在这些系统之间进行切换将不会要求用户重新登录，这就达到了单点登录的目的。

参考文献：

• Acegi security官方网站及文档：http://acegisecurity.org
• CAS官方网站及文档：http://www.ja-sig.org/products/cas
• SSL Configuration HOW-TO：http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
• 利用CAS实现SSO技术：http://kb.csdn.net/java/Articles/200606/2e082aae-775d-48be-b2fb-c2e218af9ba9.html
• Spring in Action中文版（ISBN7-115-14315-3/TP.5173）

CAS（Central Authentication Service）是耶鲁大学开发的一个开源的SSO（single sign on，单点登录）系统。它提供了丰富的客户端库，如Java, .NET, PHP, Perl等版本，使用这些库用户可以方便地给自己的应用程序加上CAS支持。Acegi security system for Spring是Spring的一个子项目，它为Java EE开发者提供了一个易于使用的提供认证和授权服务的安全框架。Acegi支持CAS，也可看作是CAS的一个Java版的Client。

以下详细介绍如何配置CAS以及应用程序，使其利用Acegi和CAS进行用户的登录和认证。我将以acegi-security-1.0.1发布包中附带的acegi-security-sample-tutorial应用为例，它使用DaoAuthenticationProvider对用户进行认证，用户帐号和权限信息保存在一个properties文件中，我将对其进行改造，改造之后，acegi-security-sample-tutorial使用CAS进行用户认证，授权信息仍从该properties文件读取，因为CAS只负责认证，不负责授权，所以授权工作交由客户端Acegi来完成，CAS的用户源配置为数据库，利用JDBC进行读取。本文需要读者对SSO和Acegi有一定的了解。

一．准备工作下载并安装Tomcat（<a target="_blank" rel="nofollow" href="http://tomcat.apache.org/">http://tomcat.apache.org/</a>），本文使用的版本是5.5.15；

二．安装CAS 解压缩cas-server-3.0.5-rc2.zip，拷贝target目录中的cas.war到%CATALINA_HOME%/webapps下即可。运行Tomcat，访问<a target="_blank" rel="nofollow" href="http://localhost:8080/cas">http://localhost:8080/cas</a>应可看到CAS登录界面。

三．配置Tomcat支持SSL 由于CAS要求使用https和客户端进行通信，所以需要配置Tomcat支持SSL，首先介绍如何制作自签名证书以及将其导入到证书库。

[Unknown]: localhost

接下来，用编辑器打开%CATALINA_HOME%/conf/server.xml，找到

&lt;Connector port="8443" maxHttpHeaderSize="8192"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true"

acceptCount="100" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS" /&gt;

这一行默认是被注释掉的，取消注释，并加入keystoreFile="keystore" keystorePass="password"这两个属性，注意keystoreFile属性可以使用keystore文件的绝对路径，也可使用基于%CATALINA_HOME%环境变量的相对路径，keystorePass是访问keystore的密码，应和上面制作证书时设定的密码保持一致。

南京地税目前有多种企业应用，包括征管系统、行政系统、辅助决策系统、公文系统、人事系统、电子地图、邮件系统等等，这些应用主要是采用三层体系结构（IE6.0+weblogic portal7.0 +weblogic server7.0 +oracle9i）来构架。所有的用户登陆需要通过weblogic portal进行。

我们在系统中使用SSO来实现用户通过一次认证（authenticate）来存取多个受保护的资源，也就是说，用户随后对受保护资源的存取，将不会导致每一次都要用户提供认证的信息，只需要一次认证即可。

一、SSO实现原理

1、概念：SSO的一种偏向技术的说法：用户只需登陆一次，就可使用多个SSO enable的应用系统。

（1）、单一的登陆点。理想的情况是用户通过任何应用系统都能进行SSO，这对于基于Web的系统是可行的。这种单一的登陆点在整个系统的设计中是唯一认证用户的地方，由登陆点将SSO token（针对不同的C/S，B/S应用可能还需要传递用户名，口令）传递给应用系统，应用系统利用SSO token来进行用户已认证的验证。我们将这个单一的登陆点称为SSO Entry。

（2）、SSO enable意味着对应用系统的修改不可避免。并不是任何系统都能够使用SSO，只有那些符合SSO规范，使用SSO API的应用系统才具有SSO的功能。简单地说就是要修改已有的应用系统，屏蔽已有的应用系统的用户认证模块，使用系统提供的SSO API来验证用户，以及对用户的操作进行授权。

（3）、需要统一的认证，权限信息库。通常，认证与授权管理模块以一种应用专有的方式实现，系统的授权模型、认证，授权信息存贮结构与访问控制逻辑与应用的业务逻辑之间耦合紧密。这种设计与实现方式的缺点是显而易见的：由于认证、授权模块与应用逻辑之间的紧耦合使得认证、授权模块很难进行扩展与维护；认证、授权模块的设计与编码需要很大的工作量，而且很难在不同的应用系统之间共享与重用。这也是越来越多企业应用需要SSO的原因之一。

SSO要求有统一的认证，权限存放库。但现实中，有的系统无法使用外部的认证，授权信息库，所以就需要在应用系统和Portal Server之间进行认证，同时进行授权信息的数据同步。

2、实现描述：在用户成功登录 weblogic Portal之后，系统提供的Login Delegate机制来为用户登录到其有权可以使用的应用系统。系统提供Logout Delegate机制实现用户的注销功能（即SSO logout）。

用户存取由Portal SSO保护的若干资源，SSO会话服务（Session/SSO Service）提供了授权的证明，这样就不再需要用户重新进行身份验证了。在这种方式下，即使用户要访问不同的域（weblogic domain）的应用，我们提供的Portal SSO Service为其保持会话服务。

同时，SSO还包括的与登录恰恰相反的，统一的注销点，即用户一旦从Portal注销，则亦当从所有参与Portal SSO的应用注销。此处有一个例外，就是当用户从Portal登录并转向一个应用后，经过一段时间后可能会出现用户的该应用的会话还有效时用户的Portal会话过期时，此时用户将只能使用该应用，直到该用户再次登录Portal。

3、通过SSO Agent：当用户试图通过浏览器存取受保护的应用资源时，系统提供安装在不同应用上的SSO Agent来截取用户对资源的请求，并检查请求是否存在会话标识符，即token。如果token不存在，请求就被传递给Portal SSO，在Portal SSO上会话服务负责创建会话token，然后认证服务将提供登陆页面以验证用户。

4、创建会话Token：在用户身份验证之前，会话服务就创建了会话token。token为随机产生的Portal  Server 会话标识符，该标识符代表了一个确定用户的特定会话。创建会话token后，认证服务把token插入cookie中在用户的浏览器中设定cookie。在token被设定的同时，该用户将会看到一个登陆页面。

5、用户认证：用户收到登陆页面和会话token后，填入合适的认证信息。当用户提交登陆页面后，这些认证信息就被发给认证提供者（authentication provider）（LDAP服务器，RADIUS服务器等）进行验证。一旦认证提供者成功验证了认证信息，用户就被认为是通过了认证。Identity Server会从用户的token中取出会话信息并将会话状态设为有效。此后，用户就可以访问这些受保护的资源。

6、cookie和会话token：Cookie是由Web服务器创建的信息包，并传递给浏览器。Cookie 保存类似用户习惯等Web服务器产生的信息。它本身并不表明用户通过了认证。Cookie是特定于某个域的。在Identity Server的实现中，cookie由会话服务产生，并由认证服务设定。而且，Identity Server的cookie是会话cookie，存储在内存中。会话token由会话服务创建并插入Cookie。会话token利用安全随机数发生器产生，并包含Portal Server特有的会话信息。在存取受保护的资源之前，用户由认证服务验证，并创建SSO token。

二、SSO技术实现

1、SSO entry

SSO entry 作为系统唯一的登陆点将完成如下的功能：

（1）提供用户身份认证的登陆页面；
（2）根据用户的权限，显示可供用户使用的应用系统；
（3）调用用户选择的应用系统（B/S或C/S均可）；
（4）为应用系统传递SSO Token（针对不同的C/S，B/S应用可能还需要传递用户名，口令）；
（5）关闭SSO；
（6）SSO token失效后，关闭SSO entry。

注意SSO entry 并不提供通知应用系统SSO token已失效的功能，这一问题并不大，因为SSO token失效后，SSO entry 已被关闭。用户只有重新认证，才能获取新的SSO token。

2、SSO 部署

 
上面是整个系统的部署的示意图。白色的立方体表示应用系统。浅蓝色的立方体表示Portal SSO平台。从上图可以看出：各个应用系统各个应用系统与SSO entry发生联系。SSO entry 需要向应用系统传递SSO Token，用户名，口令；启动应用系统。

3、SSO实现方式

SSO 的实现方式按照应用系统与Portal Server的交互程度分为三种。需要指出这些SSO的实现方式并没有优略之分，不同的实现方式适应不同的应用环境。解决现实中遇到的不同问题。真单点登陆： 通过SSO entry认证后，应用系统利用SSO API同Portal Server通信，验证用户是否经过认证。新开发的应用系统大多使用这种SSO的实现方式。这种方式需要对应用系统的认证模块进行修改。伪单点登陆：通过SSO entry认证后，应用系统还要自己进行用户的认证。这种方式适用于那些无法修改认证模块的应用系统。我们应用系统的整合采用该方式进行。整合第三方软件的单点登陆：Tarantella和Citrix都是将C/S应用系统转化为Web应用的第三方软件系统。在某些应用环境下，这类软件将发挥其作用。这种SSO实现方式在实施中并不使用，列出这种使用方式主要用来展现Identity Server的扩展性。

4、SSO的实现

（1）用户从Portal登录

说明：以上蓝色区域为Portal Server上的服务，白色为需要与Portal进行SSO的应用，绿色为每个应用的SSO Entry。代理登录的具体过程：用户首先登录Portal，Portal处理完登录后，启动代理登录，为用户登录应用系统，Portal把用户转向到应用系统，应用系统再把用户在征管系统的sessionID转发给Portal，登录代理（Login Delegate）把用户在征管系统中的sessionID和用户id发到征管系统的SSO Service进行登记，Portal把用户访问转向征管系统SSOEntry，征管系统SSOEntry通过用户的sessionID得到SSOService中记录的用户在Portal的用户userID，并把当前用户认可为此Portal userID对应的在征管系统中的用户，征管系统把用户访问转回Portal。接着登录代理再对SSO应用列表中的其它应用进行代理登录。代理登录完成，用户被重定向到Portal的相关页面。

用户访问应用系统：之后，当用户访问征管的某个应用时，征管系统发现该用户还未经认证，则将其sessionID与SSOService中登记的uid/sessionID比较，如果存在匹配，则认证通过，将用户id与session相关联。之后用户就可以直接访问征管系统了。

（2）SSO单点注销

 
说明：

（1）用户注销总是从Portal开始；
（2）注销代理（Logout Delegate）将注销消息发到各应用的SSO Logout Entry；
（3）应用的SSO Logout Entry注销本地的用户会话记录；
（4）注销Portal上的用户会话记录。

三、安全性分析

Portal SSO的安全性需要从几个方面理解：

1.客户登录Portal Server之后SSO到应用的安全性，即SSOToken的安全性；
2.客户无SSOToken时，首先访问应用的安全性；
3.客户有SSOToken时想通过仿冒别人的有效SSOToken来进行非法的访问。

Portal Server生成的SSO token 因为需要在应用程序间传递，所以SSOToken比较容易被窃取，但Portal Server保证了SSOToken的唯一性，那些盗用合法SSOToken的人无法通过SSOToken的验证。因为SSOToken的生成收集了用户端和服务器端的很多信息，当非法用户持有效的SSOToken试图访问某应用时，该应用将通过Portal Server的SSOService进行SSOToken验证时，SSOToken的这些信息以及Portal Server的安全算法确保了盗用者即使拿到合法用户的SSOToken也无法通过SSOToken的有效性验证。所以SSOToken的安全性也得到了保证。

用户没有SSOToken的时候，如果客户要访问某应用，如果用户没有该应用的会话信息也没有Portal的SSOToken，则该用户必须先通过Portal的认证并SSO到该应用；如果用户已经在应用登录成功（可能是该应用保留了原有的认证入口，用户通过该入口访问此应用，也有可能是用户从Portal 登录后，通过SSO访问该应用，经过一段时间后，用户的Portal SSOToken已经过期，但是用户在该应用中的会话仍然保持有效），则用户可以继续使用该应用系统而无需重新认证。但是如果用户想访问Portal或者与Portal进行SSO的其它应用的话，则用户须经过Portal的认证并拿到SSOToken。所以在这种情况下SSOToken也是安全的。

每个用户的SSOToken只在其当次会话过程中有效，离开其当次会话，SSOToken即被视作无效，因此这种情况下也是安全的。

在Jive Forum部署时，需使用Oracle Internet Directory（OID）作为LDAP目录数据库，位于搜索路径下的所有用户都可以登录Jive Forum，在配置时可以指定一名管理员，并在Oracle数据库JIVEUSERPREP表中用相应用户的USERID替换原本admin的USERID。随后按以下步骤实施即可。

This document describes how you should configure Jive Forums Enterprise Edition to leverage Oracle Identity Management for maintaining the user credentials.  It also describes how you can register the OracleAS Provider for Jive Forums with your OracleAS Portal and how to add the provider's portlets to your portal page.  You should use these instructions if your Jive Forum Enterprise Edition Application is deployed on the OracleAS instance.

Note: This feature is not available on the Professional Editions of Jive Forums.

It is possible to configure Jive Forums to use Oracle Identity Management as an external LDAP server to authenticate and store user profile information. This configuration ensures that the user entries are managed by a single server. Please refer to your Jive Forums Installation Document for further information on how to configure the Jive Forums application to work in the LDAP mode. In order to configure the LDAP mode, you will require to gather the following information about the Oracle Identity Management, against which you are authenticating your users.

• The Identity Management host
  
• The Identity Management port
  
• The base DN for searching the users.

The above information can be obtained from OracleAS Portal, available on the Builder Page, under Administer->Global Settings.

Once you have your Jive Forums application running successfully in the LDAP mode, make the following changes to the jive_config.xml file in your jiveHome directory. Replace the existing entry for the <AuthFactory> element with the following one.

<AuthFactory>
     <className>oracle.webdb.ohs.forum.security.PortalLdapAuthFactory</className>
</AuthFactory>

It is also possible to have an Oracle Single Sign-On (SSO) server authenticate the users for the Jive Forums application. This functionality can be achieved by modifying the login / logout actions of the Jive Forums application. In order to enable the SSO feature, you have to create a file named custom-actions.xml file in the WEB-INF/classes directory, with the following content:

<?xml version="1.0" encoding="UTF-8"?>

<actions>

  <!-- Base actions -->
  <action name="oracle.webdb.ohs.forum.actions.SSOLoginAction" alias="login">
    <view name="success">doRedirect.jspa?url={jive.login.successURL}</view>
    <view name="cancel">doRedirect.jspa?url={jive.login.cancelURL}</view>
    <view name="fatal">doRedirect.jspa?url=index.jsp</view>
  </action>
 
  <action name="oracle.webdb.ohs.forum.actions.SSOLogoutAction" alias="logout">
    <view name="success">logout-success.jsp</view>
    <view name="error">error.jsp</view>
  </action>

</actions>

Note: If the file already exists, then Copy and Paste the content within the <actions> tag, into the custom-actions.xml file.

The <OC4J_Instance> would need to be restarted for the changes to take effect, where <OC4J_Instance> is the OC4J instance where Jive Forum is installed.

1. Login to OracleAS Portal as an OracleAS Portal Administrator.  Go to the Administer tab of the OracleAS Portal Builder page.
2. Under the Portlets tab, click on Register a Provider within the Remote Providers portlet.

3. Fill out provider information for the  Provider:

   • Name: OracleAS_Provider_for_Jive_Forums
   • Display Name: OracleAS Provider for Jive Forums
   • Timeout: 30
   • Timeout Message: OracleAS Provider for Jive Forums Timed Out
   • Implementation Style: Web
4. Click on the Next button to enter the Web Provider specific information

5. Enter the Web Provider location

   • URL: http://<server>:<port>/<jiveContext>/providers/forum

example: if your jive url looks like, http://my.company.com/jive3, then your web provider location is http://my.company.com/jive3/providers/forum

6. Select the radio button labeled The user has the same identity in the Web providers application as in the Single Sign-On identity.
7. Scroll down to the User/Session Information section and specify the login frequency as Once Per Session.
8. Click on the Finish button to complete the registration

Note: When registering a new provider with OracleAS Portal, only the user who registered the provider has privileges to see the provider/portlets. If necessary, go to the Folder with the name of the provider within the Portlet Repository content area and update the provider privileges as required.

You are now ready to add the OracleAS Provider for Jive Forums Portlets to a page.

Introduction

When I was trying to understand the mechanisms involved in writing proxying applications using CAS, I found it very helpful to manually walkthrough the aquisition of a proxy ticket. The CAS server played itself in this exercise and I played all the other roles - user, proxying application and proxied application - simply by constructing URLs and feeding them into a web browser.

The only part of the exercise that can't be done with just a web browser and careful URL construction is the part where CAS makes it's own callback to the proxying application. For this, I chose a proxy callback url on a machine for which I had access to the log files and scanned through the HTTP requests to find the information I wanted.

Step One: login

To start with, log in to CAS with some invented service:

https://foo.bar.com/is/cas/login?service=http://localhost/bling

On successful login, CAS will redirect you to the service with a ticket appended (it doesn't matter that the service is made up as the ticket you're after is part of the url and will appear in the location bar even if your browser can't find the resource):

http://localhost/bling?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS

Step Two

(a): verify the ticket and be done

So, playing the role of the first application (not a proxying application at this stage - lets just see if we can get our application authenticated without proxying for now), you need to take the ticket and turn it into a username:

https://foo.bar.com/is/cas/serviceValidate?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS&service=http://localhost/bling

which will produce a result like:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationSuccess> <cas:user>endjs</cas:user> </cas:authenticationSuccess></cas:serviceResponse>

This is the end of the road for normal applications that don't need to proxy other applications.

Step Two (b): verify the ticket and enable further proxying

If instead you do want to be able to proxy other applications you need to also supply a pgtUrl to your validation request so that CAS can callback with the Proxy Granting Ticket. This is where life gets complicated, especially if you forget that service tickets are one-time-only tickets and that once you've used them with serviceValidate, you have to go back to CAS and get a new one (so if you've done Step One and Step Two (a) you'll need to do Step One again before you can do Step Two (b)).

The choice of pgtUrl here is fairly arbitrary except that it needs to be an https url and it needs to be on a server on which you can access the log files.

https://foo.bar.com/is/cas/serviceValidate?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS&service=http://localhost/bling&pgtUrl=https://foo.bar.com/pgtCallback

results in:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationSuccess> <cas:user>endjs</cas:user><cas:proxyGrantingTicket>PGTIOU-85-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523Eti2td</cas:proxyGrantingTicket> </cas:authenticationSuccess></cas:serviceResponse>

Step Three: dig out the PGT

Now our first application knows who the user is and has a Proxy Granting Ticket IOU. To find the real PGT we look in the apache access log for foo.bar.com and hunt out the request made by CAS to deliver the PGT:

foo.bar.com - - [10/Dec/2003:09:28:15 +0000] "GET/pgtCallback?pgtIou=PGTIOU-85-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523Eti2td&pgtId=PGT-330-CSdUc5fCBz3g8KDDiSgO5osXfLMj9sRDAI0xDLg7jPn8gZaDqS HTTP/1.1" 200 13079

(Editor's note: linebreaks introduced for page formatting.)

Step Four: get a proxy ticket

With the PGT in our grasp we can make a call on CAS to give us a proxy ticket for some other service we wish to proxy:

https://foo.bar.com/is/cas/proxy?targetService=http://localhost/bongo&pgt=PGT-330-CSdUc5fCBz3g8KDDiSgO5osXfLMj9sRDAI0xDLg7jPn8gZaDqS

resulting in:

<cas:serviceResponse> <cas:proxySuccess> <cas:proxyTicket>PT-957-ZuucXqTZ1YcJw81T3dxf</cas:proxyTicket> </cas:proxySuccess></cas:serviceResponse>

Step Five: verify the proxy ticket

Now we take on our final role for the exercise - the proxied application. The proxying application has invoked our service url and has passed in the proxy ticket it's got. We take that ticket and validate it to find out both who the user is and which applications are in the proxy chain:

https://foo.bar.com/is/cas/proxyValidate?service=http://localhost/bongo&ticket=PT-957-ZuucXqTZ1YcJw81T3dxf

resulting in:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationSuccess> <cas:user>endjs</cas:user> <cas:proxies> <cas:proxy>https://foo.bar.com/pgtCallback</cas:proxy> </cas:proxies> </cas:authenticationSuccess></cas:serviceResponse>

Obviously, this walkthrough doesn't help with acquiring and plugging in good proxying code for your application but it does help to see what the proxying code needs to be doing and makes it easier to write your own.

Originally provided by: David Spencer on the CAS mailing list.

CAS 2.0 is the version of CAS currently in production at Yale University. CAS 2.0 is backwards compatible with CAS 1.0; it simply introduces new features. Application developers at Yale need only understand the concepts and techniques in the CAS 1.0 paper to integrate with CAS successfully, unless their applications need to proxy credentials (as is the case with portals, web-mail services, and so forth). Unless you develop such applications, you will likely be more interested in the original CAS 1.0 Architecture document.

Motivation for upgrade

• The agent must establish its own identity
• The agent must demonstrate that it has been in contact with the user "recently."
  The first criterion alone is insufficient because it is undesirable for even a relatively trusted agent to be able to impersonate all users baselessly; the second is likewise inadequate because not every agent in contact with the user is necessarily trusted to represent that user to any given third party. (Indeed, CAS specifically prevents two unrelated services from sharing credentials meaningfully.)

(As a side note, since "contact" with a service protected by the Central Authentication Service doesn't necessarily involve any affirmative action on the part of the user, the "contact with service" provision could be dropped, and a simpler requirement of "contact with CAS itself" could be substituted in its place. Under such a model, a proxy could simply authenticate itself to a back-end target service and assert that it acts on behalf of any user who recently authenticated with CAS. However, we prefer a model where CAS – instead of back-end services – may authenticate proxy agents. As usual, CAS can centralize authentication procedures, resulting in simpler management and use.)

The players

Player	Role
CAS = The Central Authentication Service	a trusted arbiter of authenticity
Service	A web application that authenticates users via CAS.
Proxy	A service that wants to access other services on behalf of a particular user.
Target (or back-end service)	A service that accepts proxied credentials from at least one particular proxy.

Tickets

Parties involved in a CAS authentication make use of tickets, or opaque strings that prove some assertion to CAS. CAS 2.0 uses the following tickets:

Ticket type	description
Ticket-granting cookie (TGC)	A ticket encapulated by a cookie that is sent to the user's web browser and returned only to CAS, and only over a secured channel. This (optional) ticket establishes the user's identity with CAS and lets CAS act as a single sign-on system for the web.
Service ticket (ST)	A ticket sent by CAS, through the user's browser, to a service. Each ST may be used only once, and must be combined with the unique identifier for one specific service in order to be useful. (Put another way, a service that knows its own unique identifier will refuse to accept STs intended for another service. This prevents one service from mounting a "man in the middle" attack against another.)
Proxy-granting ticket (PGT)	A ticket sent by CAS to a service holding a valid ST (but see below). This ticket (associated with an individual service and an individual user) confers the ability to produce proxy tickets (see below)
Proxy-granting ticket IOU (PGTIOU)	A ticket sent by CAS alone in a service validation response, and with a PGT to the callback URL. It is the web application's responsibility to maintain a table to correlate PGTIOUs and PGTs (see below)
Proxy ticket (PT)	A ticket usable by a proxy to access a target by impersonating a single user. The PT carries information about the proxy or proxies attempting to gain access. For targets that are also (second- or higher-level proxies), a PT may be used to obtain a PGT, but this PGT will preserve information about the linear series of proxies that lie between the user and the ultimate target.

Proxy mechanism:

For the purposes of the this document, it's assumed you're familiar with CAS 1.0's underlying processes, which are described in more detail in the ITS Central Authentication Service paper. CAS's basic mechanism can be diagrammed as follows:
 

Request: The web application sends an HTTP request with two query parameters: ticket and service, representing respectively an ST and the unique identifier (URL) corresponding to the web application.

In recognition of XML's increasing popularity, CAS 2.0 supplements this existing protocol with an existing and optionally available one. The format of the request is the same as above, but the response takes the following format:

Response: CAS response with an XML document whose root element is <cas:serviceResponse>. On failure, the document node contains a single subelement:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>    <cas:authenticationFailure code="...">	Optional authentication failure message    </cas:authenticationFailure>  </cas:serviceResponse>

On success, the document node contains a subelement with its own marked-up content:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>    <cas:authenticationSuccess>	<cas:user>NetID</cas:user>    </cas:authenticationSuccess>  </cas:serviceResponse>

In addition to this core validation protocol, CAS 2.0 provides an additional protocol available to any web applications that wish to use it. As before, the format of the request is the same, but the response, on success, contains an extra element providing new information:

<cas:serviceResponse>    <cas:authenticationSuccess>        <cas:user>NetID</cas:user>        <cas:proxyGrantingTicket>PGTIOU</cas:proxyGrantingTicket>    </cas:authenticationSuccess>  </cas:serviceResponse>

The proxyGrantingTicket element contains as its body content information identifying the PGT to be sent to the web application, essentially a PGT "IOU". This value is not the typical opaque identifier for the actual PGT; it is simply a unique value that indexes this PGT. Synchronously, CAS must send the PGT's actual (opaque) value as a request parameter to a URL owned by the application (and identified by the request parameter proxyCallbackUrl in the validation request to CAS). The callback request contains two query parameters: pgtId, containing the actual value representing the PGT, and pgtIou, containing the PGTIOU contained in CAS's response to the web application's request.

Once this PGT has been received and matched appropriately by the web application, it enables a new protocol (exposed to web applications) that allows the retrieval of specific-use proxy tickets (PTs), also defined earlier:

Response: A cas:proxyFailure message can be returned here for invalid or expired PGTs. On success, a message of the following format is sent by CAS to the application:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>    <cas:proxySuccess>      <cas:proxyTicket>PT</cas:proxyTicket>    </cas:proxySuccess>  </cas:serviceResponse>

This PT may then be sent by the application to the target service, which validates it with CAS using the following protocol.

Response: As before, authenticationFailure is an option here. On success, a message with the following form is returned:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>    <cas:authenticationSuccess>	<cas:user>NetID</cas:user>        <cas:proxyGrantingTicket>PGTIOU</cas:proxyGrantingTicket>	<cas:proxies>	   <cas:proxy>proxy1</cas:proxy>	   <cas:proxy>proxy2</cas:proxy>	   <cas:proxy>proxy3</cas:proxy>	   ...	</cas:proxies>    </cas:authenticationSuccess>  </cas:serviceResponse>

The target service may then make any access-control decisions it needs to make, based both on the username and the proxy "path" conveyed by the response from CAS.

Miscellaneous updates to CAS 1.0

• Users can now choose, from the login page, to be warned before CAS uses its single sign-on capabilities to log them into web applications. This facilitates anonymous web browsing in situations where this is a concern.
• Applications that pass the value true for the request parameter renew when redirecting users to CAS's login page can explicitly choose to opt out of CAS's single sign-on facility. This is appropriate for applications that want to use CAS but want to ensure that the user is still present before displaying sensitive information. Normally, this behavior is simply advisory and does not ensure the user just recently logged in; however, if you pass the value true for the request parameter renew to the URL for service-ticket validation, CAS will fail to authenticate the user unless the service ticket you've passed was the result of a new primary authentication.
• Applications that pass the value true for the request parameter "gateway" when redirecting users to CAS's login page instruct CAS not to conduct a primary authentication. This is useful for applications that want to accept a pre-existing CAS ticket-granting cookie but do not otherwise want to interrupt their own page flow with CAS's login screen. (Such behavior is expected to be transitional.)

Restrictions and other changes include the following:

• Because of incompatibilities between different browsers, service URLs may not include encoded or bare representations of linefeed, carriage return, or double-quotation-mark characters. If a page in your application uses such characters in query strings, ensure that it is not the first page that requires CAS authentication.

一般来说单点认证都需要两端来完成，在认证中心端的我们称之为SSO，在网站端的模块我们称之为PSO。两个模块之间采用二次重定向技术来实现同步两端票据的方式来实现单点登陆

首先我们就来看看这两个模块式如何配合来完成单点认证的

第一个场景是用户首先访问认证中心登陆再去进入成员网站的情况：

首先是登陆后产生一个SSO的票据，这个票据是最重要的，因为它是决定用户是否登陆的关键。这个票据可以是Cookie,也可以是Session,我比较倾向于Cookie，因为现在有3DES加密，加密后篡改Cookie几乎成为不可能，所以无论是对于服务器负担来说还是安全性都是Cookie比较好，可能人认为万一不支持Cookie呢，不过我想Demo应该没问题吧，大不了我设计成两个都支持：}，

PS，为什么不用非对称加密？其实那个效率不高，3DES的安全性已经足够了，至少现在还没有人宣称能破解

在登陆后就可以通知用户你已经登陆了，现在你可以去访问成员站点了，这个时候用户点击了成员站点的URL，进去了，这个时候首先就需要接受PSO组件的盘查，你有没有PSO的票据呢？很显然是没有的，所以这个时候请求就被Redirect回了认证中心，认证中心检查用户已经有了SSO的票据了，认为用户已经登录了，就把用户的SSO票据附加在URL后边然后Redirect回成员站点，成员站点的PSO这个时候获取到了SSO票据，于是知道了用户已经在认证端登录了，于是就创建一个PSO票据，然后返回给用户他所请求的内容。所以我们来看看其实PSO的逻辑更加复杂一点。

SSO的逻辑：

PSO的逻辑：

这里我们可以看到其实两个模块的功能都不算复杂，这里存在几个现实的问题，第一个是加密问题，票据需要加密，传输的URL也需要加密。

还有一个就是上一次我上篇文章里说的，在SSO把票据通过URL发送给PSO的时候，如果我们能够截获这个URL，不管他加没有加密，在下一次我们直接用这个URL去访问站点的时候因为已经包含SSO票据了，所以PSO会认为已经登陆了而直接产生PSO票据然后就让用户进去了，这显然是一个漏洞。所以呢，我们需要在这里给这个URL加一点盐值（所谓盐值其实就是加点料），我们通过在URL里加入时间戳来让这个URL具备时间限制，这个样子URL具备失效期，过了这个时间即使截获到了这个URL也完全没有作用了。

什么是安全套接字层技术？

安全套接字层(SSL)是允许Web浏览器和Web服务通过安全连接进行通信的技术。在这种安全连接上，数据在发送前经过加密码，然后在接收时先解密再进行处理。浏览器和服务器在发送任何数据之前都对所有流量加密。SSL是针对下列重要的安全性考虑的：

身份验证

在第一次尝试与Web服务器通过安全连接通信时，这台服务器将以服务器证书的形式向Web浏览器发送一份凭证。这个证书的目的是验证这个站点就是它所宣称的那一个。在有些情况下，服务器可能要求客户端提供证明它就是它所宣称的身份的证书(即客户端身份验证)。

机密性

数据通过网络在客户端与服务器之间传送时，第三方可以查看并截获该数据。SSL响应是加密的，这样数据就不会被第三方解密而仍然保持其机密机。

完整性

当数据通过网络在客户端与服务器之间传送时，第三方可以查看并截获该数据。SSL帮助保证数据在传输过程中不被第三方修改。

要在自己的独立Web服务器上安装并配置SSL，需要下列组件。以下各节专门讨论在Tomcat上启用SSL支持。如果使用不同的Web服务器，请参照相应产品的文档。

·  Java 安全套接字扩展(Java Secure Socket Extension JSSE))(见使用JSSE)。

·  服务器证书keystore(见设置数字证书)。

·  一个HTTPS连接器(见配置SSL连接器)。

要验证启用了SSL支持，参见验证SSL支持。

使用JSSE

如果使用J2SE SDK v1.3.1，那么需要安装Java安全套接字扩展(JSSE)以使用SSL。JSSE是J2SE 1.4 SDK的一部分。JSSE是一组Java包，它使安全Internet通信成为可能。这些包实现了Java版本的SSL(安全套接字层)和TLS(传输层安全性)协议并包括数据加密、服务器身份验证、消息完整性和可选的客户端验证功能。使用JSSE，开发者在可以为客户端和运行任何TCP/IP之上的应用协议(如HTTP、Telnet、NNTP和FTP)的服务器之间提供安全数据传输。

在默认情况下，jsse.jar文件的位置是<JAVA_HOME>/jre/lib/jsse.jar。有关JSSE的更多信息，参见其Web站点http://java.sun.com/products/jsse/。

设置数据证书

为了实现SSL，一个Web服务必须对每一个接受安全连接的外部接口或者IP地址有一个相关联的证书。这种设计背后的理论是服务器应该对其拥有者身份提供某种合理的保证，特别是在接收任何敏感信息之前。将证书想像为Internet地址的“数字驱动的许可许”可能会有帮助。它声明这个站点与哪个公司相关联，以及站点所有者或者管理员的一些基本联系信息。

数字证书是由其拥有者加密签名，任何其他人都难以仿造。对于涉及电子商务的站点，或者任何其他身份验证起重要作用的业务交易站点，可以从像verisign或者Thawte这样的著名证书颁发机构(Certificate Authority CA)购买证书。

如果身份验证并不很重要，比如管理员只是希望保证服务器发送和接收的数据是私有的并且不能被连接中的任何窃听者探听到，则可以只是使用自签名的证书，从而省去获取CA证书的时间和成本。

SSL使用公钥加密，它基于密钥对。密钥对包含一个公钥和一个私钥。如果数据是用其中一把钥匙加密的，那么只能用钥匙对中的另一把钥匙解密。这种特性是建立交易信任和私有性的基础。例如，使用SSL时，服务器计算出一个值并用其私钥加密这个值。加密的值称为数字签名。客户端用服务器的公钥解密这个加密的值并将这个值与它自己的计算值进行比较。如果这两个值相匹配，那么客户端就可以信任签名是真的，因为只有用私钥才可以生成这个签名。

数字证书与HTTPS协议一共使用以验证Web客户端身份。除非安装了数字证书，否则大多数Web服务的HTTPS服务都不会运行。使用下面描述的过程设置可以被Web服务器使用的数字证书以启用SSL。

一种可以用于设置数字证书的工具是keytool，这是一种与J2SE 1.4 SDK一同发布的密钥和证书管理工具。它使用户可以管理他们自己的公/私钥对以及相关的证书，以在自验证(用户向其他用户/服务验证他/她自己)或者数字完整性和身份验证服务用使用。它还让用户可以缓存他们通信伙伴的公钥(以证书的形式)。要更好地理解公钥加密，参阅以下地址上的文档

http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/keytool.html

证书是来自某一实体(人员、公司等)的数字签名的声明，表明其他实体的公钥(或者一些其他信息)有一个特定值。当对数据进行数字签名后，可以对该签名进行验证以检查数字完整性和真实性。完整性意味着数据没有被修改或者篡改，真实性意味着数据确实是来自宣称创建和对它签名的地方。

keytool将储存密钥和证书储存在一个名为keystore的文件中。Keystore的默认实现将keystore实现为一个文件。它用密码保护私钥。有关keytool的更多信息，参阅以下地址的文档

http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/keytool.html

本节描述创建一个名为server.keystore的服务器keystore以及名为client.keystore的客户端keystore。这两个文件构成一个密钥对。这些文件通常是在<HOME>目录中或者在应用程序目录中创建的。

除了服务器和客户端keystore，还必须有签名的证书，它必须存在于服务器上。在服务器验证客户端身份时，这个文件必须包含证书颁发机构的公钥证书或者客户端的公钥证书。我们将在<HOME>目录中创建server.cer。

通常，keystore文件是由密码保护的。对于server.keystore、client.keystore和server.cer文件这个密码的默认值是changeit。

我们使用keytool工具创建keystore文件。可以在<JAVA_HOME>/bin目录中找到keytool工具。

要设置数字证书，

1.     生成密钥对

keytool工具使您可以生成密钥对。随J2SE SDK发布的keytool工具在程序中增加了实现了RSA算法的Java 密码扩展提供程序。这个提供程序使您可以导入RSA签名的证书。

如下运行keytool工具以生成keystore文件，用keystore文件的名字替换<keystore_filename>，例如server.keystore。如果使用Tomcat服务器，文件必须命名为.keystore并位于Tomcat运行的计算机的home目录中，或者通过在Tomcat配置文件中的<Factory>元素中添加一个keystoreFile属性、或者在admintool的Connector (8443)节点上指定该文件的位置以告诉Tomcat这个keystore文件是什么地方。

keytool -genkey -keyalg RSA -alias tomcat-server
    -keystore <keystore_filename>

2.     keytool工具提示您加入以下信息：

a.   Keystore password--输入默认密码，即changeit。有关改变密码的信息参见keytool文档。

b.   First and last name——输入适当的值，例如JWSDP。

c.   Organizational unit——输入适当的值，例如Java Web Services。

d.   Organization——输入适当的值，如Sun Microsystems。

e.   City or locality——输入适当的值，例如Santa Clara。

f.    State or province——.输入非缩写名，如CA。

g.   Two-letter country code-——对于美国，双字母国家代码是US。

h.   Review the information you've entered so far, enter Yes if it is correct.检查输入的信息，如果都正确，则输入Yes。

i.    Key password for the Web server——不输入密码。按回车。

下一步是为该keystore生成签名的证书。一个自签名的证书对于大多数SSL通信来说是可以接受的。如果使用自签名的证书，则进入创建自签名的证书。如果想让证书由CA数字签名，则进入获取数字签名的证书。

创建自签名的证书

本例假设keystore命名为server.keystore，证书文件是server.cer，CA文件是cacerts.jks。在<HOME>目录中运行以下命令以使它们创建到这里。

1.     将服务器证书导出为证书文件：

keytool -keystore server.keystore -export -alias tomcat-server -file server.cer

2.     输入密码(changeit)：

Keytool返回下列消息：

Certificate stored in file <server.cer>

3.     将新的服务器证书导入到证书颁发机构文件cacerts.jks：

keytool -import -alias serverCA -keystore <HOME>/cacerts.jks
-file server.cer

4.     输入密码(changeit)。

Keytool返回类似下面的消息：

Owner: CN=JWSDP, OU=Java Web Services, O=Sun, L=Santa Clara,
ST=CA, C=US
Issuer: CN=JWSDP, OU=Java Web Services, O=Sun, L=Santa Clara,
ST=CA, C=US
Serial number: 3e39e3e0
Valid from: Thu Jan 30 18:48:00 PST 2003 until: Wed Apr 30 19:48:00 PDT 2003
Certificate fingerprints:
MD5: 44:89:AF:54:FE:79:66:DB:0D:BE:DC:15:A9:B6:09:84
SHA1:21:09:8A:F6:78:E5:C2:19:D5:FF:CB:DB:AB:78:9B:98:8D:06:8C:71
Trust this certificate? [no]: yes
Certificate was added to keystore

获取数字签名的证书

本例假设keystore命名为server.keystore，证书文件为server.cer，并且CA文件是cacerts.jks。

1.     CA获得数字签名的证书。为此，

a.   生成证书签名请求(Certificate Signing Request CSR)。

keytool -certreq -alias tomcat-server -keyalg RSA
-file <csr_filename> -keystore cacerts.jks

b.   发送csr_filename的内容以进行签名。

c.   如果使用Verisign CA，则进入http://digitalid.verisign.com/。Verisign将在电子邮件中发送签名的证书。将这个证书储存在一个文件中。

d.   将通过电子邮件收到的签字的证书导入服务器：

keytool -import -alias tomcat-server -trustcacerts -file
<signed_cert_file> -keystore <keystore_filename>

2.     导入证书(如果使用CA签名的证书)。

如果证书是由证书颁发机构(CA)签名，那么必须导入CA证书。如果只使用自签名证书则可跳过这一步。如果使用自签名证书或者由浏览器不识别的CA签名的证书，那么用户第一次试图访问服务器时就会跳出一个对话框。用户可以选择只在这个会话中、还是永远信任这个证书。

要在标准版本的Java 2平台安装CA证书，如下运行keytool工具。

keytool -import -trustcacerts -alias root
  -file <ca-cert-filename> -keystore <keystore-filename>

为相互验证创建客户端证书

创建客户端证书的过程与创建服务器证书类似。

1.     用keytool在所选的keystore文件中创建客户端证书：

keytool -genkey -keyalg RSA -alias jwsdp-client -keystore client.keystore

会提示输入密码。输入默认密码changeit。根据提示输入名字、组织和其他客户端信息。不要在“Key password for <client>”输入任何内容，只需要按回车。

2.     将新客户端证书从keystore导出到证书文件：

keytool -keystore client.keystore -export -alias jwsdp-client -file client.cer

3.     输入keystore密码(changeit)。Keytool将返回该消息：

Certificate stored in file <client.cer>

4.     将新客户端证书导入到服务器的证书颁发机构文件cacerts.jks中。这使服务器在SSL相互验证过程中信任该客户端。

keytool -import -alias root -keystore <HOME>/cacerts.jks
-file client.cer

5.     输入keystore密码(changeit)。Keytool返回下面的消息：

Owner: CN=JWSDP Client, OU=Java Web Services, O=Sun, L=Santa
Clara, ST=CA, C=US
Issuer: CN=JWSDP Client, OU=Java Web Services, O=Sun, L=Santa Clara, ST=CA, C=US
Serial number: 3e39e66a
Valid from: Thu Jan 30 18:58:50 PST 2003 until: Wed Apr 30
19:58:50 PDT 2003
Certificate fingerprints:
MD5: 5A:B0:4C:88:4E:F8:EF:E9:E5:8B:53:BD:D0:AA:8E:5A
SHA1:90:00:36:5B:E0:A7:A2:BD:67:DB:EA:37:B9:61:3E:26:B3:89:46:
32
Trust this certificate? [no]: yes
Certificate was added to keystore

检查相互验证是否已运行

要证明SSL握手已进行，关闭Tomcat，在<JWSDP_HOME>/bin/catalina.bat文件中发送debug旗标，然后重新启动Tomcat。服务将显示握手消息，或者将它们写入文件<JWSDP_HOME>/logs/launcher.server.log中。下面例子以粗体显示新代码。

rem Execute the Tomcat launcher
"%JAVA_HOME%\bin\java.exe" -Djavax.net.debug=ssl,handshake
-classpath %PRG%\..;%PRG%\..\..\jwsdp-shared\bin;"%PRG%

在Tomcat服务器使用PKCS12证书

Java WSDP支持PKCS12格式的证书。PKCS12标准规定储存或者传输用户私钥、证书和各种秘密的可移植格式。更多信息参见以下Web站点：

http://www.rsasecurity.com/rsalabs/pkcs/pkcs-12

如果有PKCS12格式的证书，那么必须将它转换为JKS格式。进行转换的命令是：

keytool -pkcs12 -pkcsFile <fileName> -pkcsKeyStorePass
<password> -pkcsKeyPass <password> -jksFile <outputFileName>
-jksKeyStorePass <password>  

结果是一个含有密钥——私钥和证书链——的JKS文件。

用带-export选项的keytool将证书导出到一个文件中，如abc.cer：

keytool -keystore <outputFileName> -export -alias <server> -file abc.cer

证书的各种命令

·  检查服务器证书的内容：

keytool -list -keystore server.keystore -alias tomcat-server -v

·  检查cacerts文件的内容：

keytool -list -keystore cacerts.jks

配置SSL连接器

取决于Web服务器，可能它会启用SSL HTTPS连接器，也可能不启用。如果使用Tomcat服务器，那么就没有配置SSL连接器。本节描述如何为Tomcat配置SSL HTTPS连接器。如果使用其他Web服务器，则应该参考相应服务器的文档。

在部署描述符中必须包含一个用于SSL连接的元素Connector。在改变服务器部署描述符之前，必须关闭服务器。下列代码是在Web服务器上启用SSL连接器的代码示例：

<Connector
   className="org.apache.coyote.tomcat5.CoyoteConnector"
   port="8443" minProcessors="5" maxProcessors="75"
   enableLookups="true" acceptCount="10" debug="0"
   scheme="https" secure="true" useURIValidationHack="false">
<Factory className="com.sun.web.security.SSLSocketFactory"
   clientAuth="false" protocol="TLS" debug="0" />
</Connector>

这个Connector元素的属性在附录A Tomcat服务器管理工具中有更详细的描述。可以使用下面两种方法之一向Tomcat添加SSL HTTPS连接器：

·  使用admintool添加Connector。参见在admintool中添加SSL连接器。

·  向服务器的部署描述符添加SSL连接器的Connector元素。参见在server.xml中配置SSL。

在admintool中添加SSL连接器

要用admintool配置SSL连接器，必须首先像在设置数字证书中所描述的那样创建一个keystore。Tomcat会在它所运行的计算机上的主目录中寻找名为.keystore的keystore。确认已经创建了keystore以后，进行以下步骤：

1.     如果Tomcat还没有启动，就启动它。

2.     在Web浏览器中输入http://localhost:8080/admin in a Web browser启动admintool。

3.     输入为admin角色指定的用户名和密码组合。

4.     在左边窗格中选择服务(Java Web Services Developer Pack)。

5.     从右边窗格中的下拉列表中选择Create New Connector。

6.     在Type域，选择HTTPS。

7.     在Port域，输入8443(或者其他所要求的端口)。这会定义Tomcat会监听哪个安全连接的TCP.IP端口号。

8.     如果创建了keystore，其名字不是.keystore，如果keystore不在Tomcat所运行的计算机上的home目录中，或者密码不是默认值changeit，则输入Keystore Name和keystore Password。如果使用了期望值，则可以不填写这些域。

在Unix和Linux系统中home目录是/home/user_name，在Microsoft Windows系统中是C:\Documents and Settings\user_name。

9.     选择Save以为该会话保存新Connector。

10.   选择Commit Changes以将新Connector信息写入文件server.xml，这样下次Tomat启动时它就是可用的了。

要查看和/或者编辑新创建的Connector，展开Service(Java Web Services Developer Pack)节点，并选择Connector(8443)。

在server.xml中配置SSL Connector

在默认server.xml中包括了一个SSL Connector的示例Connector元素。在默认情况下这个Connector元素是注释掉的。要为Tomcat启用SSL Connector，去掉围绕着SSL Connector元素的注释标记。为此，执行以下步骤。

1.     如果Tomcat正在运行，则关闭它。当Tomcat再次启动时对<JWSDP_HOME>/conf/server.xml文件的修改就可被它使用了。

2.     在文本编辑器中打开文件<JWSDP_HOME>/conf/server.xml。

3.     在文件中找到下代码部分(可以试着搜索SSL Connector)。删除围绕Connector项的注释。要删除的注释标签以粗体表示。

  <!-- SSL Connector on Port 8443 -->

<!--
    <Connector
      className="org.apache.coyote.tomcat4.CoyoteConnector"
      port="8443" minProcessors="5"
      maxProcessors="75"
      enableLookups="false"
      acceptCount="10"
      connectionTimeout="60000" debug="0"
      scheme="https" secure="true">
    <Factory
      className="org.apache.coyote.tomcat4.
             CoyoteServerSocketFactory"
             clientAuth="false" protocol="TLS" />
    </Connector>
  -->

4.     保存并关闭文件。

5.     启动Tomcat。

在Tomcat管理工具文档中对这个Connector元素中的属性有更详细的描述。

验证SSL支持

为了进行测试，并验证SSL支持已经正确安装，用连接到在服务器部署描述符中定义的端口的URL装载默认的介绍页面：

https://localhost:8443/

这个URL中的https表明浏览器应该使用SSL协议。端口8443就是在前面一步中创建SSL Connector的端口

用户第一次装载这个应用程序时，会显示New Site Certificate对话框。选择Next通过一系列New Site Certificate对话框，到达最后一个对话框时，选择Finish。

有关运行SSL的一般性提示

SSL协议设计为尽可能地高效和安全。不过，从性能的角度看，加密/解密是一种需要大量计算的过程。不一定要将整个Web应用都放到SSL上，并且一般由开发者决定哪一页面需要安全连接，哪一页面不需要。可能需要安全连接的页面包括登录页面、个人信息页面、购物小车付款、或者任何其他可能传送信用卡号的页面。可以仅通过加在地址上用https个取代http前缀而使应用程序中的任何一页面运行在安全套接字上。对任何绝对要求安全连接的页面都应该检查与该页面请求相关联的协议类型，如果没有指定https就要采取相应措施。

使用在安全连接上的基于名字的虚拟主机可能会有问题。这是SSL协议本身的一个设计局限。SSL握手必须在访问HTTP请求之前发生，在握手时客户端浏览器接受服务器证书。结果，不能在身份验证之前确定包含虚拟主机名的请求信息，并且因此不可能对一个IP地址指定多个证书。如果在一个IP地址上的所有虚拟主机需要针对同一个证书进行验证，那么额外的多个虚拟主机就不应该介入服务器上的普通SSL操作。不过要知道，大多数客户端浏览器会比较服务器的域名和在证书中列出的域名，如果有列出的话(主要适用于正式的、CA签名的证书)。如果域名不匹配，那么这些浏览器将向客户端显示一个警告。一般来说，在生产环境中只有基于地址的虚拟主机通常会使用SSL。

SSL连接的故障排除

启动Tomcat时，得到这样的异常“"java.io.FileNotFoundException: {some-directory}/{some-file} not found”

一个可能的解释是Tomcat不能找到它要寻找的keystore文件。在默认情况下，Tomcat期待keystore命名为.keystore，并且位于Tomcat所在的系统中的home目录(与您自己的计算机上的home目录可能一致、也可能不一致) 。如果keystore文件是在其他位置，那么就需要在Tomcat配置文件中的<Factory>元素上添加一个keystoreFile属性，或者在admintool的Connector (8443)节点指定文件的位置。

Tomcat启动时，得到这样的异常“"java.io.FileNotFoundException: Keystore was tampered with, or password was incorrect”。

假设没有人改变了您的keystore文件，最有可能的原因是Tomcat使用了与创建keystore文件时使用的不同的密码。要解决这个问题，可以返回并重新创建keystore文件，也可以在Tomcat配置文件中的<Factory>元素上、或者在的Connector (8443)节点上添加keystorePass属性——提醒--密码是大小写敏感的。

如果仍然有问题，

如果仍然有问题，邮件列表是一个好的信息资源。可以在http://jakarta.apache.org/site/mail.html上查看这个列表中以前的消息，还可以预订和取消预订信息。

有关SSL的进一步信息

更多信息请参阅<JWSDP_HOME>/docs/tomcat/ssl-howto.html上的Tomcat文档SSL Configuration HOW-TO。

JAX-RPC的安全性

在本节，将学习如何配置基于JAX-RPC的Web服务应用程序以进行HTTP/SSL上的基本和相互身份验证。如果验证对于您来说还是一个新题目，那么请参见验证Web资源的用户那一节。

在本教程中，我们要修改<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/hello中的示例应用程序以添加HTTP/S基本和相互身份验证。可以在目录<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security中找到所得到的应用程序。下列步骤是向hello例子中添加基本验证的必要步骤：

·  创建相应的证书和keystore(参见第1步：为基本身份验证创建SSL证书)。

·  确保为服务器配置了SSL 连接器。Tomcat服务器没有配置SSL Connector，所以需要添加SSL Connector(参见配置SSL连接器)并在生成的keystore文件中添加信息(见第2步：配置SSL 连接器)。

·  .向部署描述符web.xml添加安全元素。有关操作信息参见第3步：向web.xml添加安全元素。

·  在应用程序的build.properties文件中修改端点地址，并添加运行这个例子所需要的其他属性。参见第4步：编辑Build属性。

·  在客户端代码中设置安全属性。有关操作信息参见第5步：在客户端代码中设置安全属性。

·  编译并运行Web服务。有关对示例应用程序完成这项操作的信息见第6步：创建NewAnt Target以运行这个例子。

在这里描述为Web服务配置HTTP/S上的基本身份验证的步骤。对于相互身份验证，完成下述步骤，再按启用SSL上的相互验证中的说明添加客户端验证。

第1步：为基本身份验证创建SSL证书

注：在设置数字证书中对这些信息有更详细的讨论。本节总结了为这个例子创建SSL证书所需要的步骤。

我们将用工具keytool生成SSL证书并将它们导出为相应的服务器和客户端keystore。记住服务器和客户端keystore是在运行keytool的目录中创建的。因为我们是向hello Web服务添加安全性，所以我们从修改的示例应用程序所在目录中运行keytool，这就是<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security目录。这样，keystore就在security Web服务的代码所在的同一目录中生成。

1.     运行keytool以生成服务器和客户端keystore。对于基本身份验证，只需要将服务器证书导入到客户端keystore。用默认密码changeit生成服务器keystore。

要生成服务keystore，在终端窗口输入下面内容。在继续之前确是在<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security目录中。

注意在按Enter时，keytool提示您输入服务器名、组织单位、组织、所在地、州和国家代码。注意必须在keytool的要求输入姓和名的第一个提示中输入服务器名。为了进行测试，可以用localhost。这个主机必须与在第4步：编辑Build属性中指定的端点地址中标识的主机相匹配。

<J2SE_HOME>\bin\keytool -genkey
-alias tomcat-server
-keyalg RSA -keypass changeit
-storepass changeit
-keystore server.keystore

2.     导出生成的服务器证书。

<J2SE_HOME>\bin\keytool -export -alias tomcat-server
-storepass changeit -file server.cer -keystore
server.keystore

3.     生成客户端keystore。

要生成客户端keystore，在终端窗口中输入以下内容：

注意在按Enter时，keytool提示您输入客户端的服务器名、组织单位、组织、所在地、州和国家代码。注意必须在keytool的要求输入姓和名的第一个提示中输入服务器名。在大多数情况下，为了进行测试，可以使用localhost。这个主机必须与在第4步：编辑Build属性中指定的端点地址中标识的主机相匹配。

<J2SE_HOME>\bin\keytool -genkey -alias jwsdp-client -keyalg
RSA -keypass changeit -storepass changeit -keystore
client.keystore

4.     将服务器证书导入客户端的keystore。

<J2SE_HOME>\bin\keytool -import -v -trustcacerts
-alias tomcat-server -file server.cer
-keystore client.keystore -keypass changeit
-storepass changeit

第2步：配置SSL连接器

注：在配置SSL 连接器一节中更详细地提供了配置SSL 连接器的步骤。本节中的步骤是为了您的方便提供的。

需要为Tomcat配置一个SSL Connector。如果使用不同的服务器，参见配置SSL 连接器中配置SSL Connector的一般信息。除了为服务配置一个SSL 连接器外，还必须在添加SSL连接器的同一位置上添加有关keystore文件的信息及其密码。例如，在Java WSDP中，首先需要从SSL Connector周围删除注释标签(<!-- ... -->)，然后在<JWSDP_HOME>/conf/server.xml文件中的这一部分添加以粗体显示的信息。

<!-- SSL Connector on Port 8443 -->
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
    port="8443" minProcessors="5" maxProcessors="75"
    enableLookups="false"
    acceptCount="10" debug="0" scheme="https" secure="true">
<Factory className= "org.apache.coyote.tomcat4.CoyoteServerSocketFactory">
keystoreFile=
  "<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security/      server.keystore"
    keystorePass="changeit"
    clientAuth="false" protocol="TLS" debug="0" />
</Connector> 

第3步：向web.xml添加安全元素

这个例子的文件在<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security目录中。要通过SSL进行身份验证，web.xml文件包括<security-constraint>、 <login-config>,和<security-role>元素。在基本<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/hello例子之上添加了粗体的代码。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
    2.3//EN"
    "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">

  <web-app>
  <display-name>Hello World Application (secure)</display-name>
  <description>HTTPS example using JAX-RPC </description>
  <session-config>
    <session-timeout>60</session-timeout>
  </session-config>
 <security-constraint>
    <web-resource-collection>
      <web-resource-name>SecureHello</web-resource-name>
      <url-pattern>/security</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
      <role-name>manager</role-name>
    </auth-constraint>
    <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
  </security-constraint>
  <login-config>
    <auth-method>BASIC</auth-method>
  </login-config>
  <security-role>
    <role-name>manager</role-name>
  </security-role>
</web-app>

注意<role-name>元素指定了manager，这是一个已经在Tomcat的部署描述符(<JWSDP_HOME>/conf/tomcat-users.xml)中指定的角色。有关角色定义和链接的更多内容，参见安全性角色。

第4步：编辑Build属性

要以HTTP/SSL上的基本身份验证运行这个应用程序，我们向build.properties文件添加与keystore文件相关的一些属性及其密码，这个文件位于<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security目录中。下述例子假设运行的是Java WSDP 1.1。以粗体标记的项被添加到文件中。在后面一节中运行它时，所添加的项将作为参数传递给客户端应用程序。

# This file is referenced by the build.xml file.

  example=security
context-path=security-jaxrpc

  client-class=security.HelloClient
client-jar=${example}-client.jar
  portable-war=${example}-portable.war
deployable-war=${context-path}.war war-path=${tut- root}/tutorial/examples/jaxrpc/${example}/dist/${deployable- war}

  trust-store=${tut-root}/tutorial/examples/jaxrpc/security/cli-
ent.keystore
  trust-store-password=changeit

第5步：在客户端代码中设置安全属性

客户端的源代码在<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security目录中的HelloClient.java文件中。对于SSL上的基本身份验证，客户端代码必须设置几项安全相关的属性。

·   trust-store属性——trust-store属性的值是客户端 keystore文件的完全限定名：<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security/client.keystore

·  trust-store-password属性——trust-store-password属性是keystore的密码。这个密码的默认值是changeit。

·  username和 password属性——username和password属性对应于manager角色(见安全性角色)。

客户端如下设置前述的安全属性。粗体的代码是在原来的jaxrpc/hello示例应用程序上添加的代码。

package security;   import javax.xml.rpc.Stub;

public class HelloClient {

public static void main(String[] args) {

          if (args.length !=4) {
          System.out.println("Usage: ant run-security");          System.exit(1);        }

         String trustStore=args[0];
        String trustStorePassword=args[1];        String username=args[2];        String password=args[3];
          System.out.println("trustStore: " + trustStore);         System.out.println("trustStorePassword: " +
        trustStorePassword);
        System.out.println("username: " + username);
        System.out.println("password: " + password);

      try {
      Stub stub = createProxy();
      System.setProperty("javax.net.ssl.trustStore",        trustStore);
      System.setProperty("javax.net.ssl.trustStorePassword",        trustStorePassword);
    stub._setProperty(javax.xml.rpc.Stub.USERNAME_PROPERTY,
        username);
    stub._setProperty(javax.xml.rpc.Stub.PASSWORD_PROPERTY,        password);
      HelloIF hello = (HelloIF)stub;
      System.out.println(hello.sayHello("Duke! I feel
        secure!"));
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

          private static Stub createProxy() {
        // Note: MyHelloService_Impl is implementation-specific.
        return (Stub)(new MyHello_Impl().getHelloIFPort());
    }
}

第6 步：创建New Ant Target以运行这个例子

运行hello示例应用程序的现有目标还不足以运行运行安全版本的应用程序。需要传递关于keystore及其密码的信息，以及用户名及用户密码。下列targe添加到<JWSDP_HOME>/docs/examples/jaxrpc/security/build.xml文件中，以便于运行安全的JAX-RPC例子：

<target name="run-security"
     description="Runs a client with authentication
    over ssl">
     <echo message="Running the ${client-class} program...." />
    <java
      fork="on"
      classpath="${dist}/${client-jar}:${jwsdp-jars}"
      classname="${client-class}" >
      <arg value="${trust-store}" />
      <arg value="${trust-store-password}" />
      <arg value="${username}" />
      <arg value="${password}" />
    </java>
</target>

第7步：编译并运行这个例子

要编译并在SSL上运行这个JAX-RPC例子，执行以下步骤：

1.     如果没有做的话，按照设置中的指示，下载本教程的示例代码，完成上述第1到2步，因为这些步骤是对您的计算机和实现特定的。

2.     确保Tomcat正在运行。

3.     进入<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security目录。

4.     键入下述命令：

  ant build
  ant package
  ant deploy
  ant build-static
  ant run-security

客户端应该显示下述输出：

% ant run-security
Buildfile: build.xml

run-security:
[echo] Running the security.HelloClient program...
[java] trustStore: <JWSDP_HOME>/docs/tutorial/examples/
     jaxrpc/security/client.keystore
[java] trustStorePassword: changeit
[java] username: your_name
[java] password: your_password
[java] Hello - secure Duke! I feel secure!

BUILD SUCCESSFUL

启用SSL上的相互身份验证

TJAX-RPC安全性一节对设置服务器端身份验证进行了讨论。本节讨论设置客户端身份验证。当服务器和客户端身份验证都启用时，这称为相互、或者双向验证。在客户端身份验证中，客户端需要提交由你所选择的可以接受的证书颁发机构颁发的证书。至少有两种途径启用客户端身份验证。

1.     .配置SSL套接字工厂启用客户端验证。例如，要为Tomcat配置SSL套接字工厂 ，要设置clientAuth="true"，如下面代码示例中的粗体部分。以这种方式启用客户端验证，对于所有通过特定SSL端口进入的请求都会要求客户端验证。与对Web服务配置文件所做的所有改变一样，必须停止并重新启动Web服务以使这种改变生效。

<!-- SSL Connector on Port 8443 -->
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
    port="8443" minProcessors="5" maxProcessors="75"
    enableLookups="false"
    acceptCount="10" debug="0" scheme="https" secure="true">
<Factory className=
"org.apache.coyote.tomcat4.CoyoteServerSocketFactory">
keystoreFile=
  "<JWSDP_HOME>/docs/tutorial/examples/jaxrpc/security/
      server.keystore"
    keystorePass="changeit"
    clientAuth="true" protocol="TLS" debug="0" />
</Connector>

2.     如下面粗体部分所示。以这种方法启用客户端身份验证，客户端身份验证是对特定的应用程序启用的。

<login-config>
  <auth-method>CLIENT-CERT</auth-method>
</login-config>

3.     如果同时用上述两种方法启用客户端身份验证，那么客户端身份验证将会执行两次。

为JAX-RPC安全示例配置相互验证

要以相互验证配置并创建JAX-PRC服务，执行JAX-RPC安全性中的所有步骤，直到ant build-static命令 (包括这一步)。然后执行以下步骤：

1.     生成客户端证书，导出它，再将客户端证书导入服务器keystore，如为相互验证创建客户端证书中所讨论的。

2.     编辑web.xml以将部署描述符中的登录配置部分的身份验证方法改为CLIENT-CERT。

<login-config>
  <auth-method>CLIENT-CERT</auth-method>
</login-config>

3.     :运行这个应用程序：

ant run-security

客户端应该显示以下一行：

Hello Duke! I feel secure!

致谢：本节包括由Rahul Sharma和Beth Stearns编写的“Web Services Security Configuration”白皮书中的内容。

EIS层安全性

在EIS层，应用程序组件请求到EIS资源的连接。作为这种连接的一部分，EIS可能请求对资源的sign-on。应用程序组件提供者有两设计这种EIS sign-on的选择：

·  使用容器托管的sign-on方式，应用程序组件让容器负责配置并管理EIS sign-on。容器确定用户名和密码以建立到EIS实例的连接。

·  用组件托管的sign-on方式，应用程序组件代码通过加入执行sign-on过程的代码管理EIS sign-on。

容器托管的登录(Sign-On)

使用容器托管的登录，应用程序组件不必为了登录资源而向getConnection()方法传递任何安全信息。安全信息是由容器提供的，如下面的例子所示。

// Business method in an application
component Context initctx = new InitialContext();
// Perform JNDI lookup to obtain a connection factory javax.resource.cci.ConnectionFactory cxf =
     (javax.resource.cci.ConnectionFactory)initctx.lookup(
      "java:comp/env/eis/MainframeCxFactory");
// Invoke factory to obtain a connection. The security
// information is not passed in the getConnection method
javax.resource.cci.Connection cx = cxf.getConnection();
...

组件托管的登录

使用组件管理的登录，应用程序组件负责向getConnection()方法传递登录资源所需要的安全信息。安全信息可以是用户名和密码，如下例所示：

// Method in an application
component Context initctx = new InitialContext();
// Perform JNDI lookup to obtain a connection factory javax.resource.cci.ConnectionFactory cxf =
     (javax.resource.cci.ConnectionFactory)initctx.lookup(
       "java:comp/env/eis/MainframeCxFactory");
// Get a new ConnectionSpec
com.myeis.ConnectionSpecImpl properties = //..
// Invoke factory to obtain a connection
properties.setUserName("...");
properties.setPassword("...");
javax.resource.cci.Connection cx =
  cxf.getConnection(properties);
...