《CAS原理简介电子教案》由会员分享，可在线阅读，更多相关《CAS原理简介电子教案（15页珍藏版）》请在金锄头文库上搜索。
1、CAS原理简介精品文档密基础软件事业部CAS原理简介收集于网络，如有侵权请联系管理员删除 更改履历版本号更改时间更改的图表和章节号状态更改简要描述更改申请编号更改人批准人0.12016-08-17gaoxiang注：状态可以为N-新建、A-增加、M-更改、D-删除目录第1章 CAS简介31.1 什么是CAS31.2 主要特性3第2章 SSO单点登录原理42.1 什么是SSO42.2 SSO体系中的角色42.3 SSO实现模式的原则4第3章 CAS的基本原理53.1 结构体系53.1.1 CAS Server53.1.2 CAS Client53.2 CAS原理和协议53.2.1 基础模式53.
2、2.2 CAS如何实现SSO73.2.3 CAS请求认证时序图8第4章 附录 术语解释11第1章 CAS简介1.1 什么是CASCAS （ Central Authentication Service ） 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。CAS 开始于 2001 年， 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。1.2 主要特性1、 开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、
3、RESTful API 、 SAML1.1 、 SAML2.0 等。2、 支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等；3、 安全策略：使用票据（ Ticket ）来实现支持的认证协议；4、 支持授权：可以决定哪些服务可以请求和验证服务票据（ Service Ticket ）；5、 提 供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现， 如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、
4、JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等；6、 支持多种客户端： Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。第2章 SSO单点登录原理2.1 什么是SSO单点登录（ Single Sign-On , 简称 SSO ）是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只需要 登录一次 就可以访问所有相互信任的应用系统。2.2 SSO体系中的角色一般 SSO 体系主要角色有三种：1、 Use
5、r （多个）2、 Web 应用（多个）3、 SSO 认证中心（ 1 个 ）2.3 SSO实现模式的原则SSO 实现模式一般包括以下三个原则：1、 所有的认证登录都在 SSO 认证中心进行；2、 SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是已通过认证的用户；3、 SSO 认证中心和所有的 Web 应用建立一种信任关系，也就是说 web 应用必须信任认证中心。（单点信任）2.4 SSO优势SSO将一个企业内部所有域中的用户登录和用户帐号管理集中到一起，SSO的好处显而易见：1. 减少用户在不同系统中登录耗费的时间，减少用户登录出错的可能性2. 实现安全的同时避免了处理和保
6、存多套系统用户的认证信息3. 减少了系统管理员增加、删除用户和修改用户权限的时间4. 增加了安全性：系统管理员有了更好的方法管理用户，包括可以通过直接禁止和删除用户来取消该用户对所有系统资源的访问权限第3章 CAS的基本原理3.1 结构体系从结构体系看， CAS 包括两部分： CAS Server 和 CAS Client 。3.1.1 CAS ServerCAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials) 。3.1.2 CAS Client负责处理对客户端受保护资源的访问请求，需要对请求方进行身份
7、认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。3.2 CAS原理和协议3.2.1 基础模式基础模式 SSO 访问流程主要有以下步骤：1. 访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。2. 定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。3. 用户认证：用户身份认证。4. 发放票据： SSO 服务器会产生一个随机的 Service Ticket 。5. 验证票据： SSO 服务器验证票据 Se
8、rvice Ticket 的合法性，验证通过后，允许客户端访问服务。6. 传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。下面是 CAS 最基本的协议过程：如上图： CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同 时， CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的；于是 CAS Client 会重定向用户请求到 CAS Server （ Step
9、 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 进行身份核实，以
10、确保 Service Ticket 的合法性。在该协议中，所有与 CAS Server 的交互均采用 SSL 协议，以确保 ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向 的过程。但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的（使用 HttpsURLConnection ）。3.2.2 CAS如何实现SSO当用户访问另一个应用的服务再次被重定向到 CAS Server 的时候， CAS Server 会主动获到这个 TGC cookie ，然后做下面的事情：1) 如果 User 持有 TGC 且其还没失效，那么就走基础协议
11、图的 Step4 ，达到了 SSO 的效果；2) 如果 TGC 失效，那么用户还是要重新认证 ( 走基础协议图的 Step3) 。3.2.3 CAS请求认证时序图3.2.3.1 第一次访问应用cas流程图：3.2.3.2 再次访问应用：3.2.3.3 访问其他应用：第4章 附录 术语解释Ticket-granting cookie(TGC) ：存放用户身份认证凭证的 cookie ，在浏览器和 CAS Server 间通讯时使用，并且只能基于安全通道传输（ Https ），是 CAS Server 用来明确用户身份的凭证；Service ticket(ST) ：服务票据，服务的惟一标识码 ,
12、由 CAS Server 发出（ Http 传送），通过客户端浏览器到达业务服务器端；一个特定的服务只能有一个惟一的 ST ；Proxy-Granting ticket （ PGT ）：由 CAS Server 颁发给拥有 ST 凭证的服务， PGT 绑定一个用户的特定服务，使其拥有向 CAS Server 申请，获得 PT 的能力；Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是将通过凭证校验时的应答信息由 CAS Server 返回给 CAS Client ，同时，与该 PGTIOU 对应的 PGT 将通过回调链接传给 Web 应用。 Web
13、 应用负责维护 PGTIOU 与 PGT 之 间映射关系的内容表；Proxy Ticket (PT) ：是应用程序代理用户身份对目标程序进行访问的凭证；Ticket Granting ticket(TGT) ：票据授权票据，由 KDC 的 AS 发放。即获取这样一张票据后，以后申请各种其他服务票据 (ST) 便不必再向 KDC 提交身份认证信息 (Credentials) ；Authentication service(AS) - 认证用服务，索取 Credentials ，发放 TGT ；Ticket-granting service (TGS) - 票据授权服务，索取 TGT ，发放 ST ；KDC( Key Distribution Center ) - 密钥发放中心；
