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 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中，此过程对用户是不可见的。新建的用户登录和老用户登录的体验是一致的。
相关问题可能有同学会问，上面说的单点登录都是统一用户的，如果是老系统没办法做统一用户，是不是就不能做单点登录了？
一般做单点登录肯定是最好上统一用户，这样好管理，开发也方便，但对于没办法做的老系统或老用户，如果要做单点登录一般就是做的用户映射，要知道我们前面说的张三、zhangsan、00356等等是同一个人，这些之前要建立一个映射关系。
cas client需要在web.xml里面添加过滤器，还是需要对系统做改造，老系统没法改造怎么办？
对于没法改造的老系统一般可以采用模拟登录的方式，这个时候就不用cas了。
人力资源的数据与统一用户的数据啥关系？
一般一个企业里面的人力资源的数据是最标准的用户数据（前提是管理规范的公司），比如一个新员工入公司之后，员工的数据必然是先进入到人力资源系统里面的，这个时候需要人力资源和统一用户的之间有数据的同步。
人力资源的数据保存的是员工的属性信息，比如员工的岗位、工资、名称、绩效成绩等；统一用户里面的数据只是用户的基础数据，统一用户里面的数据是人力资源里面的员工数据的一个子集。
不想使用ldap，也不建立统一用户，就使用liferay里面的用户作为标准行不？
完成可行，不使用ldap，我们就使用liferay里面的用户数据作为标准，其他的系统比如oa、erp、crm等这些的用户数据都从liferay里面进行导入，并和liferay里面的用户数据保持一致。我们认证的时候就让cas从liferay的数据库中进行帐号的验证。其实这个时候liferay里面的用户已经算是统一用户了。
统一用户的关键是以一个系统的数据作为标准，只要保持全局的统一即可，我们也可以使用oa里面的用户数据作为标准，也可以使用erp里面的用户数据作为标准都行。
原文地址：liferay与cas及ldap, 感谢原作者分享。