代码改变世界

在多点环境下使用cas实现单点登陆及登出

2013-08-26 17:32  御云  阅读(6497)  评论(0编辑  收藏  举报

CAS 介绍

CAS 是 Yale 大学发起的一个开源项目,旨在为 Web 应用系统提供一种可靠的单点登录方法,CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点:

  • 开源的企业级单点登录解决方案。
  • CAS Server 为需要独立部署的 Web 应用。
  • CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用),包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

CAS 原理和协议

从结构上看,CAS 包含两个部分: CAS Server 和 CAS Client。CAS Server 需要独立部署,主要负责对用户的认证工作;CAS Client 负责处理对客户端受保护资源的访问请求,需要登录时,重定向到 CAS Server。下图 是 CAS 最基本的协议过程:

在图中第3步用户认证成功后,cas server会生成Ticket Granting Ticket(票据授权票据,简称TGT),同时将TGT值以CASTGC为名保存到浏览器的cookie中,之后生成Service Ticket(服务票据,简称ST)并缓存,在第4步时将ST通过浏览器重定向的URL传给cas client。

当cas client验证ST时,是在后台请求cas server验证ST,而cas server在已缓存的ST中查找是否存在cas client传来的ST,若存在则返回验证成功同时将该ST删除(这就保证了用同一ST不能反复进入client应用,同时这也是为什么不直接将TGT返回给cas client的原因)。

那么名为CASTGC的cookie起什么作用呢?

当客户访问另一个cas client时,同样会被重定向到cas server,而此时我们并不希望再次让用户输入用户密码登陆,名为CASTGC的cookie这时就体现出作用来了,cas server发现存在名为CASTGC的cookie就将其值在已保存的TGT中查找,若存在,则说明已存在合法的TGT,cas server就根据该TGT生成新的ST,接下来的流程就和以前一样了。

CAS 协议中还提供了 Proxy (代理)模式,以适应更加高级、复杂的应用场景,具体介绍可以参考 CAS 官方网站上的相关文档。

在多点环境下使用CAS

虽然cas是作为开源单点登录解决方案的一个不错选择,但是官方提供的缺省实现代码却不并支持cas server多点部署以及每个cas client多点部署的情况。这在现今越来越强调服务稳定性的潮流下,多少显得有些不合时宜。那么是不是服务是多点部署就不能使用cas了呢?答案是否定的。

多点部署cas server

对cas server来说,默认实现不能支持多点部署的原因在于TGT保存时使用的ticket register类将TGT保存在了Java类的变量中。相关配置如下:

WEB-INF\spring-configuration\ticketRegistry.xml:

<bean id="ticketRegistry" class="org.jasig.cas.ticket.registry.DefaultTicketRegistry" />

如果要支持多点部署,我们可以通过引入memcached的方式,在多点环境下仍然能够正常使用cas。我们可以新创建一个类(如MemcachedTicketRegistry)实现AbstractTicketRegistry接口,修改相关配置如下:

WEB-INF\spring-configuration\ticketRegistry.xml:(在此省略了memcachedClient的配置)

<bean id="ticketRegistry" class="com.xxx.cas.server.MemcachedTicketRegistry">
    <property name="client" ref="memcachedClient" />
</bean>

这样cas server已经可以多点部署了,然而此时我们会发现单点登出功能不正常了。通过debug和查看代码,发现TGT中保存的service集合为空,这是单点登出不正常的直接原因,因为cas server会遍历TGT中保存的service集合,依次向对应的cas client发出退出请求。然而为什么TGT中保存的service集合会为空呢?这是因为TGT从第一次被保存到memcached后就再也没有被保存到memcached,这样从memcached中取得的TGT自然还是最初的TGT,当然其中的service会为空了,而cas默认实现中TGT是始终保持在内存中的自然不会有问题。既然找到了问题的原因就简单了,我们只要每当TGT增加service后,再次将TGT保存到memcached就能解决这个问题。

WEB-INF\spring-configuration\applicationContext.xml修改如下:

<bean id="centralAuthenticationService" class="org.jasig.cas.CentralAuthenticationServiceImpl" ... />
替换为
<bean id="centralAuthenticationService" class="com.xxx.cas.server.CentralAuthenticationServiceImpl" ... />

com.xxx.cas.server.CentralAuthenticationServiceImpl类相比org.jasig.cas.CentralAuthenticationServiceImpl类有如下不同:

this.serviceTicketRegistry.addTicket(serviceTicket);
//com.xxx.cas.server.CentralAuthenticationServiceImp类增加了下面一行:
this.serviceTicketRegistry.addTicket(ticketGrantingTicket);

多点部署cas client

对cas client来说,默认实现不能支持多点部署的原因在于cas client使用了session来保存凭证,要知道多点部署的应用其session是各自独立的,即使通过配置实现了session的同步,性能也会很差。那么如何解决这个问题呢?答案还是memcached。

我们可以用过滤器filter将自定义的request传递给后面的调用,filter内容如下:

SnaHttpServletRequest request = new SnaHttpServletRequest((HttpServletRequest) req,(HttpServletResponse) res, client);
WebContext instance = new WebContext(request, (HttpServletResponse) res, ctx);
try {
    WebContext.set(instance);
    chain.doFilter(request, res);
} finally {
    request.save();
    WebContext.set(null);
}

