Liferay and CAS and LDAP original text from http://www.huqiwen.com/2013/12/18/liferay-cas-ldap/
CAS and LDAP are things that Liferay often uses when implementing single sign-on. This article shares the personal connection and integration between Liferay, CAS, and LDAP. I reprinted an article published on IBM's developer technology community website " Transfer: Liferay integrates CAS to achieve single sign-on and application system integration ". There are not many principles in it. This article will try to explain from the theoretical level. A relatively clear description of the relationship between liferay and CAS and LDAP, this article does not involve technical implementation details, mainly on theory.
sign in
Single Sign On (Single Sign On), referred to as SSO, is one of the more popular solutions for enterprise business integration. The definition of SSO is that in multiple application systems, users only need to log in once to access all mutually trusted application systems. ( Baidu Encyclopedia )
With the development of enterprise informatization, in an enterprise, a business person often needs to log in to multiple business systems, such as OA, HR, ERP, CRM, EAM, EIP, etc. The security and management of enterprises pose challenges. The goal of single sign-on is that the user only needs to log in to one of the systems, and the other systems do not need to log in. If the user logs out in one system, the other systems are also logged out.
There are many technologies for implementing single sign-on, such as CAS, ADFS, OpenID and so on. The CAS we're going to cover today is just one option for a single sign-on implementation.
Introduction to CAS
CAS is an open source project initiated by Yale University, aiming to provide a reliable single sign-on method for Web application systems. CAS officially became a project of JA-SIG in December 2004.
CAS features:
1. The open source enterprise-level single sign-on solution has many successful cases.
2. The CAS Server can be independently deployed as a Web application as needed.
3. CAS Client supports numerous clients (here refers to various web applications in the single sign-on system), including Java, .Net, PHP, Perl, Ruby, etc.
Introduction to LDAP
LDAP is a Lightweight Directory Access Protocol, the full English name is Lightweight Directory Access Protocol, generally referred to as LDAP. We can simply think of it as a special kind of database. A lot of optimizations have been made for read queries, with very high read performance, but relatively low write performance.
In a single sign-on system, LDAP is usually chosen as the storage for unified users. The advantages are as follows:
1. Compliant with catalog X.500 standard, easy to integrate between systems
2. Effectively ensure the sharing and integration between resource products and external businesses
3. Make use of the query efficiency of directory storage and improve platform performance
Liferay integrates with CAS
Liferay is usually used as a portal, and the portal is usually used as the entrance of a system in an enterprise. After users log in on the Liferay portal, they can access other systems without having to log in again, so as to achieve "one-point login, multi-point roaming" The goal.
In Liferay, CAS is integrated by default, and it is convenient for us to integrate Liferay with CAS to implement a single sign-on system.
From a large perspective, CAS consists of two parts, CAS Client and CAS Server, one client and one server.
CAS Server：
CAS Server is responsible for completing the authentication of users. CAS Server generally needs to be deployed independently. We can deploy it to a separate server, or put it under the same Tomcat with Liferay (this is actually independent from a logical point of view), The former is recommended, the application and CAS Server are separate, so the integration method described in the article " Transfer: Liferay Integrates CAS to Implement Single Sign-On and Application System Integration " is generally not recommended. It can also be used as a demonstration test. Production environment Strongly not recommended.
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中，此过程对用户是不可见的。新建的用户登录和老用户登录的体验是一致的。
相关问题
可能有同学会问，上面说的单点登录都是统一用户的，如果是老系统没办法做统一用户，是不是就不能做单点登录了？
Generally speaking, it is best to unify users to do single sign-on, which is easy to manage and convenient for development, but for old systems or old users who cannot do it, if you want to do single sign-on, it is usually user mapping. Zhang San, Zhangsan, 00356, etc. mentioned are the same person, and a mapping relationship must be established before these.
CAS Client needs to add filters in web.xml, or needs to modify the system, what should I do if the old system cannot be modified?
For old systems that cannot be transformed, a simulated login method can generally be used. At this time, CAS is not required.
What is the relationship between HR data and unified user data?
Generally, the data of human resources in an enterprise is the most standard user data (the premise is a company with standardized management). For example, after a new employee joins the company, the data of the employee must first enter the human resources system. At this time, human resources are required. There is data synchronization between resources and unified users.
The data of human resources stores the attribute information of employees, such as the employee's position, salary, name, performance score, etc.; the data in the unified user is only the basic data of the user, and the data in the unified user is one of the employee data in human resources. Subset.
If you don't want to use LDAP and don't create unified users, can you just use the users in Liferay as the standard?
It is feasible to complete, without using LDAP, we use the user data in Liferay as the standard, and the user data of other systems such as OA, ERP, CRM, etc. are imported from Liferay, and are consistent with the user data in Liferay. When we authenticate, let CAS verify the account from Liferay's database. In fact, the users in Liferay are already unified users at this time.
The key to unifying users is to use the data of a system as the standard. As long as the overall unity is maintained, we can also use the user data in the OA as the standard, or the user data in the ERP as the standard.