CAS实施SSO单点登录原则

CAS（中央身份验证服务）是由耶鲁大学发起的企业级开源项目，旨在为Web应用程序系统（属于Web SSO）提供可靠的单点登录解决方案.

CAS从2001年开始，并于2004年12月正式成为JA-SIG项目.

1. 开源，多协议SSO解决方案；协议: 自定义协议，CAS，OAuth，OpenID，RESTful API，SAML1.1，SAML2.0等.

2. 支持多种身份验证机制: Active Directory，JAAS，JDBC，LDAP，X.509证书等；

3. 安全策略: 使用票证实现支持的身份验证协议；

4. 支持授权: 您可以决定哪些服务可以请求并验证服务票证；

5. 提供高可用性: 通过将经过身份验证的状态数据存储在TicketRegistry组件中，这些组件具有许多支持分布式环境的实现，例如: BerkleyDB，Default，EhcacheTicketRegistry，JDBCTicketRegistry，JBOSS TreeCache，JpaTicketRegistry，MemcacheTicketRegistry等；

6. 支持多个客户端: Java，.Net，PHP，Perl，Apache，uPortal等.

本文重点介绍Web SSO.

单点登录（简称SSO）是用于企业业务集成的更流行的解决方案之一. SSO使用户一次登录即可访问多个应用程序系统中的所有其他系统. 受信任的应用程序.

一般的SSO系统有三个主要角色:

1，用户（多个）

2. Web应用程序（多个）

3. SSO认证中心（1）

SSO实施模式通常包括以下三个原则:

1. 所有身份验证登录均在SSO身份验证中心中进行；

2. SSO身份验证中心通过某些方法告诉Web应用程序当前访问的用户是否是经过身份验证的用户；

3. SSO证书颁发机构与所有Web应用程序建立信任关系，这意味着Web应用程序必须信任证书颁发机构. （单点信任）

SSO的主要实现方法是:

基于同一域的共享cookie是Web开头使用的一种方法. 它使用在浏览域之间自动传递cookie的机制来实现两个域之间的系统令牌传输. 另外，关于跨域问题是，尽管cookie本身并不跨域，但它们可用于实现跨域SSO. 例如: 代理，公开SSO令牌值等.

缺点: 它不灵活并且具有许多安全风险. 它已经被遗弃了.

此技术的特点是具有集中式身份验证和用户帐户管理服务器. 经纪人提供电子身份访问权限，以用于进一步的请求. 中央的使用减少了管理成本，并提供了公共的和独立的“第三方”进行身份验证. 例如Kerberos，Sesame，IBM KryptoKnight（凭证库提示）等. Kerberos是麻省理工学院发明的一种安全认证服务，已被UNIX和Windows集成为默认安全认证服务.

在此解决方案中，有一个代理可以自动为不同应用程序验证用户身份. 该代理需要设计为具有不同的功能. 例如，它可以使用密码表或加密密钥自动消除用户的身份验证负担. 代理放置在服务器上，并充当服务器的身份验证系统和客户端身份验证方法之间的“转换”. 例如，SSH.

例如，SecureIDibm portal 单点登录，WebID，现在广泛使用的密码认证（例如FTP，邮件服务器登录认证），这是一种实现在各种应用程序中使用的密码的简便方法.

SAML（安全断言标记语言）的出现极大地简化了SSO，并被OASIS批准为SSO的实施标准. 开源组织OpenSAML实施SAML规范.

从结构系统的角度来看，CAS包括两个部分: CAS Server和CAS Client.

CAS Server负责用户的身份验证. 它需要独立部署. CAS Server将处理用户名/密码等凭据.

负责处理对客户端受保护资源的访问请求. 当需要对请求者进行身份验证时，请重定向到CAS服务器进行身份验证. （原则上，客户端应用程序不再接受用户名和密码之类的任何凭据. ）

CAS客户端与受保护的客户端应用程序一起部署，以在筛选器模式下保护受保护的资源.

基本模式SSO访问过程主要包括以下步骤:

1. 访问服务: SSO客户端发送请求以访问应用程序系统提供的服务资源.

2. 定向身份验证: SSO客户端会将用户请求重定向到SSO服务器.

3. 用户身份验证: 用户身份验证.

4. 发出票证: SSO服务器将生成随机服务票证.

5. 验证票证: SSO服务器验证服务票证的合法性. 验证通过后，允许客户端访问服务.

6. 传输用户信息: SSO服务器验证票证是否通过后，它将用户身份验证结果信息传输到客户端.

以下是CAS的基本协议:

基本协议图

如上所示: CAS客户端与受保护的客户端应用程序一起部署，以在“筛选器”模式下保护Web应用程序的受保护资源，过滤来自客户端的每个Web请求，然后CAS客户端分析HTTP请求. 是否包括对服务票证的请求（上图中的票证），

如果没有，则表明用户未通过身份验证；

然后，CAS客户端会将用户请求重定向到CAS服务器（步骤2）并传递服务（要访问的目标资源地址）.

步骤3是用户身份验证过程. 如果用户提供了正确的凭据，则CAS服务器会随机生成一个长度很长，唯一且不可伪造的服务凭单，将其缓存以备将来验证，然后将用户重定向到该服务的地址（（仅生成了服务凭单），并为客户端浏览器设置票证授予的Cookie（TGC）；

在获取服务和新生成的票证之后，CAS客户端会在步骤5和步骤6中与CAS服务器检查身份，以确保服务票证的合法性.

在此协议中，与CAS Server的所有交互都使用SSL协议来确保ST和TGC的安全性. 协议工作期间将有2个重定向. 但是，CAS客户端和CAS Server之间的票证验证过程对用户是透明的（使用HttpsURLConnection）.

CAS请求认证序列图如下:

