cas单点登录原理
1、基于Cookie的单点登录
原理:
将用户名密码加密智斗存于Cookie中,之后访问网站时在过滤器校验用户权限,如果没有权限则从Cookie中取出用户名密码进行登录,让用户觉得
只登录了一次。
2、统一认证中心方案原理
在生活中我们也有类似的相关生活经验,例如你去食堂吃饭,食堂打饭的阿姨(www.qiandu.com)告诉你,不收现金。并且告诉你,你去门口找换票的(passport.com)换小票。于是你换完票之后,再去找食堂阿姨,食堂阿姨拿着你的票,问门口换票的,这个票是真的吗?换票的说,是真的,于是给你打饭了。
基于上述生活中的场景,基于Cookie的单点登录改良以后的方案如下:
经过分析,Cookie单点登录认证太过于分散,每个网站都持有一份登录认证代码。于是将认证统一化,形成一个独立的法务。
当需要登录操作时,则重定向到同意认证中心http://passport.com。整个流程如上图所示:
1:用户访问www.qiandu.com。过滤器判断用户是否登录,没有登录,则重定向(302)到网站http://passport.com。
2、重定向到passport.com。输入用户名密码。passport.com将用户登录的信息记录到服务器的session中。
3、passport.com给浏览器发送一个特殊凭证,浏览器将凭证交给www.qiandu.com,www.qiandu.com则拿着浏览器交给它
的凭证去passport.com验证凭证是否有效,从而判断用户是否登录成功。
4、登录成功,浏览器与网站之间进行正常的访问
3、cas认证
最上层的项目部署图
项目部署时需要部署一个独立的认证中心,以及其他N个用户自己的web服务
认证中心:也就是cas.qiandu.com,即cas-server。用来提供认证服务,由cas框架提供,用户自需要根据业务实现认证的逻辑。
用户web项目:只需要在web.xml中配置几个过滤器,用来保护资源,过滤器也是cas框架提供,即cas-client。
4、cas的详细登录流程
上面是3个登录场景,分别为:第一次访问www.qiandu.com、第二次访问、以及登录状态下第一次访问mail.qiandu.com
下面就详细说明上图中每个数字标号做了什么,以及相关的请求内容,相应内容
4.1、第一次访问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,该参数目的是登录成功之后会重定向回来,因此需要该参数。而且hi发现,其实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即cas-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的关系。
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的返回,知道了用户合法,展示相关资源到用户浏览器上
至此,第一次访问的整个流程结束
第二次访问www.qiandu.com
上面已经访问过一次了,当第二次访问的时候发生了什么?
标号11:用户发起请求,访问www.qiandu.com。会经过cas-client,也就是过滤器,因为第一次访问成功之后www.qiandu.com中
会在session中记录用户信息,因此这里直接就通过了,不用验证了。
标号12:用户通过权限验证,浏览器返回正常资源
访问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,并且返回给浏览器,让他重定向到main.qiandu.com
可以发现请求的时候是携带Cookie:CASTGC的,响应的就是一个地址加上TGT签发的ST也就是ticket
标签17:浏览器根据16返回的网址发起重定向。
标签18:mail.qiandu.com获取ticket去认证中心验证是否有效
标签19:认证成功,返回在mail.qiandu.com的session中设置登录状态,下次就直接登录。
标签20:认证成功之后就访问资源