CAS与LDAP是Liferay实现单点登录时经常会用到的东西，本篇文章分享一下个人对Liferay、CAS、LDAP等三者之间的联系与集成。在前面转载过一篇发表在IBM的开发者技术社区网站的文章《转：Liferay 集成 CAS 实现单点登录与应用系统集成》，里面有些原理的内容阐

CAS与LDAP是Liferay实现单点登录时经常会用到的东西，本篇文章分享一下个人对Liferay、CAS、LDAP等三者之间的联系与集成。在前面转载过一篇发表在IBM的开发者技术社区网站的文章《转：Liferay 集成 CAS 实现单点登录与应用系统集成》，里面有些原理的内容阐述的不多，本文将试着从理论层面对liferay与CAS和LDAP的关系进行一个比较清晰的描述，本文暂不涉及技术实现细节，主要讲理论。

单点登录

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。（百度百科）

随着企业信息化的发展，在一个企业中经常会碰到一个业务人员需要登录多个业务系统，比如OA、HR、ERP、CRM、EAM、EIP等，业务人员对此烦不胜烦，同时对企业的安全、管理等形成了挑战。单点登录的目标就是用户只需要登录了其中的一个系统，其他的系统也都不用登录了，用户在一个系统进行了注销，其他系统也都注销了。

实现单点登录的技术有许多，比如CAS、ADFS、OpenID等等。我们今天要介绍的CAS只是单点登录实现方案的一种选择。

CAS简介

CAS是Yale（耶鲁）大学发起的一个开源项目，旨在为Web应用系统提供一种可靠的单点登录方法，CAS在2004年12月正式成为JA-SIG的一个项目。

CAS特点：

1、开源的企业级单点登录解决方案，有非常多的成功案例。

2、CAS Server根据需要可以独立部署成Web应用。

3、CAS Client支持众多的客户端(这里指单点登录系统中的各个Web应用)，包括Java，.Net，PHP，Perl，Ruby等。

LDAP简介

LDAP是轻量目录访问协议，英文全称是Lightweight Directory Access Protocol，一般都简称为LDAP。我们可以简单的把他看作是一种特殊的数据库。为读查询做了非常多的优化，拥有非常高的读性能，但是写的性能相对较低。

在单点登录系统中，通常选择LDAP做统一用户的存储，优势有如下：

1、符合目录X.500标准，易于系统间整合

2、有效保证资源类产品与外界业务间的共享和整合

3、发挥了目录存储的查询效率，提升平台性能

Liferay与CAS整合

Liferay通常被当作门户使用，门户通常是当作一个企业中系统的入口，当用户在Liferay门户上登录之后，就能访问其他的系统而不必再次登录，以达到“一点登录，多点漫游”的目标。

在Liferay里面，默认整合了CAS，可以方便的让我们将Liferay与CAS进行集成，以实现一个单点登录系统。

CAS从大的方面看有两部分组成，CAS Client与CAS Server，一个客户端，一个服务端。

CAS Server：

CAS Server 负责完成对用户的认证工作， CAS Server一般需要独立部署，我们可以将他部署到单独的服务器，也可以和Liferay放到同一个Tomcat下面（这种从逻辑上来看其实也是独立的），推荐前者，应用和CAS Server是分开的，所以《转：Liferay 集成 CAS 实现单点登录与应用系统集成》这篇文章中介绍的集成方式一般是不推荐的，作为演示测试还可以使用，生产环境强烈不推荐。

CAS Server处理用户名、密码等凭证 (Credentials) ，它可能会到数据库检索一条用户帐号信息，也可能在 XML 文件中检索用户密码，也可能从LDAP中检索。无论哪种方式， CAS均提供一种灵活但统一的接口与实现分离的方式， CAS 采用的认证方式跟 CAS 协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。这段话怎么理解呢？也就是说CAS从用户数据源（可以是关系数据库、xml、ldap、nosql等）中查询出用户名和密码，和用户输入的进行比较，如果匹配就认为认证成功。数据源的类型可以根据我们的实际需求进行定义，他不有关心我们的用户数据存在哪，甚至存在文本文件中也行，只要我们写相应的适配器即可，所以我们从这里可以看到LDAP其实并不是必须的（统一用户部分后面说明）。认证方式跟CAS协议分离的意思是，我们在数据源中保存的密码可能是加密的，比如MD5加密、SHA加密等，而用户输入的帐号密码是没加密，我们在做这个验证的时候，这个加密或比较的过程可以自己实现，CAS里面只提供的是一种接口，《转：Liferay 集成 CAS 实现单点登录与应用系统集成》在这篇文章中就基于CAS的接口实际了Liferay密码的加密。

CAS Client：

CAS Client 负责部署在客户端，也就是待认证的应用，Liferay其实就是一个CAS Client，所以我们在liferay的jar包里面可以看到CAS Client的jar包，CAS Client 的作用是当对本地 Web 应用的受保护资源有访问请求，并且需要对请求进行身份认证时，Web 应用不再接受任何的用户名密码等类似的 Credentials ，而是重定向到 CAS Server 进行认证。

