单点登录实现----CAS(一)
2015-05-29 17:55
337 查看
最近我们部门交接了一个新项目--- passport,即我司的单点登录系统,虽然没有交接给我,但是个人觉得登录技术是个很好的知识,于是就忙里偷闲简单地学习了下。
单点登录SSO(single sign on)是一个当前流行的企业级多应用整合用户认证解决方案。从多个web应用中分离出登录、认证操作,进行同意管理,这样个web应用也不需要重复设计登录认证操作,专注各自的业务。
目前最应用最多的SSO实现方案是耶鲁(Yale)大学发起的一个开源项目----CAS(Central Authenticaion Service 中央认证服务),
CAS包含两部分:CAS Server 和 CAS Client
CAS Server :CAS服务器端集中进行用户的登录认证,需要独立部署;
CAS Client :CAS客户端主要过滤应用的请求,以filter的方式保护受保护请求,它需要和应用部署在一起;
CAS的基础模式
1. user请求应用1(以下简称aap1),CAS Client过滤此请求,如果是受保护请求,则分析此请求是否含有ST(Service Ticket,表明当前user的当前请求是否经过CAS Server认证)或者app1中的session(有用户信息表明当前用户通过此应用在CAS Server认证过,无须再去CAS Server认证)里是否含有当前用户信息;
2. 1中发现没有ST或者session,则重定向user请求到CAS Server,CAS Server 从user中获取TGC(Ticket Granted Cookie,表明当前user在CAS Server登录认证过,无须用户登录,这也体现了单点登录的需求),如果没有TGC或者TGC失效,则返回user登录页面,让用户登录认证;
3. 用户输入账号、密码,在CAS Server进行认证,如果登录成功,CAS Server生成一个唯一的,不可伪造的长度相当的ST;
4. CAS Server重定向user请求到CAS Client,附带上刚才生成的ST;
5. CAS Client向CAS Server发起校验请求,校验收到的ST的有效性;
6. ST验证有效,在app1上创建session,来标识用户已登录;
7. 现在,登录认证全部完成,重定向user到服务情求地址。
CAS的代理模式
CAS代理模式试用场景:用户向app1发出请求,但是app1依赖app2(假设app1和2均需要认证),为了提升交互效果,避免过多的重定向,CAS引入代理机制,由CAS Client代理user访问app2,
类似于基础模式中usr保存TGC,代理模式中,CAS Client也需要存储用户的身份信息,这就是PGT(Proxy Gtanted Ticket),CAS Server获取CAS Client中PGT的用户身份信息,确认身份后返回PT(Proxy Ticket)给代理程序CAS Client。
一句话来说,PGT和TGC类似,PT和ST类似,区别就是,PGT保存在CAS Client,而TGC保存在user。
CAS的的安全性设计
1. TGC\PGT是用来确认用户是否需要登录的,所以,安全性不言而喻,CAS Server使用SSL发送 TGC\PGT到user\CAS Client;
2. ST\PT:只能使用一次,使用后即作废、只在一段时间内有效(默认5分钟)、随机数(一定不能让人猜出规则);
单点登录SSO(single sign on)是一个当前流行的企业级多应用整合用户认证解决方案。从多个web应用中分离出登录、认证操作,进行同意管理,这样个web应用也不需要重复设计登录认证操作,专注各自的业务。
目前最应用最多的SSO实现方案是耶鲁(Yale)大学发起的一个开源项目----CAS(Central Authenticaion Service 中央认证服务),
CAS包含两部分:CAS Server 和 CAS Client
CAS Server :CAS服务器端集中进行用户的登录认证,需要独立部署;
CAS Client :CAS客户端主要过滤应用的请求,以filter的方式保护受保护请求,它需要和应用部署在一起;
CAS的基础模式
1. user请求应用1(以下简称aap1),CAS Client过滤此请求,如果是受保护请求,则分析此请求是否含有ST(Service Ticket,表明当前user的当前请求是否经过CAS Server认证)或者app1中的session(有用户信息表明当前用户通过此应用在CAS Server认证过,无须再去CAS Server认证)里是否含有当前用户信息;
2. 1中发现没有ST或者session,则重定向user请求到CAS Server,CAS Server 从user中获取TGC(Ticket Granted Cookie,表明当前user在CAS Server登录认证过,无须用户登录,这也体现了单点登录的需求),如果没有TGC或者TGC失效,则返回user登录页面,让用户登录认证;
3. 用户输入账号、密码,在CAS Server进行认证,如果登录成功,CAS Server生成一个唯一的,不可伪造的长度相当的ST;
4. CAS Server重定向user请求到CAS Client,附带上刚才生成的ST;
5. CAS Client向CAS Server发起校验请求,校验收到的ST的有效性;
6. ST验证有效,在app1上创建session,来标识用户已登录;
7. 现在,登录认证全部完成,重定向user到服务情求地址。
CAS的代理模式
CAS代理模式试用场景:用户向app1发出请求,但是app1依赖app2(假设app1和2均需要认证),为了提升交互效果,避免过多的重定向,CAS引入代理机制,由CAS Client代理user访问app2,
类似于基础模式中usr保存TGC,代理模式中,CAS Client也需要存储用户的身份信息,这就是PGT(Proxy Gtanted Ticket),CAS Server获取CAS Client中PGT的用户身份信息,确认身份后返回PT(Proxy Ticket)给代理程序CAS Client。
一句话来说,PGT和TGC类似,PT和ST类似,区别就是,PGT保存在CAS Client,而TGC保存在user。
CAS的的安全性设计
1. TGC\PGT是用来确认用户是否需要登录的,所以,安全性不言而喻,CAS Server使用SSL发送 TGC\PGT到user\CAS Client;
2. ST\PT:只能使用一次,使用后即作废、只在一段时间内有效(默认5分钟)、随机数(一定不能让人猜出规则);
相关文章推荐
- iCheck .js各种各样的插件 fuck Javascript
- 寻找水王
- Linux进程与线程的区别
- 指定一个Java文件,输入其代码行数
- C#/WPF 面试题(Microsoft, Morgan stanley)
- SVN使用教程之—分支/标记 合并
- 微软镜像资源ISO全收录
- 程序员面试题精选算法58题加答案
- 第13周-多态性-项目0-课后实践·阅读程序1.
- unity资源打包研究
- 阅读8,9,10章
- SQL SERVER2008历史日志查询
- LeetCode题解:Merge Sorted Array
- 从手机来电分析android消息机制
- ArcSDE的SQL操作ObjectID获取方式
- TortoiseSVN客户端重新设置用户名和密码
- Qt5.3 For Andoid 安装过程
- spring多数据源配置
- 写lua时需要注意的地方
- Django搭建及源码分析(二)