CAS 文档
CAS基本介绍
-
CAS简介
CAS是Central Authentication Service的缩写，中央认证服务，一种独立开放指令协议，
为国外大学所发起的一个开源项目。
CAS目标
CAS主要目的是为企业各应用系统提供一个统一的认证，即SSO(Single Sign-On)单点登录，
如果企业有多个系统，用户需要访问各个系统，则需要每次登录该系统地址，进行认证，比较
麻烦，不便于管理，而CAS的出现则是为了解决该问题，只需要在一处登录认证，即可访问
所有授权的系统，极大的提高了操作的便利。
CAS优点
a、一个开放的文件化协议
b、一个开源的Java 服务组件
c、支持灵活的插件化认证(eg:LDAP, database, X.509, 2-factor)
d、支持多种协议(eg:CAS, SAML, OAuth, OpenID)
e、跨平台客户端支持(eg:Java, .Net, PHP, Perl, Apache, uPortal等)
f、提供了和 uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle等集成
-
CAS架构
-
System Components
CAS server 与CAS Client 通过各种各样的协议进行连接
CAS Server
a、CAS Server 是构建于Spring 框架的Java Servlet.
b、主要职责为 认证用户和保证CAS Clients 访问CAS内置的services
c、TGT 为用户成功登录后CAS server发行的 ticket-granting ticket (TGT)
d、SSO(单点登录)的Session是在Server发行TGT的时候创建的
e、ST(service ticket) 是在用户携带TGT当做token(令牌)通过浏览器重定向
请求service的时候CAS Server发行的，CAS server也会验证ST.
f、具体的交互在CAS协议中详细描述
CAS Clients
a、CAS Clients是CAS内置的一些通过支持的协议与Server通信的程序
b、CAS Clients 也是内置的软件包可与各种各样的软件平台和程序集成，通过
各种各样的认证协议(e.g. CAS, SAML, OAuth)与CAS Server通信
Platforms:
Apache httpd Server (mod_auth_cas module)
Java (Java CAS Client)
.NET (.NET CAS Client)
PHP (phpCAS)
Perl (PerlCAS)
Python (pycas)
Ruby (rubycas-client)
Applications:
Outlook Web Application (ClearPass + .NET CAS Client)
Atlassian Confluence
Atlassian JIRA
Drupal
Liferay
uPortal
Protocols协议
Clients 通过Server支持的各种协议与Server通信，所有协议概念上相似，根据程序的
使用有一些个性和特性不同，eg: CAS protocol 支持集成代理认证， SAML protocol
支持属性发行和single sign-out.
Supported protocols:
CAS (versions 1, 2, and 3)
SAML 1.1
OpenID
OAuth (1.0, 2.0)
Software Components
从下述三个子系统来描述CAS Server是非常有用的：
Web (Spring MVC/Spring Webflow)
Ticketing
Authentication
几乎所有的部署和组件配置都涉及到这三个子系统,Web 层是一个端点用于和所有外部
系统包括CAS Clients通信.web 层集成了Ticketing子系统，用于生成CAS clients
访问的tickets.
The SSO session begins with the issuance of a
ticket-granting ticket on successful authentication, thus the
ticketing subsystem frequently delegates to the authentication
subsystem.
Authentication 系统仅仅处理SSO Session 开始的请求,尽管也有一些如强制验证也
涉及到该Authentication系统
Authentication认证
CAS 的认证主要通过一系列相关组件来处理的：
1、PrincipalNameTransformer(凭据名称转换器)
将登录表单输入的用户id字符串转换为Principal Name，尝试指定类型的
认证处理器 认证。
2、AuthenticationManager(认证管理器)
认证系统的入口点,它接受一个或多个凭据和委托认证通过 AuthenticationHandler
配置的组件,它收集每次尝试的结果并确定有效的安全策略。
3、AuthenticationHandler(认证处理器)
认证单个凭据并且返回认证的结果，该返回值只有三种值分别为 Success(成功)、
Failure(失败)、Indeterminate(没有尝试).
4、PrincipalResolver(凭据解析器)
将认证的凭据通过策略转换为安全的凭据，通常包含添加额外是属性(eg:email,
display name)
5、AuthenticationMetaDataPopulator(认证元数据操作者)
是给成功认证的事件设置随机的元数据的策略组件，这些通常使用协议约束的元数据,
除非特别声明，所有的认证组件处理都是在 deployerConfigContext.xml配置的
CAS时序图
CAS协议服务认证请求处理过程
请求访问app
1、通过浏览器(GET)访问 "http://app.example.com/'，通过CAS协议访问CAS客户端
受保护的App.
2、CAS 客户端发现访问是没有认证的,所以携带着配置的Service查询参数重定向到CAS进行
认证,对URL:"http://app.example.com/"进行加密.
3、浏览器地址此时为："http://app.example.com/cas/login?service=
https%3A%2F%2Fapp.example.com%2F",再GET该地址请求CAS Server.
4、CAS Server 发现用户此时没有SSO Session,所以重定向到login表单页面.
5、用户录入登录信息，Post提交："http://app.example.com/cas/login?
service= https%3A%2F%2Fapp.example.com%2F",重新请求到CAS Server,
认证用户名、密码、ticket ,用户认证成功，则创建SSO Session CASTGC cookie
包含了这个TGT(Ticket Granting Ticket),这个TGT是该用户的SSO Session key.
6、CAS 设置cookie,包含CASTGC=TGT-2345678 重定向"http://app.example.com/
?ticket=ST-12345678"请求CAS 客户端
7、CAS 客户端校验来自CAS Server携带的Ticket(ST)，通过调用 GET "http://app.
example.com/serviceValidate?service= https%3A%2F%2Fapp.example.com%2F&
ticket=ST-12345678"请求CAS Server.
8、CAS Server 返回包含成功的标识、认证的对象和可选属性的XML文档
9、CAS 客户端设置session和cookie,重新取消ST的展示，该步骤为可选择的,主要防止
浏览器地址展示ST，设置后的Cookie:JSESSIONID=ABC1234567,重定向地址到
"http://app.example.com/"
10、浏览器携带Cookie:JSESSIONID=ABC1234567 GET "http://app.example.com/"
请求CAS 客户端
11、CAS 客户端校验 Session cookie ,返回请求app的资源页面
12、浏览器展示 app 资源信息