回到Liferay与CAS的整合，当我们整合成功之后，我们在浏览器里面输入http://localhost:8080/c/portal/login这样的登录地址，或者访问一个需要登录才能访问的页面时，会跳转到CAS Server（前面说了CAS Server可以和Liferay部署到同一个tomcat下面--但是不推荐，但是更推荐部署成不同的tomcat下面，尤其推荐和Liferay就不部署在一个服务器上）上的登录地址，如：http://localhost:8020/cas/login类似这样的页面，我们需要在CAS Server上输入帐号密码进行认证，认证成功后返回到Liferay的页面上。

CAS怎么判断用户有没有登录呢？CAS Client与Liferay或业务应用整合的时候，需要在业务应用（如Liferay）的web.xml里面添加一个filter，来判断请求中是否有token。

CAS的一个认证过程如下图所示：

cas认证过程

图片来源于网络

CAS Client与受保护的客户端应用部署在一起，以Filter方式保护受保护的资源。对于访问受保护资源的每个Web请求，CAS Client会分析该请求的Http请求中是否包含ServiceTicket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的CASServer登录地址，并传递Service（也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第3步中输入认证信息，如果登录成功，CAS Server随机产生一个相当长度、唯一、不可伪造的ServiceTicket，并缓存以待将来验证，之后系统自动重定向到Service所在地址，并为客户端浏览器设置一个TicketGrantedCookie（TGC），CASClient在拿到Service和新产生的Ticket过后，在第5，6步中与CAS Server进行身份合适，以确保ServiceTicket的合法性。

LDAP干啥

上面貌似没有提LDAP的事，他干嘛呢？比如我们现在有OA、HR、ERP、CRM、EAM、EIP等六个系统，如果这六系统里面的用户帐号都不一样，张三在OA里面的登录帐号是zhangsan，在HR里面的登录帐号是工号：00356，ERP里面是中文名称张三，在ERP里面是email地址：zhangsan，在CRM里面是userid：50291等等，不同的系统里面的帐号不一样，各自是独立的体系，现在OA里面的zhangsan登录了，HR里面并没有zhangsan这个用户呀，自然OA里面的zhangsan也就没有办法形成统一认证，统一登录了。

所以在实现单点登录的前提，一般是要实现统一用户，我们将OA、HR、ERP、CRM、EAM、EIP这些系统里面的用户信息都统一了或者以某一个系统的为准，企业里面一般以人力资源系统的数据为准，用户在HR里面是00356，在其他系统里面也都是00356。

由于LDAP优秀的读性能以及符合目录标准，我们一般将统一用户之后的用户认证信息保存到LDAP里面所有的业务系统OA、HR、ERP、CRM、EAM、EIP等里面的用户认证时的数据都从LDAP里面来取。这个时候可能就有同学问了，我就是不想用LDAP行不，行呀，我们只要将这些用户信息统一的保存一份，就行了，保存到哪无所谓。可以是LDAP，也可以是关系数据库、NOSQL数据库、KV数据库等各种数据源都行。

那我们为啥选择使用LDAP呢？前面提过LDAP的优势，认证的过程主要是查询，LDAP有非常高的读性能；其次我们做统一用户的时候是希望做系统数据整合的，有许多第三方的系统都默认支持LDAP，如果我们采用其他的方式，做用户数据的导入时可能就需要再重新开发接口或适配器。

LDAP与CAS的关系

还是以我们与Liferay整合为例子，当用户登录的时候，跳转到了cas的登录界面比如：http://localhost:8020/cas/login，这个时候用户输入了帐号密码，CAS接收到此帐号密码的时候，根据帐号名称从统一用户数据源（LDAP）中查询一条记录，查询出来之后，获取到了这个帐号的信息，将里面的密码取出来和用户输入的做比较，这个比较的过程就是认证了，这个比较的过程我们可以自己来写实现，比如我们的数据源中的用户数据保存的是MD5加密的，我们就要在这里对用户的密码进行一次MD5加密，再和是查询出来的比较。这也是前面说的认证和CAS协议分离。如果这个比较的过程我们不做二次开发，CAS默认的实现是只要相同就通过了，所以有加密的我们都要再根据接口写一下相应的实现。

LDAP与Liferay的关系

LDAP里面存的是标准的用户数据，Liferay里面的用户应该从LDAP里面导入。所以LDAP里面的用户数据和Liferay里面的用户数据的基础属性是相同的，我们在LDAP里面的配置就是配置将LDAP的数据导入到Liferay里面来。当我们在liferay里面编辑一条用户数据的时候，在保存成功后也会同步到LDAP里面（可以配置为是否开启，一般统一用户的时候只允许一个地方写数据，其他的节点都是只读数据）。

在这个过程中LDAP相当于一个中央仓库，Liferay其实也是一个客户端。

Liferay、CAS、LDAP的关系

现在假设我们在LDAP里面添加了一条数据，这个时候LDAP不会通知Liferay，Liferay里面是肯定没有这个用户，但是这个用户要登录怎么办呢？此时当此用户登录的时候，Liferay检测到此用户不存在，后台会从LDAP里面将用户导入到Liferay中，此过程对用户是不可见的。新建的用户登录和老用户登录的体验是一致的。

Liferay与CAS及LDAP