CAS单点登录技术原理

参考博文：

http://www.iteye.com/blogs/subjects/cas168

http://www.coin163.com/java/cas/cas.html

老早便就想学习下CAS单点登录了，这两天学习了下CAS并简单实现了单点登录的小应用

一，SSO以及CAS实现SSO原理

前言

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

SSO原理

sso角色

一般SSO体系主要角色有三种：

1、 User（多个）

2、 Web应用（多个）

3、 SSO认证中心（1个）

SSO实现方式

SSO的主要实现方式有：

1、共享COOKIEs

基于共享同域的COOKIE是Web刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递COOKIEs机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然COOKIEs本身不跨域，但可以利用它实现跨域的SSO。如：代理、暴露SSO令牌值等。

缺点：不灵活而且有不少安全隐患，已经被抛弃。

2、 Broker-based(基于经纪人)

这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的"第三方"。例如Kerberos、Sesame、IBM KryptoKnight（凭证库思想)等。Kerberos是由麻省理工大学发明的安全认证服务，已经被UNIX和Windows作为默认的安全认证服务集成进操作系统。

3、Agent-based（基于代理人）

在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加***来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个"翻译"。例如SSH等。

4、Token-based

例如SecureID,WebID，现在被广泛使用的口令认证，比如FTP、邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。

5、基于网关

6、 基于SAML

SAML(Security Assertion Markup Language，安全断言标记语言）的出现大大简化了SSO，并被OASIS批准为SSO的执行标准。开源组织OpenSAML 实现了 SAML 规范。

CAS原理

Cas的全称是Centeral Authentication Service，是对单点登录SSO（Single Sign On）的一种实现。其由Cas Server和Cas Client两部分组成，Cas Server是核心，而Cas Client通常就对应于我们的应用。一个Cas Server可以对应于多个Cas Client。它允许我们在一个Client进行登录以后无需再让用户输入用户名和密码进行认证即可访问其它Client应用。

CAS Server负责完成对用户的认证工作, 需要独立部署, CAS Server 会处理用户名 / 密码等凭证 (Credentials)。

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

上面是CAS最基础的协议过程

CAS Client 与受保护的客户端应用部署在一起，以Filter方式保护Web应用的受保护资源，过滤从客户端过来的每一个Web请求，同时，CAS Client 会分析HTTP请求中是否包含请求Service Ticket( ST上图中的Ticket) ，如果没有，则说明该用户是没有经过认证的；于是CAS Client 会重定向用户请求到 CAS Server（Step 2），并传递Service（要访问的目的资源地址）。 Step 3是用户认证过程，如果用户提供了正确的Credentials， CAS Server随机产生一个相当长度、唯一、不可伪造的Service Ticket，并缓存以待将来验证，并且重定向用户到Service 所在地址（附带刚才产生的Service Ticket ）, 并为客户端浏览器设置一个Ticket Granted COOKIE（TGC）；CAS Client 在拿到Service和新产生的 Ticket过后，在Step 5和Step6中与CAS Server进行身份核实，以确保 Service Ticket 的合法性。 在该协议中，所有与CAS Server的交互均采用SSL协议，以确保ST和TGC的安全性。协议工作过程中会有2次重定向的过程。但是 CAS Client与CAS Server之间进行Ticket验证的过程对于用户是透明的（使用HttpsURLConnection）。下面用官网的一张图来描述CAS单点登录的实现过程：

如你所见，在第一次访问应用app1时，由于没有登录会直接跳转到Cas Server去进行登录认证，此时将附带查询参数service在Cas Server的登录地址上，表示登录成功后将要跳转的地址。此时Cas Server检查到没有之前成功登录后生成的SSO Session信息，那么就会引导用户到登录页面进行登录。用户输入信息提交登录请求，Cas Server认证成功后将生成对应的SSO Session，以及名为CASTGC的COOKIE，该COOKIE包含用来确定用户SSO Session的Ticket Granting Ticket（TGT）。之后会生成一个Service Ticket（ST），并将以ticket作为查询参数名，以该ST作为查询参数值跳转到登录时service对应的URL。如：

http(s)://domain/app1?ticket=ST-2-59fS6KxvmykibRXyoPJE

之后的操作对用户来说都是透明的，即不可见的。app1之后将以service和ticket作为查询参数请求Cas Server对service进行验证，验证通过后Cas Server将返回当前用户的用户名等信息。app1就会给当前用户生成其自身的Session，以后该用户以该Session都可以成功的访问app1，而不需要再去请求Cas Server进行认证。当该用户再去访问app2的时候，由于其在app2上没有对应的Session信息，将会跳转到Cas Server的登录地址，Cas Server此时发现其包含名为CASTGC的COOKIE，将获取其中包含的TGT来获取对应的SSO Session，然后会将用户重定向到app2对应的地址，以Service Ticket作为查询参数。之后app2会向Cas Server发送请求校验该Service Ticket，校验成功后app2将建立该用户对应的Session信息，以后该用户以该Session就可以自由的访问app2了。

综上所述，我们知道，各系统之间的单点登录是通过Cas Server生成的SSO Session来交流的，而用户与实际的应用系统进行交互的时候，各应用系统将建立单独的Session，以满足用户与该系统的交互需求。

这有一篇关于CAS实现的文章：http://blog.csdn.net/frinder/article/details/7969925

来源：https://www.pianshen.com/article/9339132331/