ACEGI安全框架应用指南.doc

ACEGI安全框架应用指南级别: 中级何平 系统架构师，独立顾问，培训讲师。2005 年 12 月 26 日文章来源于一次acegi的项目应用。因为业务需要与acegi框架缺省的应用方式有一定的区别，故在实际应用过程中尝试了对acegi的一定量的改造工作，从而具有一定的研究和学习价值。文章中关于Acegi的介绍收入了其他文章中的内容，已在参教资料中列出资料来源。内容大纲： 认识Acegi安全框架 安装并运行Acegi自带的范例 改造Acegi框架满足我们的业务要求具体内容：n 认识Acegi安全框架Acegi安全系统，是一个用于Spring Framework的安全框架，能够和目前流行的Web容器无缝集成。它使用了Spring的方式提供了安全和认证安全服务，包括使用Bean Context，拦截器和面向接口的编程方式。因此，Acegi安全系统能够轻松地适用于复杂的安全需求。安全涉及到两个不同的概念，认证和授权。前者是关于确认用户是否确实是他们所宣称的身份。授权则是关于确认用户是否有允许执行一个特定的操作。在Acegi安全系统中，需要被认证的用户，系统或代理称为Principal。Acegi安全系统和其他的安全系统不同，它并没有角色和用户组的概念 关键组件Acegi安全系统包含以下七个关键的功能组件：l Authentication对象，包含了Principal，Credential和Principal的授权信息。同时还可以包含关于发起认证请求的客户的其他信息，如IP地址。 2 ContextHolder对象，使用ThreadLocal储存Authentication对象的地方。 3 AuthenticationManager，用于认证ContextHolder中的Authentication对象。 4 AccessDecissionManager，用于授权一个特定的操作。 5 RunAsManager，当执行特定的操作时，用于选择性地替换Authentication对象。 6 Secure Object拦截器，用于协调AuthenticationManager，AccessDecissionManager，RunAsManager和特定操作的执行。7 ObjectDefinitionSource，包含了特定操作的授权定义。这七个关键的功能组件的关系如下图所示（图中灰色部分是关键组件）： 安全管理对象Acegi安全系统目前支持两类安全管理对象。 第一类的安全管理对象管理AOP Alliance的MethodInvocation，开发人员可以用它来保护Spring容器中的业务对象。为了使Spring管理的Bean可以作为MethodInvocation来使用，Bean可以通过ProxyFactoryBean和BeanNameAutoProxyCreator来管理，就像在Spring的事务管理一样使用。 第二类是FilterInvocation。它用过滤器（Filter）来创建，并简单地包装了HTTP的ServletRequest，ServletResponse和FilterChain。FilterInvocation可以用来保护HTTP资源。通常，开发人员并不需要了解它的工作机制，因为他们只需要将Filter加入web.xml，Acegi安全系统就可以工作了。 安全配置参数每个安全管理对象都可以描述数量不限的各种安全认证请求。例如，MethodInvocation对象可以描述带有任意参数的任意方法的调用，而FilterInvocation可以描述任意的HTTP URL。 Acegi安全系统需要记录应用于每个认证请求的安全配置参数。例如，对于BankManager.getBalance（int accountNumber）方法和BankManager.approveLoan（int applicationNumber）方法，它们需要的认证请求的安全配置很不相同。 为了保存不同的认证请求的安全配置，需要使用配置参数。从实现的视角来看，配置参数使用ConfigAttribute接口来表示。Acegi安全系统提供了ConfigAttribute接口的一个实现，SecurityConfig，它把配置参数保存为一个字符串。 ConfigAttributeDefinition类是ConfigAttribute对象的一个简单的容器，它保存了和特定请求相关的ConfigAttribute的集合。 当安全拦截器收到一个安全认证请求时，需要决定应用哪一个配置参数。换句话说，它需要找出应用于这个请求的ConfigAttributeDefinition对象。这个查找的过程是由ObjectDefinitionSource接口来处理的。这个接口的主要方法是public ConfigAttributeDefinition getAttributes(Object object)，其中Object参数是一个安全管理对象。因为安全管理对象包含有认证请求的详细信息，所以ObjectDefinitionSource接口的实现类可以从中获得所需的详细信息，以查找相关的ConfigAttributeDefiniton对象。 Acegi如何工作为了说明Acegi安全系统如何工作，我们设想一个使用Acegi的例子。通常，一个安全系统需要发挥作用，它必须完成以下的工作： l 首先，系统从客户端请求中获得Principal和Credential； 2 然后系统认证Principal和Credential信息； 3 如果认证通过，系统取出Principal的授权信息； 4 接下来，客户端发起操作请求； 5 系统根据预先配置的参数检查Principal对于该操作的授权；6 如果授权检查通过则执行操作，否则拒绝。那么，Acegi安全系统是如何完成这些工作的呢？首先，我们来看看Acegi安全系统的认证和授权的相关类图：图中绿色部分是安全拦截器的抽象基类，它包含有两个管理类，AuthenticationManager和AccessDecisionManager，如图中灰色部分。AuthenticationManager用于认证ContextHolder中的Authentication对象（包含了Principal，Credential和Principal的授权信息）；AccessDecissionManager则用于授权一个特定的操作。下面来看一个MethodSecurityInterceptor的例子： true net.sf.acegisecurity.context.BankManager.delete*= ROLE_SUPERVISOR,RUN_AS_SERVERnet.sf.acegisecurity.context.BankManager.getBalance= ROLE_TELLER,ROLE_SUPERVISOR,BANKSECURITY_CUSTOMER,RUN_ 上面的配置文件中，MethodSecurityInterceptor是AbstractSecurityInterceptor的一个实现类。它包含了两个管理器，authenticationManager和accessDecisionManager。这两者的配置如下： false 准备工作做好了，现在我们来看看Acegi安全系统是如何实现认证和授权机制的。以使用HTTP BASIC认证的应用为例子，它包括下面的步骤：1. 用户登录系统，Acegi从acegisecurity.ui子系统的安全拦截器（如BasicProcessingFilter）中得到用户的登录信息（包括Principal和Credential）并放入Authentication对象，并保存在ContextHolder对象中；2. 安全拦截器将Authentication对象交给AuthenticationManager进行身份认证，如果认证通过，返回带有Principal授权信息的Authentication对象。此时ContextHolder对象的Authentication对象已拥有Principal的详细信息； 3. 用户登录成功后，继续进行业务操作；4. 安全拦截器（bankManagerSecurity）收到客户端操作请求后，将操作请求的数据包装成安全管理对象（FilterInvocation或MethodInvocation对象）；5. 然后，从配置文件（ObjectDefinitionSource）中读出相关的安全配置参数ConfigAttributeDefinition；6. 接着，安全拦截器取出ContextHolder中的Authentication对象，把它传递给AuthenticationManager进行身份认证，并用返回值更新ContextHolder的Authentication对象；7. 将Authentication对象，ConfigAttributeDefinition对象和安全管理对象（secure Object）交给AccessDecisionManager，检查Principal的操作授权； 8. 如果授权检查通过则执行客户端请求的操作，否则拒绝； AccessDecisionVoter注意上节的accessDecisionManager是一个AffirmativeBased类，它对于用户授权的投票策略，只要通过其中的一个授权投票检查，即可通过；它的allowIfAllAbstainDecisions属性值是false，意思是如果所有的授权投票是都是弃权，则通不过授权检查。Acegi安全系统包括了几个基于投票策略的AccessDecisionManager，上节的RoleVoter就是其中的一个投票策略实现，它是AccessDecisionVoter的一个子类。AccessDecisionVoter的具体实现类通过投票来进行授权决策，AccessDecisionManager则根据投票结果来决定是通过授权检查，还是抛出AccessDeniedException例外。 AccessDecisionVoter接口共有三个方法：public int vote(Authentication authentication, Object object, ConfigAttributeDefinition config);public boolean supports(ConfigAttribute attribute);public boolean supports(Class clazz);其中的vote方法返回int返回值，它们是AccessDecisionVoter的三个静态成员属性：ACCESS_ABSTAIN,，ACCESS_DENIED和ACCESS_GRANTED，它们分别是弃权，否决和赞成。Acegi安全系统中，使用投票策略的AccessDecisionManager共有三个具体实现类：AffirmativeBased、ConsensusBased和UnanimousBased。它们的投票策略是，AffirmativeBased类只需有一个投票赞成即可通过；ConsensusBased类需要大多数投票赞成即可通过；而UnanimousBased类需要所有的投票赞成才能通过。RoleVoter类是一个Acegi安全系统AccessDecisionVoter接口的实现。如果ConfigAttribute以ROLE_开头，RoleVoter则进行投票。如果GrantedAuthority的getAutority方法的String返回值匹配一个或多个以ROLE_开头的ConfigAttribute，则投票通过，否则不通过。如果没有以ROLE_开头的ConfigAttribute，RoleVoter则弃权。 小结到这里，我想各位对于Acegi安全框架的实现原理和运行机制已经有了较清楚的认识。下一步我们就理论联系实践来感觉一下Acegi给我们带来乐趣。n 安装并运行acegi自带的范例为了让大家对acegi有一个感性的认识，下面我们一起来安装Acegi自带的demo，并运行它，亲身感觉Acegi都为我们带来了些什么。 需要的软件Acegi 0.83版本注意，目前Acegi的发布版本还不是很稳定，如果大家要运行我后面提供的范列，最好是下载这个版本的。下载地址：/sourceforge/acegisecurity/acegi-security-0.8.3.zip因为我们还需求分析它的源码，所以最好也下之/sourceforge/acegisecurity/acegi-security-0.8.3-src.zipTomcat 5.5下载地址:/download-55.cgiJ2SE5.0下载地址：/j2se/1.5.0/download.jsp 安装范例1. 安装tomcat到合适的位置2. 解压acegi-security-0.8.3.zip，目录展开如下： 图中选中的文件就是我们将安装的demo。3. 将acegi-security-sample-contacts-filter.war复制到tomcat/webapps目录下4. 启动tomcat5. 通过地址：http:/localhost:8080/acegi-security-sample-contacts-filter访问demo界面如下：6. 打开上面的页面后，大家就可以亲身去体验Acegi为我们来了什么。 提示其实只要好好研究一下这个demo中对于Acegi的用法，基本上就可以掌握Acegi了。一起加油吧。n 改造Acegi框架满足我们的业务要求 我们的Acegi的范例在前面介绍Acegi时，我们举例说明了Acegi是如何做到对业务对象的访问控制的。在更多的时候，对于Web应用程序还要控制页面的访问。而我们的业务要求就是这样的简单，根据不同的角色决定它能访问哪些页面和哪些对象的哪些方法。目前暂时不考虑具体角色的具体权限指派，关于这部分内容大家可以通过研究demo获得相应的知识。因为是举例说明Acegi的用法，现假设我们的web工程名为myacegi，其目录结构如下： 其中的secure目录下的文件就是我们希望受控制的页面。 src目录是我们的java源程序。 acegilogin.jsp是我们的登录界面。 logoff.jsp是我们的登出页面。 test.jsp页面中有我们对受控业务对象的受控方法的访问举例。WEB-INF目录下的目录结构如下： classes和lib目录就不再解释了 applicationContext-common-business.xml配置了例子中要使用的数据源 applicationContext-acegi-security.xml配置了例子中关于安全方面的内容 applicationContext-common-authorization.xml配置了例子中关于授权方面的内容 web.xml当然就是整个web应用的配置了。我们在这里先详细说明一下web.xml文件，其它的配置文件的内容将在后面的改造过程中不断深入web.xml文件内容如下： myacegi example contextConfigLocation /WEB-INF/applicationContext-acegi-security.xml /WEB-INF/applicationContext-common-business.xml /WEB-INF/applicationContext-common-authorization.xml Acegi Filter Chain Proxy net.sf.acegisecurity.util.FilterToBeanProxy targetClass net.sf.acegisecurity.util.FilterChainProxy Acegi Filter Chain Proxy /* org.springframework.web.context.ContextLoaderListener net.sf.acegisecurity.ui.session.HttpSessionEventPublisher index.html /spring /WEB-INF/spring.tld 在上面的配置中，我只说明与Acegi有直接关系的部分1. 定义了一个应用程序域的变量contextConfigLocation contextConfigLocation /WEB-INF/applicationContext-acegi-security.xml /WEB-INF/applicationContext-common-business.xml /WEB-INF/applicationContext-common-authorization.xml 这里列出了我们希望Spring框架(Acegi中已经自带的Spring)加载的关于Acegi的配置文件。2. 定义了一个过滤器Acegi Filter Chain Proxy, Acegi Filter Chain Proxy net.sf.acegisecurity.util.FilterToBeanProxy targetClass net.sf.acegisecurity.util.FilterChainProxy Acegi Filter Chain Proxy /* 这样的配置表时，当前web应用中的所用url的请求访问都会被这个过滤器捕获，也就是说，Acegi的页面控制其实和我们平时的开发一样，也是通过过滤器来实现的。3. 定义了两个监听器 org.springframework.web.context.ContextLoaderListener net.sf.acegisecurity.ui.session.HttpSessionEventPublisher 第一个是用来动态加载我们前面定义的应用程序域的变量contextConfigLocation中所列出的配置文件的，第二个是Acegi内部需求使用的事件发布器，我们不需求太多关心它的实现和用法，就这样放着吧。总的来说，这个工程本身也是以demo程序作为样板来建立的。 想了解更多信息，建议下载范例代码。 改造schema通过Acegi的demo演示大家可以看到，它所提供的缺省用户验证办法是依据的用户名和登录密码，而对于授权访问方面是根据用户所付于的角色来进行判断的。但在我们的业务系统中，用户验证则有所不同。单位号、用户ID和登录密码三者放在一起才能验证一个用户。同样对于用户角色的查询办法也得变成以单位号加用户ID为条件。我们先来看看Acegi所提供的demo的表结构和表间关系。 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 ); CREATE TABLE acl_object_identity ( id BIGINT GENERATED BY DEFAULT AS IDENTITY(START WITH 0) NOT NULL PRIMARY KEY, object_identity VARCHAR_IGNORECASE(250) NOT NULL, parent_object BIGINT, 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 BIGINT GENERATED BY DEFAULT AS IDENTITY(START WITH 0) NOT NULL PRIMARY KEY acl_object_identity BIGINT 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) ); 注意：以上sql语句来源于Acegi网站，应用于hsql。网页地址：/dbinit.txt 通过上面的schema可以看出Acegi是如何管理用户和进行授权的。也就是说，如果要让其满足我们前面所提出的业务要求，第一步从schema这块就得进行改造。 我们业务上的实际要求很简单，还没有涉及到对象的方法访问的权限问题，只是想根据用户的角色来控制其页面和业务方法的调用。从而得到我们所需要的schema。 CREATE TABLE dbo.USERS (DWH varchar(2) NOT NULL, USER_ID varchar(5) NOT NULL, USER_NAME varchar(20) , ENABLED v