单点登录系统构建之二——SSO原理及CAS架构

基本概念

SSO（Single Sign On）单点登录，是在多个应用系统中，用户只需要登录一次就能访问所有相互信任的应用系统。它包括将这次的主要登录映射到其他应用中用户同一个用户的登录机制。

SSO可以分为Web SSO和桌面SSO，Web SSO体现在客户端，桌面SSO则是操作系统级别的SSO（如登录了Windows就可以使用QQ）。

现在我们所讲的SSO，通常是Web SSO，也就是SSO应用间走Web协议（HTTP/SSL），并且多个应用共享一个SSO入口。

原理介绍

系统角色

User

User可以有多个，User访问Web应用并被SSO认证中心鉴权和授权。

Web应用

Web应用可以有多个，并且受SSO认证中心的保护，是User访问的目标。

SSO认证中心

仅包含一个，用户未授权的访问请求会被重定向到SSO认证中心。

CAS

CAS是耶鲁（Yale）大学发起的一个开源项目，在Java Web SSO中，CAS占据了大约八成的份额，简单时效且足够安全。

CAS的体系结构

CAS Server

CAS Server完成对用户的认证工作，CAS Server需要独立部署，有不止一种CAS Server实现。Yale CAS Server和ESUP CAS Server都是不错的选择。

CAS Server 会处理用户名/密码等凭证，并可能从数据库或其他来源检索用户名和密码，对于这种方式，CAS提供灵活的接口/实现分离方式，意味着CAS Server可以支持任何的认证方式，并且与CAS协议分离。

CAS Client

CAS Client负责部署在客户端（Web应用侧）。当有对本地受保护的Web资源的访问请求，并且需要对请求方进行身份验证，Web应用不再接受任何用户名/密码等类似的Credentials，而是重定向到CAS Server进行认证。

目前CAS Client支持非常多的客户端（Java/PHP/.Net）等。

CAS协议

CAS协议有从v1到v3的版本，在v2版本中开始支持了XML，在v3版本中支持了AOP，因此对于使用Spring开发的项目来说是非常友好的。

CAS协议的基础思想都是基于Kerberos的票据方式。

基础协议

图1 基础模式

CAS Client以Filter的形式保护Web应用的受保护资源，过滤从客户端过来的每一个请求（Step 1）。

CAS Client分析HTTP请求中是否包含Service Ticket，如果没有则重定向到CAS Server（Step 2）。

用户认证过程，如果用户提供了正确的Credentials，CAS Server会产生随机的Ticket，然后缓存该Ticket（Step3），并生成TGC（Ticket Grant Cookie）给User浏览器。

并重定向用户到CAS Client并携带刚才产生的Ticket（Step4）。

CAS Client与CAS Server通过Ticket完成身份认真（Step4和Step5）。

验证成功后，CAS Client对当前Request用户进行服务。

用户再次访问时携带TGC，CAS Server会判断该Cookie的有效性并决定是否再次验证。

CAS代理模式

基础协议已经能够满足绝大多数的场景，但是对于通过service1访问service2这种场景就无能为力了，如果我们对service2也进行验证，从用户角度来说，将会看到频繁的重定向，因此引入了Proxy（代理）模式，由CAS Client代理用户去访问其他Web应用。

代理的前提是需要CAS Client拥有身份信息（类似凭据），用户持有的TGC（Ticket Granted Cookie），而代理持有的是PGT（Proxy Granted Ticket），凭借TGC用户可以免登陆获取其他应用的Service Ticket，同样的，通过PGT，Web应用可以代理用户实现后端认真而无需前端的用户参与。

如何获取PGT？

如下图示，CAS Client在基础协议之上，提供了一个额外的PGT URL给CAS Server，CAS Server通过该接口提供PGT给CAS Client。



图2 Proxy模式

与基础协议不同，在Proxy模式中起作用的是PT（Proxy Ticket），基础模式使用的是ST（Service Ticket）。



图3 代理模式的访问模式

当helloservice需要helloservice2的数据时，helloservice首先使用自己保存的PGT向CAS Server获取PT。

当获取到PT之后，helloservice携带该PT向helloservice2请求数据。

Helloservice2使用该PT向CAS Server验证请求，CAS Server返回验证结果。

Helloservice2此时知道可以合法的为Helloservice服务，从而返回数据。

业界方案

JA-SIG CAS

开源SSO实现中最为成熟的一个，良好的安全性和易用性。

而且CAS客户端有Java，.Net，以及PHP版本，良好支持了现有产品，SSO将会基于CAS进行开发。

http://www.jasig.org/cas

JOSSO

较早的一个实现，但与技术绑定过深，缺乏良好的适用性和文档。

CoSign

类似于CAS的一个实现，CAS Server基于GCI，在C/C++项目中使用较多。

WebAuth

非常早期的SSO方案，使用Perl编写，对Java的支持性很差。

OpenSSO

被甲骨文收购，不再提供支持

CAS安全性

CAS的安全性是非常重要的，从CAS V1到V3，其都依赖与SSL，它假定了用户在一个非常不安全的环境中使用SSO，HTTP传送的密码和Ticket票据都是不安全的。

TGC/PGT的安全性

对于一个CAS用户来说，最重要的事情是保护他的TGC，如果TGC被黑客获取，黑客就会使用该TGC访问所有的应用。

对SSO来说，这种风险是巨大的，因为SSO具有一种门槛效应，一旦登录就会获取相关服务的所有权限。

TGC保存在客户端，其安全性完全有SSL保证。

TGC也有自己的存活周期，在CAS的web.xml中，可以通过grantingTimeout来设置CAS TGC的存活周期。

该周期需要慎重设置，既不影响用户体验，不能带来过高的安全风险（避免被盗用）。

Service Ticket/Proxy Ticket的安全性

Service Ticket/Proxy Ticket是通过HTTP传送的，因此网络中的其他人是可以嗅探到他人的Ticket的。

CAS协议从以下几个方面让ST/PT更加安全。

Service Ticket只能使用一次

Service Ticket一段时间后失效

通过在web.xml中配置如下参数。

<context-param>
<param-name>edu.yale.its.tp.cas.serviceTimeout</param-name>
<param-value>300</param-value>
</context-param>

ST/PT的生成必须足够随机

避免被猜出生成规则

SAML

SAML是OASIS制定的安全性断言标记语言，用于在复杂环境下交互用户的身份识别信息，正在被越来越多的商用产品支持。

SAML与SOAP一样，不考虑具体的传输协议，实际上可以与HTTP/SSL/JMS等任何传输协议捆绑。对于复杂的服务构型，由于不同服务可能有不同的协议，使用CAS将无法完成，因为CAS是基于HTTP/SSL上的，只有SAML能完成这项任务，因为其与传输协议无关。

最后，SAML是一种SSO标准而CVS是一种SSO实现，从CAS的RoadMap中可以看出，其也将很快支持SAML。