SSO解决方案汇总

Posted on | In

0.概述

SSO英文全称Single Sign On（单点登录）。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一.

随着SSO技术的流行，SSO的产品也是满天飞扬。所有著名的软件厂商都提供了相应的解决方案。常见的开源解决方案有：JA-SIG CAS、OpenSSO、JOSSO、Passport.js、Atlassian Crowd、GodAuth等。商业解决方案有Tivoli、Siteminder、RSA Secure SSO等。商业产品的安全性和用户体验比开源的相对来说比较好点。但是接触最多的还属于开源的方案。

基本上SSO的实现分为3类：基于WEB的WEB SSO、基于Windows域的桌面SSO、SAML(Security Assertion Markup Language安全断言标记语言)。

1.SSO原理

1.1 SSO体系中的角色

1.User （多个）

2.Web 应用（多个）

3.SSO 认证中心（ 1 个 ）

1.2 SSO 实现模式的原则

1.所有的认证登录都在 SSO 认证中心进行；

2.SSO 认证中心通过一些方法来告诉 Web 应用当前访问用户究竟是不是已通过认证的用户；

3.SSO 认证中心和所有的 Web 应用建立一种信任关系，也就是说 web 应用必须信任认证中心。（单点信任）

1.3 SSO 主要实现方式

1.共享 cookies

基于共享同域的 cookie 是 Web 刚开始阶段时使用的一种方式，它利用浏览同域名之间自动传递 cookies 机制，实现两个域名之间系统令牌传递问题；另外，关于跨域问题，虽然 cookies本身不跨域，但可以利用它实现跨域的 SSO 。如：代理、暴露 SSO 令牌值等。

缺点：不灵活而且有不少安全隐患，已经被抛弃。

2.Broker-based(基于经纪人)

这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的 “第三方 “ 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （凭证库思想 ) 等。 Kerberos是由麻省理工大学发明的安全认证服务，已经被 UNIX 和 Windows 作为默认的安全认证服务集成进操作系统。

3.Agent-based(基于代理人)

在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个 “ 翻译 “。例如 SSH 等。

4.Token-based

例如 SecureID,WebID ，现在被广泛使用的口令认证，比如 FTP 、邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。

5.基于网关

在网关处实现身份认证。

6.基于SAML

SAML(Security Assertion Markup Language ，安全断言标记语言）的出现大大简化了 SSO ，并被 OASIS 批准为 SSO 的执行标准 。开源组织 OpenSAML 实现了 SAML 规范。

2.SSO开源解决方案-CAS概述

CAS(Central Authentication Service) 是 Yale 大学发起的一个开源项目，据统计使用开源SSO方案的大部分选择CAS，CAS简单高效并且足够安全。这也是本文介绍的主角。

2.1 CAS的特征:

  • 开源的、多协议:支持的协议包括 Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。
  • 支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等。
  • 安全策略：使用票据(Ticket)来实现支持的认证协议。
  • 支持授权:可以决定哪些服务可以请求和验证服务票据(Service Ticket)。
  • 高可用性支持：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、 JDBCTicketRegistry 、 JBOSS TreeCache 、 JpaTicketRegistry 、 MemcacheTicketRegistry 等。
  • 支持多种客户端: Java 、 .Net 、 PHP 、 Perl 、 Apache, uPortal 等。

2.2 CAS的结构体系

从结构体系看， CAS 包括两部分： CAS Server 和 CAS Client 。

CAS Server

CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证(Credentials) 。

CAS Client

负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。

2.3 CAS原理和协议

CAS协议是由Drew Mazurek编写，最新版本为3.0.1，发布时间为:2015-01-13。

从 CAS v1 到现在的 CAS v3 ，整个协议的基础思想都是基于 Kerberos 的票据方式。

CAS v1 非常原始，传送一个用户名居然是 ”yes”ndavid.turing” 的方式， CAS v2 开始使用了 XML 规范，大大增强了可扩展性， CAS v3 开始使用 AOP 技术，让 Spring 爱好者可以轻松配置 CAS Server 到现有的应用环境中。

CAS 是通过 TGT(Ticket Granting Ticket) 来获取 ST(Service Ticket) ，通过 ST 来访问服务，而 CAS 也有对应 TGT ， ST 的实体，而且他们在保护 TGT 的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。

CAS协议分为基础模式和代理模式两种。

CAS协议官方规范

2.3.1 基础模式的认证过程：

基础模式-时序图

CAS服务端控制台日志：

CAS服务端控制台

2.3.2 代理模式的认证过程：

代理模式-时序图

3.CAS安全性

CAS 的安全性仅仅依赖于 SSL，使用的是 secure cookie，CAS 协议从几个方面让认证变得更加安全。

有关CAS安全特性，请看CAS v4 安全手册

3.1 TGC/PGT 安全性

对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问 所有 授权资源。 PGT 的角色跟 TGC 是一样的。

从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。

TGT 的存活周期默认为 120 分钟。

3.2 ST/PT 安全性

ST （ Service Ticket ）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）：

1、ST 只能使用一次

CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该Ticket ，从而可以确保一个 Service Ticket 不被使用两次。

2、ST 在一段时间内失效

CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。默认有效时间为 5 分钟。

3、ST 是基于随机数生成的

ST 必须足够随机，如果 ST 生成规则被猜出， Hacker 就等于绕过 CAS 认证，直接访问 对应的服务。