图 1 Acegi体系结构
SecurityContextHolder是框架级的容器,它保存着和所有用户关联SecurityContext实 例,SecurityContext承载着用户(也称认证主体)的身份信息的权限信息, AuthenticationManager、AccessDecisionManager将据此进行安全访问控制。 SecurityContext的认证主体安全信息在一个HTTP请求线程的多个调用之间是共享的(通过ThreadLocal),但它不能在多个请求之 间保持共享。为了解决这个问题,Acegi将认证主体安全信息缓存于HttpSession中,当用户请求一个受限的资源时,Acegi通过 HttpSessionContextIntegrationFilter将认证主体信息从HttpSession中加载到 SecurityContext实例中,认证主体关联的SecurityContext实例保存在Acegi容器级的 SecurityContextHolder里。当请求结束之后,HttpSessionContextIntegrationFilter执行相反的操 作,将SecurityContext中的认证主体安全信息重新转存到HttpSession中,然后从SecurityContextHolder中清 除对应的SecurityContext实例。通过HttpSession转存机制,用户的安全信息就可以在多个HTTP请求间共享,同时保证 SecurityContextHolder中仅保存当前有用的用户安全信息,其整体过程如图 2所示:
图 2 SecurityContext在HttpSession和请求线程间的转交过程
当用户请求一个受限的资源时,AuthenticationManager首先开始工作,它象一个安检入口,对用户身份进行核查,用户必须提供身份认证的 凭证(一般是用户名/密码)。在进行身份认证时,AuthenticationManager将身份认证的工作委托给多个 AuthenticationProvider。因为在具体的系统中,用户身份可能存储在不同的用户信息安全系统中(如数据库、CA中心、LDAP服务 器),不同用户信息安全系统需要不同的AuthenticationProvider执行诸如用户信息查询、用户身份判断、用户授权信息获取等工作。只要 有一个AuthenticationProvider可以识别用户的身份,AuthenticationManager就通过用户身份认证,并将用户的授 权信息放入到SecurityContext中。 当用户通过身份认证后,试图访问某个受限的程序资源时,AccessDecisionManager开始工作。 AccessDecisionManager采用民主决策机制判断用户是否有权访问目标程序资源,它包含了多个AccessDecisionVoter。 在访问决策时每个AccessDecisionVoter都拥有投票权,AccessDecisionManager统计投票结果,并按照某种决策方式根 据这些投票结果决定最终是否向用户开放受限资源的访问。
重要组件类介绍 每个框架都有一些核心的概念,这些概念被固化为类和接口,成为框架的重要组件类。框架的管理类、操作类都在这些组件类的基础上进行操作。在进入Acegi框架的具体学习前,有必要事先了解一下这些承载Acegi框架重要概念的组件类。 首先,我们要接触是UserDetails接口,它代表一个应用系统的用户,该接口定义了用户安全相关的信息,如用户名/密码,用户是否有效等信息,你可以根据以下接口方法进行相关信息的获取: String getUsername():获取用户名; String getPassword():获取密码; boolean isAccountNonExpired():用户帐号是否过期; boolean isAccountNonLocked():用户帐号是否锁定; boolean isCredentialsNonExpired():用户的凭证是否过期; boolean isEnabled():用户是否处于激活状态。 当以上任何一个判断用户状态的方法都返回false时,用户凭证就被视为无效。 UserDetails还定义了获取用户权限信息的方法:GrantedAuthority[] getAuthorities(),GrantedAuthority代表用户权限信息,它定义了一个获取权限描述信息(以字符串表示,如 PRIV_COMMON)的方法:String getAuthority()。
图 3 用户和权限
在未使用Acegi之前,我们可能通过类似User、Customer等领域对象表示用户的概念,并在程序中编写相应的用户认证的逻辑。现在,你要做的一 个调整是让原先这些代表用户概念的领域类实现UserDetails接口,这样,Acegi就可以通过UserDetails接口访问到用户的信息了。 UserDetails可能从数据库、LDAP等用户信息资源中返回,这要求有一种机制来完成这项工作,UserDetailsService正是充当这 一角色的接口。UserDetailsService接口很简单,仅有一个方法:UserDetails loadUserByUsername(String username) ,这个方法通过用户名获取整个UserDetails对象。 Authentication代表一个和应用程序交互的待认证用户,Acegi从类似于登录页面、Cookie等处获取待认证的用户信息(一般是用户名密码)自动构造Authentication实例。
图 4 Acegi的认证用户
Authentication可以通过Object getPrincipal()获取一个代表用户的对象,这个对象一般可以转换为UserDetails,从中可以取得用户名/密码等信息。在 Authentication被AuthenticationManager认证之前,没有任何权限的信息。在通过认证之后,Acegi通过 UserDetails将用户对应的权限信息加载到Authentication中。Authentication拥有一个 GrantedAuthority[] getAuthorities()方法,通过该方法可以得到用户对应的权限信息。 Authentication和UserDetails很容易被混淆,因为两者都有用户名/密码及权限的信息,接口方法也很类似。其实 Authentication是Acegi进行安全访问控制真正使用的用户安全信息的对象,它拥有两个状态:未认证和已认证。UserDetails是代 表一个从用户安全信息源(数据库、LDAP服务器、CA中心)返回的真正用户,Acegi需要将未认证的Authentication和代表真实用户的 UserDetails进行匹配比较,通过匹配比较(简单的情况下是用户名/密码是否一致)后,Acegi将UserDetails中的其它安全信息(如 权限、ACL等)拷贝到Authentication中。这样,Acegi安全控制组件在后续的安全访问控制中只和Authentication进行交 互。
由于Acegi对程序资源进行访问安全控制时,一定要事先获取和请求用户对应的Authentication,Acegi框架必须为Authentication提供一个“寓所”,以便在需要时直接从“寓所”把它请出来,作为各种安全管理器决策的依据。 SecurityContextHolder就是Authentication容身的“寓所”,你可以通过 SecurityContextHolder.getContext().getAuthenication()代码获取Authentication。 细心观察一下这句代码,你会发现在SecurityContextHolder和Authentication之间存在一个getContext()中 介,这个方法返回SecurityContext对象。SecurityContext这个半路杀出来的程咬金有什么特殊的用途呢?我们知道 Authentication是用户安全相关的信息,请求线程其它信息(如登录验证码等)则放置在SecurityContext中,构成了一个完整的安 全信息上下文。SecurityContext接口提供了获取和设置Authentication的方法: Authentication getAuthentication() void setAuthentication(Authentication authentication)
图 5 认证用户信息存储器
SecurityContextHolder是Acegi框架级的对象,它在内部通过ThreadLocal为请求线程提供线程绑定的 SecurityContext对象。这样,任何参与当前请求线程的Acegi安全管理组件、业务服务对象等都可以直接通过 SecurityContextHolder.getContext()获取线程绑定的SecurityContext,避免通过方法入参的方式获取用户 相关的SecurityContext。 线程绑定模式对于大多数应用来说是适合的,但是应用本身会创建其它的线程,那么只有主线程可以获得线程绑定SecurityContext,而主线程衍生 出的新线程则无法得到线程绑定的SecurityContext。Acegi考虑到了这些不同应用情况,提供了三种绑定SecurityContext的 模式: SecurityContextHolder.MODE_THREADLOCAL:SecurityContext绑定到主线程,这是默认的模式; SecurityContextHolder.MODE_GLOBAL:SecurityContext绑定到JVM中,所有线程都使用同一个SecurityContext; SecurityContextHolder.MODE_INHERITABLETHREADLOCAL::SecurityContext绑定到主线程及由主线程衍生的线程中。 你可以通过SecurityContextHolder.setStrategyName(String strategyName)方法指定SecurityContext的绑定模式。