耶鲁CAS Single Sign On和Spring Acegi Security

时间 2020-08-05 标签耶鲁 cas single sign spring acegi security

耶鲁CAS Single Sign On- -

耶鲁大学开发的单点登陆（Single Sign On）系统称为CAS（Central Authentication Service），是一个独立于平台的，易于理解的开源软件，支持代理功能。Spring Framework的Acegi安全系统支持CAS，并提供了易于使用的方案。javascript

CAS的设计目标
       l、为多个Web应用提供单点登陆基础设施，同时能够为非Web应用但拥有Web前端的功能服务提供单点登陆的功能；
      2、简化应用认证用户身份的流程；
      3、将用户身份认证集中于单一的Web应用，让用户简化他们的密码管理，从而提升安全性；并且，当应用须要修改身份验证的业务逻辑时，不须要处处修改代码；php

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做为请求参数。java

       为了让讨论更加清楚，考虑下面的例子。假设用户在访问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个小时。）web

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="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则弃权。