当访问另一个应用程序服务的用户再次重定向到CAS Server时，CAS Server将主动获取此TGC cookie，然后执行以下操作:

1）如果用户持有TGC并且尚未过期，则请转到基本协议图的步骤4以达到SSO的效果；

2）如果TGC失败，用户仍然需要重新认证（基本协议图的步骤3）.

这种模式是用户访问App1，而App1依赖于App2来获取一些信息，例如: User-> App1-> App2.

在这种情况下，假设App2还需要对用户进行身份验证才能访问，那么，为了不影响用户体验（重定向次数过多，导致用户的IE窗口不断闪烁），CAS引入了代理身份验证机制，也就是说，CAS客户端可以代理用户访问其他Web应用程序.

代理的前提是CAS客户端必须具有用户的身份信息（类似于凭据）. 我们前面提到的TGC是用户为自己的身份信息持有的凭据，这里的PGT是CAS客户端所拥有的用户身份信息的凭据. 使用TGC，用户可以避免输入密码来获取用于访问其他服务的服务票证. 因此，使用此处的PGT，Web应用程序可以代理用户以实现后端身份验证，而无需前端用户的参与.

以下是通过代理应用程序（helloService）获取PGT的过程: （注意: PGTURL用于表示代理服务，是回调链接； PGT等效于代理证书； PGTIOU是实现此操作的关键获取代理证书并用于与PGT关联关系；）

如上面的CAS代理图中所示，当在基本协议之上验证ST时，CAS客户端会向CAS服务器提供附加的PGT URL（和SSL条目），以便CAS服务器可以通过PGT URL. 将PGT授予CAS客户端.

CAS客户端可以获取PGT（PGTIOU-85….ti2td），然后可以通过PGT对后端Web应用程序进行身份验证.

以下是代理身份验证和服务提供的过程:

如上图所示，代理身份验证与普通身份验证没有太大区别. 步骤1和2与基本模式的步骤1和2几乎相同. 唯一的区别是代理模式使用PGT而不是TGC，它是代理票证. （PT）代替服务凭单.

CAS的SSO实现可以简化为: 1个cookie和N个会话. CAS Server创建一个cookie，该cookie将在所有应用程序中用于身份验证. 每个应用程序都会创建自己的会话，以识别用户是否已登录.

用户通过应用程序的身份验证后，将来当用户在同一浏览器中访问该应用程序时，客户端应用程序中的筛选器将在会话中读取用户信息，因此它们将不会转到CAS服务器身份验证. 如果您在此浏览器中访问其他Web应用程序，则如果客户端应用程序中的过滤器无法读取会话中的用户信息，它将进入CAS服务器的登录界面进行身份验证，但CAS Server则会读取浏览器Cookie（TGC） ）从服务器发送，因此CAS Server不会要求用户进入登录页面进行登录，而是会根据服务参数生成票证，然后与Web应用程序进行交互以验证票证.

在CAS系统中设计了五张票证: TGC，ST，PGT，PGTIOU，PT.

票务授权cookie（TGC）: 一种存储用户身份验证凭据的cookie. 它在浏览器和CAS Server之间的通信期间使用，并且只能通过安全通道（Https）进行传输. CAS服务器用于识别用户的身份. 凭据；

Ø服务票证（ST）: 服务票证，由CAS服务器发布（Http传输）并通过客户端浏览器到达业务服务器的服务的唯一标识码；特定服务只能具有唯一的ST；

ØProxy-Granting票证（PGT）: 由CAS服务器颁发给具有ST凭据的服务. PGT绑定了用户的特定服务，因此它可以应用于CAS Server并获得PT；

Ø授予代理身份的凭单（PGTIOU）: 当将证书验证从CAS服务器传递到CAS客户端时，该角色将返回响应信息. 同时，对应于PGTIOU的PGT将通过回调链接传递到Web应用程序. Web应用程序负责维护PGTIOU和PGT之间的映射关系的内容表；

Ø代理票证（PT）: 这是应用程序代理用户访问目标程序的凭据；

其他说明如下:

票证授予票证（TGT）: 票证批准票证，由KDC的AS发布. 也就是说，在获得这样的票证之后，不再需要在申请各种其他服务票证（ST）之后向KDC提交身份认证信息（凭据）；

Ø身份验证服务（AS）---------身份验证服务，请求凭据，颁发TGT；

Ø机票授予服务（TGS）---------机票授予服务，要求TGT，签发ST；

ØKDC（密钥分发中心）----------密钥分发中心；

CAS安全仅依赖于SSL. 使用安全的Cookie.

对于CAS用户，最重要的是保护其TGC. 如果TCAS是由CAS服务器以外的其他实体意外获取的，则Hacker可以找到TGC，然后假冒CAS用户访问所有授权资源. PGT的角色与TGC相同.

从基本模式可以看出，CAS服务器通过SSL将TGC发送给最终用户. 因此，为了确保CAS的安全性，拦截TGC十分困难.

TGT生存期默认为120分钟.

ST（服务票证）是通过Http传输的ibm portal 单点登录，因此网络上的其他人可以嗅探到其他人的票证. CAS通过以下几个方面使ST更加安全（实际上，它们是可配置的）:

1，ST只能使用一次

CAS协议规定，无论服务票证验证是否成功，CAS服务器都会清除服务器缓存中的票证，从而确保服务票证不被使用两次.

2，ST在一段时间内失败

CAS规定ST只能生存一定的时间，然后CAS Server将使其无效. 默认有效时间为5分钟.

3，ST是根据随机数生成的

ST必须足够随机. 如果猜中了ST生成规则，那么Hacker等同于绕过CAS身份验证并直接访问相应的服务.

1

2

3

4

5

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-158462-1.html