Liferay与CAS及LDAP
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自带的那个登录Portlet,然后需要使用重新做一个?
建议使用Hook来覆盖登录的portlet,配合主题以达到自己想要的样子