CAS(Central Authentication Service、中央认证服务)是Yale大学发起的一个开源项目,旨在[color=red]为Web应用系统提供一种可靠的单点登录方法[/color],CAS 在 2004 年 12 月正式成为 [color=blue]JA-SIG[/color] 的一个项目。官网地址:[url]http://www.jasig.org/cas[/url]
[b]特点:[/b]
[list]
[*]1、开源的企业级单点登录解决方案。
[*]2、CAS Server 为需要独立部署的 Web 应用。
[*]3、CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用),包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
[/list]
[b]原理和协议[/b]
从结构上看,CAS 包含两个部分: CAS Server 和 CAS Client。CAS Server 需要独立部署,主要负责对用户的认证工作;CAS Client 负责处理对客户端受保护资源的访问请求,需要登录时,重定向到 CAS Server。下图是CAS最基本的协议过程:
[img]http://dl.iteye.com/upload/attachment/0075/1765/a4b99778-9e46-35eb-b94c-dddfb11cc837.jpg[/img]
CAS Client 与受保护的客户端应用部署在一起,以 [color=blue]Filter[/color] 方式保护受保护的资源。
对于访问受保护资源的每个 Web 请求,CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket,如果没有,则说明当前用户尚未登录,于是将请求重定向到指定好的 CAS Server 登录地址,并传递 Service (也就是要访问的目的资源地址),以便登录成功过后转回该地址。
用户在第 3 步中输入认证信息,如果登录成功,CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket,并缓存以待将来验证,之后系统自动重定向到 Service 所在地址,并为客户端浏览器设置一个 [color=blue]Ticket Granted Cookie(TGC)[/color],
CAS Client 在拿到 Service 和新产生的 Ticket 过后,在第 5,6 步中与 CAS Server 进行身份合适,以确保 Service Ticket 的合法性。
在该协议中,[color=red]所有与 CAS 的交互均采用 SSL 协议,确保,ST 和 TGC 的安全性[/color]。协议工作过程中会有 [color=blue]2 次重定向[/color]的过程,但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
参考:[url=http://baike.baidu.com/view/18179.htm#sub6392359]CAS[/url]
[b]特点:[/b]
[list]
[*]1、开源的企业级单点登录解决方案。
[*]2、CAS Server 为需要独立部署的 Web 应用。
[*]3、CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用),包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
[/list]
[b]原理和协议[/b]
从结构上看,CAS 包含两个部分: CAS Server 和 CAS Client。CAS Server 需要独立部署,主要负责对用户的认证工作;CAS Client 负责处理对客户端受保护资源的访问请求,需要登录时,重定向到 CAS Server。下图是CAS最基本的协议过程:
[img]http://dl.iteye.com/upload/attachment/0075/1765/a4b99778-9e46-35eb-b94c-dddfb11cc837.jpg[/img]
CAS Client 与受保护的客户端应用部署在一起,以 [color=blue]Filter[/color] 方式保护受保护的资源。
对于访问受保护资源的每个 Web 请求,CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket,如果没有,则说明当前用户尚未登录,于是将请求重定向到指定好的 CAS Server 登录地址,并传递 Service (也就是要访问的目的资源地址),以便登录成功过后转回该地址。
用户在第 3 步中输入认证信息,如果登录成功,CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket,并缓存以待将来验证,之后系统自动重定向到 Service 所在地址,并为客户端浏览器设置一个 [color=blue]Ticket Granted Cookie(TGC)[/color],
CAS Client 在拿到 Service 和新产生的 Ticket 过后,在第 5,6 步中与 CAS Server 进行身份合适,以确保 Service Ticket 的合法性。
在该协议中,[color=red]所有与 CAS 的交互均采用 SSL 协议,确保,ST 和 TGC 的安全性[/color]。协议工作过程中会有 [color=blue]2 次重定向[/color]的过程,但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。
参考:[url=http://baike.baidu.com/view/18179.htm#sub6392359]CAS[/url]