单点登陆终极方案之 CAS 应用及原理

Cookie的单点登陆的实现方式很简单，可是也问题颇多。例如：用户名密码不停传送，增长了被盗号的可能。另外，不能跨域！

一、基于Cookie的单点登陆的回顾

基于Cookie的单点登陆核心原理：

将用户名密码加密以后存于Cookie中，以后访问网站时在过滤器（filter）中校验用户权限，若是没有权限则从Cookie中取出用户名密码进行登陆，让用户从某种意义上以为只登陆了一次。

该方式缺点就是屡次传送用户名密码，增长被盗风险，以及不能跨域。点击这里了解Java如何进行跨域。同时www.qiandu.com与mail.qiandu.com同时拥有登陆逻辑的代码，若是涉及到修改操做，则须要修改两处。

二、统一认证中心方案原理

在生活中咱们也有相似的相关生活经验，例如你去食堂吃饭，食堂打饭的阿姨（www.qiandu.com）告诉你，不收现金。而且告诉你，你去门口找换票的（passport.com）换小票。因而你换完票以后，再去找食堂阿姨，食堂阿姨拿着你的票，问门口换票的，这个票是真的吗？换票的说，是真的，因而给你打饭了。

基于上述生活中的场景，咱们将基于Cookie的单点登陆改良之后的方案以下：

通过分析，Cookie单点登陆认证太过于分散，每一个网站都持有一份登录认证代码。因而咱们将认证统一化，造成一个独立的服务。当咱们须要登陆操做时，则重定向到统一认证中心http://passport.com。因而乎整个流程就如上图所示：

第一步：用户访问www.qiandu.com。过滤器判断用户是否登陆，没有登陆，则重定向（302）到网站http://passport.com。

第二步：重定向到passport.com，输入用户名密码。passport.com将用户登陆的信息记录到服务器的session中。

第三步：passport.com给浏览器发送一个特殊的凭证，浏览器将凭证交给www.qiandu.com，www.qiandu.com则拿着浏览器交给他的凭证去passport.com验证凭证是否有效，从而判断用户是否登陆成功

第四步：登陆成功，浏览器与网站之间进行正常的访问。

三、Yelu大学研发的CAS(Central Authentication Server)

下面就以耶鲁大学研发的CAS为分析依据，分析其工做原理。首先看一下最上层的项目部署图：

部署项目时须要部署一个独立的认证中心（cas.qiandu.com），以及其余N个用户本身的web服务。

认证中心：也就是cas.qiandu.com，即cas-server。用来提供认证服务，由CAS框架提供，用户只须要根据业务实现认证的逻辑便可。

用户web项目：只须要在web.xml中配置几个过滤器，用来保护资源，过滤器也是CAS框架提供了，即cas-client，基本不须要改动能够直接使用。

四、CAS的详细登陆流程

上图是3个登陆场景，分别为：第一次访问www.qiandu.com、第二次访问、以及登陆状态下第一次访问mail.qiandu.com。

下面就详细说明上图中每一个数字标号作了什么，以及相关的请求内容，响应内容。

4.一、第一次访问www.qiandu.com

标号1：用户访问http://www.qiandu.com，通过他的第一个过滤器（cas提供，在web.xml中配置）AuthenticationFilter。

过滤器全称：org.jasig.cas.client.authentication.AuthenticationFilter

主要做用：判断是否登陆，若是没有登陆则重定向到认证中心。

标号2：www.qiandu.com发现用户没有登陆，则返回浏览器重定向地址。

首先能够看到咱们请求www.qiandu.com，以后浏览器返回状态码302，而后让浏览器重定向到cas.qiandu.com而且经过get的方式添加参数service，该参数目的是登陆成功以后会要重定向回来，所以须要该参数。而且你会发现，其实server的值就是编码以后的咱们请求www.qiandu.com的地址。

标号3：浏览器接收到重定向以后发起重定向，请求cas.qiandu.com。

标号4：认证中心cas.qiandu.com接收到登陆请求，返回登录页面。

上图就是标号3的请求，以及标号4的响应。请求的URL是标号2返回的URL。以后认证中心就展现登陆的页面，等待用户输入用户名密码。

标号5：用户在cas.qiandu.com的login页面输入用户名密码，提交。

标号6：服务器接收到用户名密码，则验证是否有效，验证逻辑可使用cas-server提供现成的，也能够本身实现。

上图就是标号5的请求，以及标号6的响应了。当cas.qiandu.com即csa-server认证经过以后，会返回给浏览器302，重定向的地址就是Referer中的service参数对应的值。后边并经过get的方式挟带了一个ticket令牌，这个ticket就是ST（数字3处）。同时会在Cookie中设置一个CASTGC，该cookie是网站cas.qiandu.com的cookie，只有访问这个网站才会携带这个cookie过去。

Cookie中的CASTGC：向cookie中添加该值的目的是当下次访问cas.qiandu.com时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登陆过了，是否须要展现登陆页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。点击这里了解Java如何操做Cookie。

TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他能够签发ST）

TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他能够找到TGT。

ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字3处的ticket值。

标号7：浏览器从cas.qiandu.com哪里拿到ticket以后，就根据指示重定向到www.qiandu.com，请求的url就是上面返回的url。

标号8：www.qiandu.com在过滤器中会取到ticket的值，而后经过http方式调用cas.qiandu.com验证该ticket是不是有效的。

标号9：cas.qiandu.com接收到ticket以后，验证，验证经过返回结果告诉www.qiandu.com该ticket有效。

标号10：www.qiandu.com接收到cas-server的返回，知道了用户合法，展现相关资源到用户浏览器上。

至此，第一次访问的整个流程结束，其中标号8与标号9的环节是经过代码调用的，并非浏览器发起，因此没有截取到报文。

4.二、第二次访问www.qiandu.com

上面以及访问过一次了，当第二次访问的时候发生了什么呢？

标号11：用户发起请求，访问www.qiandu.com。会通过cas-client，也就是过滤器，由于第一次访问成功以后www.qiandu.com中会在session中记录用户信息，所以这里直接就经过了，不用验证了。

标号12：用户经过权限验证，浏览器返回正常资源。

4.三、访问mail.qiandu.com

标号13：用户在www.qiandu.com正常上网，忽然想访问mail.qiandu.com，因而发起访问mail.qiandu.com的请求。

标号14：mail.qiandu.com接收到请求，发现第一次访问，因而给他一个重定向的地址，让他去找认证中心登陆。

上图能够看到，用户请求mail.qiandu.com，而后返回给他一个网址，状态302重定向，service参数就是回来的地址。

标号15：浏览器根据14返回的地址，发起重定向，由于以前访问过一次了，所以此次会携带上次返回的Cookie：TGC到认证中心。

标号16：认证中心收到请求，发现TGC对应了一个TGT，因而用TGT签发一个ST，而且返回给浏览器，让他重定向到mail.qiandu.com

能够发现请求的时候是携带Cookie：CASTGC的，响应的就是一个地址加上TGT签发的ST也就是ticket。

标号17：浏览器根据16返回的网址发起重定向。

标号18：mail.qiandu.com获取ticket去认证中心验证是否有效。

标号19：认证成功，返回在mail.qiandu.com的session中设置登陆状态，下次就直接登陆。

标号20：认证成功以后就反正用想要访问的资源了。

五、总结

至此，CAS登陆的整个过程就完毕了，之后有时间总结下如何使用CAS，并运用到项目中。

更多精彩文章，关注公众号【ToBeTopJavaer】，更有以下数万元精品vip资源免费等你来拿！！！复制代码