耶鲁CAS Single Sign On- -
耶鲁大学开发的单点登录(Single Sign On)系统称为CAS(Central Authentication Service),是一个独立于平台的,易于理解的开源软件,支持代理功能。Spring Framework的Acegi安全系统支持CAS,并提供了易于使用的方案。
CAS的设计目标
l、为多个Web应用提供单点登录基础设施,同时可以为非Web应用但拥有Web前端的功能服务提供单点登录的功能;
2、简化应用认证用户身份的流程;
3、将用户身份认证集中于单一的Web应用,让用户简化他们的密码管理,从而提高安全性;而且,当应用需要修改身份验证的业务逻辑时,不需要到处修改代码;
CAS的设计和实现
CAS(Central Authentication Server)被设计成一个独立的Web应用。它目前的实现是运行在HTTPS服务器上的几个Java Servlet。通过三个URL来访问:Login URL,Validation URL和可选的Logout URL。下图是CAS的单点登录流程示意图:
为了使用CAS,Web应用重定向它的用户(或简单地创建一个超链接)到Login URL,例如https://secure.its.yale.edu/cas/servlet/login。用户也可以手工访问这个URL,如果希望预先验证会话。
Login URL处理初步的认证工作,它提示用户输入NetID和密码,并用Kerberos服务器校验它们是否匹配。为了接下来能自动重新验证用户身份,CAS也会试图给浏览器回送Cookie(浏览器关闭后会自动过期)。这个Cookie用于识别已经成功登录的用户身份。
使用这个可选的Cookie,CAS可以为用户实现对于多个Web应用单点登录的效果。这就是说,用户只需输入一次他的NetID和密码,即可访问任何使用CAS的资源服务。没有这个Cookie,当Web应用重定向用户到CAS时,用户每次都要输入NetID和密码。(用户也可以通过访问Logout URL,如https://secure.its.yale.edu/cas/servlet/logout,来要求CAS删除这个Cookie。)
为了处理初步的身份认证,CAS也记录了用户被重定向时访问的service。可以这样做是因为CAS要求重定向或链接用户到Login URL的Web应用提供一个service的标志符(在上图中记为serviceID)。如果验证成功,CAS创建一个位数很长的随机数(我们称之为ticket)。CAS把这个ticket和成功登录的用户以及用户要访问的service联系起来。例如,如果用户peon重定向自service S,CAS创建ticket T,这个ticket T允许peon访问service S。这个ticket是个一次性的凭证;它仅仅用于peon,仅仅用于service S,并且只能使用一次,使用之后马上会过期。
一旦完成了初步的身份验证,CAS重定向用户浏览器回到原来的Web应用URL。CAS之所以能记得原来的URL,是因为上面讨论的service ID作为一个"callback URL"。CAS重定向用户的浏览器回到原来的URL,并加上上面讨论的ticket作为请求参数。
为了让讨论更加清楚,考虑下面的例子。假设用户在访问http://www.yale.edu/tp之前需要验证身份,我们把用户从http://www.yale.edu/tp重定向到下面的Login URL:
https://secure.its.yale.edu/cas/servlet/login?service=http://www.yale.edu/tp/authenticate.jsp
JSP页面authenticate.jsp是网站资源的一部分。一旦完成了上面描述的初步身份验证,CAS用下面的URL重定向用户浏览器到这个JSP页面:
http://www.yale.edu/tp/authenticate.jsp?ticket=opaque-ticket-string
一旦收到请求,authenticate.jsp页面需要校验这个收到的ticket,它把tickect传送Validation URL(如http://secure.its.yale.edu/cas/servlet/validate)。authenticate.jsp页面需要使用JSSE向Validation URL发送请求并读取数据。当生成这个请求时,authenticate.jsp页面还需要把先前的service ID用service的参数名传送给Validation URL,例子如下:
http://secure.its.yale.edu/cas/servlet/validate?ticket=T&service=S
当CAS从Validation URL收到这个ticket,它检查自己内部数据库,看看是否保存过这个ticket。如果数据库有这个ticket,则进一步检查数据库中和ticket关联的service是否和刚收到的service相匹配。如果匹配,则向请求验证身份的应用URL返回NetID;否则拒绝验证这个请求。
Validation URL向请求身份验证的应用URL返回数据的方式很简单。CAS用text/plain的应答方式返回两行数据;第一行是yes或no,取决于ticket验证是否通过。如果ticket通过验证,第二行则是成功通过身份验证的用户的NetID。如果ticket没有通过验证,第二行为空。例子如下:
如果ticket通过验证,CAS立即删除该ticket,使它以后不能再使用。
当完成了身份验证的循环流程,Web应用无需知道用户的密码即可校验用户身份。此外,如果用户浏览器接受Cookie,它将保留一个可用于多次向CAS验证用户身份的Cookie,让用户以后不用再输入NetID和密码。(目前,这个用于身份验证的Cookie保留8个小时。)
Spring安全系统:Acegi Security
Acegi安全系统,是一个用于Spring Framework的安全框架,能够和目前流行的Web容器无缝集成。它使用了Spring的方式提供了安全和认证安全服务,包括使用Bean Context,拦截器和面向接口的编程方式。因此,Acegi安全系统能够轻松地适用于复杂的安全需求。
安全涉及到两个不同的概念,认证和授权。前者是关于确认用户是否确实是他们所宣称的身份。授权则是关于确认用户是否有允许执行一个特定的操作。
在Acegi安全系统中,需要被认证的用户,系统或代理称为"Principal"。Acegi安全系统和其他的安全系统不同,它并没有角色和用户组的概念。
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的例子:
<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>
上面的配置文件中,MethodSecurityInterceptor是AbstractSecurityInterceptor的一个实现类。它包含了两个管理器,authenticationManager和accessDecisionManager。这两者的配置如下:
<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>
准备工作做好了,现在我们来看看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则弃权。
<script src="http://diy.51.net/partner/inject3.php?rid=51000000" type="text/javascript"></script>