其中SnaHttpServletRequest类继承自HttpServletRequestWrapper类,覆盖HttpSession getSession()和HttpSession getSession(boolean create)方法,使这两个方法返回实现HttpSession接口但是以memcached为核心实现的类(如MemcachedSession),而MemcachedSession类必定是以cookie为依据的,否则无法返回正确的数据。

这其中代码的具体实现,网上已经有不少,这里就不展示了。

cas client经过这样的改动后,在多点部署下可以单点登陆了,但单点登出仍有问题。原因是因为SingleSignOutFilter将ticketId和session对应关系用HashMap来保存,在多点环境下自然不能正常工作。我们可以将ticketId和cookie值的对应关系保存在memcached上,从而实现单点登出。修改办法如下:

SingleSignOutFilter类:

public void init(final FilterConfig filterConfig) throws ServletException {
    String memcachedId = "memcachedClient";
    this.client = (XMemcachedClient) WebApplicationContextUtils.getWebApplicationContext(filterConfig.getServletContext()).getBean(memcachedId);
    handler.setSessionMappingStorage(new MemcachedBackedSessionMappingStorage(client));
//红色部分是新增的内容
if (!isIgnoreInitConfiguration()) { handler.setArtifactParameterName(getPropertyFromInitParams(filterConfig, "artifactParameterName", "ticket")); handler.setLogoutParameterName(getPropertyFromInitParams(filterConfig, "logoutParameterName", "logoutRequest")); } handler.init(); }

MemcachedBackedSessionMappingStorage类继承自SessionMappingStorage接口,代码如下:

public final class MemcachedBackedSessionMappingStorage implements SessionMappingStorage {
    private XMemcachedClient client;
    private static final int TIMEOUT = 60 * 60 * 24;

    private final String MANAGED_SESSIONS = "MANAGED_SESSIONS.";
    private final String ID_TO_SESSION_KEY_MAPPING = "ID_TO_SESSION_KEY_MAPPING.";

    private final Log log = LogFactory.getLog(getClass());

    public MemcachedBackedSessionMappingStorage(XMemcachedClient client) {
        this.client = client;
    }

    public synchronized void addSessionById(String mappingId, HttpSession session) {
        try {
            client.set(ID_TO_SESSION_KEY_MAPPING + session.getId(), TIMEOUT, mappingId);
            client.set(MANAGED_SESSIONS + mappingId, TIMEOUT, session.getId());
        } catch (Exception e) {
            throw new RuntimeException(e);
        }

    }

    public synchronized void removeBySessionById(String sessionId) {
        if (log.isDebugEnabled()) {
            log.debug("Attempting to remove Session=[" + sessionId + "]");
        }

        try {
            final String key = client.get(ID_TO_SESSION_KEY_MAPPING + sessionId);

            if (log.isDebugEnabled()) {
                if (key != null) {
                    log.debug("Found mapping for session.  Session Removed.");
                } else {
                    log.debug("No mapping for session found.  Ignoring.");
                }
            }
            client.delete(MANAGED_SESSIONS + key);
            client.delete(ID_TO_SESSION_KEY_MAPPING + sessionId);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    public synchronized HttpSession removeSessionByMappingId(String mappingId) {
        HttpSession session = null;
        try {
            String sessionId = client.get(MANAGED_SESSIONS + mappingId);
            session = new MemcachedSession(client, sessionId, false);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }

        if (session != null) {
            removeBySessionById(session.getId());
        }

        return session;
    }
}

 

其它修改 

在CAS的默认实现中,所有与 CAS 的交互均采用 SSL 协议,确保ST 和 TGC(Ticket Granted Cookie,对应TGT的名为CASTGC的cookie) 的安全性。这虽然极大保证了安全性,但在某些情况下,并不想使用SSL协议,那么可以进行如下修改:

WEB-INF\spring-configuration\ticketGrantingTicketCookieGenerator.xml:

<bean id="ticketGrantingTicketCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
        p:cookieSecure="true"
        p:cookieMaxAge="-1"
        p:cookieName="CASTGC"
        p:cookiePath="/cas" />
修改为:
<bean id="ticketGrantingTicketCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
        p:cookieSecure="false"
        p:cookieMaxAge="-1"
        p:cookieName="CASTGC"
        p:cookiePath="/cas" />

WEB-INF\spring-configuration\warnCookieGenerator.xml:

<bean id="warnCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
        p:cookieSecure="true"
        p:cookieMaxAge="-1"
        p:cookieName="CASPRIVACY"
        p:cookiePath="/cas" />
修改为:
<bean id="warnCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
        p:cookieSecure="false"
        p:cookieMaxAge="-1"
        p:cookieName="CASPRIVACY"
        p:cookiePath="/cas" />

WEB-INF\deployerConfigContext.xml:

<bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler"
                    p:httpClient-ref="httpClient" />
修改为:
<bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler"
                    p:httpClient-ref="httpClient" p:requireSecure="false"/>

进行上面的修改后cas就能支持普通http协议的单点登录了。