CAS单点登录项目实战(1)

CAS单点登录项目实战——基础入门

一、项目背景

---

       企业的信息化过程是一个循序渐进的过程，在企业各个业务网站逐步建设的过程中，根据各种业务信息水平的需要构建了相应的应用系统，由于这些应用系统一般是在不同的时期开发完成的，各应用系统由于功能侧重、设计方法和开发技术都有所不同，也就形成了各自独立的用户库和用户认证体系。

       随着新的业务网站不断的增加，用户在每个应用系统中都有独立的账号，这样就造成在访问不同的应用系统时，需要记录对应的用户名和密码，多个用户名密码极易记混，如果忘记或记错了某一个业务网站的用户名或密码就无法进行登录，耽误工作，影响工作效率，随着局内信息化进程的推进还会有新的应用系统产生，如果不引入单一用户登录的解决方案，全公司工作人名特别是承担审批权限的各级领导很难记清各类应用系统的用户名和密码，严重影响由信息化带来快捷性和高效性。此外，多个应用平台就有多个用户管理，这也为系统管理员维护人员系统带来巨大的工作量，例如，一次变更10个人员，即使只有5个应用系统，也需要重复维护50个人员信息，而企业的每次人员调整远不至10人，这种几何增长的维护工作量，会浪费大量的精力和时间，减弱了信息化系统带来方便快捷，为此，需建立一套统一的、完善的、科学的单点登录系统，每个用户只需记录一个用户名密码，登录一个平台后即可实现各应用系统的透明跳转，而且实行统一的用户信息管理系统，系统管理员只需维护一套人员信息，更改信息通过平台接口同步更新至各个应用系统，实现人员系统单次维护全公司同步变更，大大提高工作效率。

       新的应用系统在不断开发，早一天规划设计出单点登录的规范接口，就可以为新开发的系统提出的一种整合的标准，在开发初期无论哪个开发商，无论采用哪种技术开发，只要遵循单点登录的规范标准，新的系统开发完成之后即可无缝整合的到单点登录平台中，从而减少了系统开发完成后再整合到单点登录改动而造成资源的浪费。

       从信息共享角度看现有的各个业务系统都使用各自的数据存储方式，不经过基础的用户名和密码认证后，相互之间无法传递有效信息。为避免信息孤岛的产生，因此需要建立一个连接各个业务系统的技术架构和标准，实现平台统一化整合；通过对业务处理和异常处理实现监管透明；通过将业务流程从应用中抽离，实现业务流程的灵活安排，这样就需要一套可以整合现有各个业务网站的信息共享平台。

       单点登录的英文名称为Single Sign-On，简写为SSO，它是一个用户认证的过程，允许用户一次性进行认证之后，就访问系统中不同的应用；而不需要访问每个应用时，都重新输入密码。IBM对SSO有一个形象的解释“单点登录、全网漫游”。

       SSO将一个企业内部所有域中的用户登录和用户帐号管理集中到一起，SSO的好处显而易见：

1. 减少用户在不同系统中登录耗费的时间，减少用户登录出错的可能性 2. 实现安全的同时避免了处理和保存多套系统用户的认证信息 3. 减少了系统管理员增加、删除用户和修改用户权限的时间 4. 增加了安全性：系统管理员有了更好的方法管理用户，包括可以通过直接禁止和删除用户来取消该用户对所有系统资源的访问权限 5. 对于内部有多种应用系统的企业来说，单点登录的效果是十分明显的。很多国际上的企业已经将单点登录作为系统设计的基本功能之一。

       目前能够找到的开源登录产品CAS采用Cookie机制实现

二、CAS介绍

---

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

-开源的、多协议企业级单点登录解决方案，支持的协议：Custom Portocol（自定义）、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0等；
-支持多种认证机制：Active Directory、JAAS、JDBC、LDAP等；
-安全策略：使用ticket（票据）来实现支持的认证协议；
-支持授权：可以决定哪些服务可以请求和验证服务票据(Service Ticket)；
-提高高可用性：通过把认证过的状态数据存储在TicketRegistry组件中，这些组件有很多支持分布环境的实现，如：BerklyDB、Default、EhcacheTicketRegistry、JDBCTicketRegistry、MemcacheTicketRegistry等；
-CAS Client支持多种客户端（Web应用客户端），包括Java，.Net，PHP，Perl，Apache，Ruby等；
-

        CAS门户网站：https://www.apereo.org/projects/cas

        CAS源码网站：https://github.com/Jasig/cas/

       

三、CAS的基本原理

---

3.1 结构体系

        从结构体系上看，CAS包括两部分：CAS Server 和CAS Client

3.1.1 CAS Server

        CAS Server作为一个独立的Web应用程序，需要独立部署，负责完成对用户的认证工作 , CAS Server 会处理用户名 / 密码等凭证。

3.1.2 CAS Client

        负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。

        CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。

3.2 CAS 原理和协议

3.2.1 基础模式

        基础模式SSO访问流程主要有以下步骤：

1. 访问服务：SSO客户端发送请求访问应用系统提供的服务资源；
2. 定向认证：SSO客户端会重定向用户请求到SSO服务器；
3. 用户认证：用户身份认证；
4. 发放票据：SSO服务器会产生一个随机的Service Ticket；
5. 验证票据：SSO服务器验证票据Service Ticket的合法性，验证通过后允许客户端访问服务；
6. 传输用户信息：SSO服务器验证票据通过后，传输用户认证结果信息给客户端。

        下图是CAS最基本的协议过程：