CAS体系结构

体系结构

系统组件

           CAS服务器和客户端组成的两个物理组件的CAS系统架构，通过各种协议进行通信。

CAS服务器

CAS服务器java Servlet基于Spring框架的首要责任是对用户进行身份验证和授权访问所启用的服务，通常称为CAS客户端，通过发行和验证ticket。一个登录会话时创建服务器发布一张票据授予ticket（TGT）在成功登录的用户。一个服务ticket（ST）发出一个服务请求通过用户的浏览器重定向使用TGT的象征。随后在CAS服务器通过后台通道通信验证。这些相互作用在CAS的协议文档中有很详细的描述。

 CAS客户端

“CAS 客户端”一词在其共同使用中有两个不同的含义。一个CAS客户端是任何CAS启用的应用程序，可以通过一个支持的协议与服务器进行通信。CAS客户端是一个软件包，可以集成不同的软件平台和应用程序以通过一些认证协议的CAS服务器通信（例如CAS，SAML，OAuth）。客户端支持多个软件平台和产品已开发。

平台:

• Apache httpd Server (mod_auth_cas module)
• Java (Java CAS Client)
• .NET (.NET CAS Client)
• PHP (phpCAS)
• Perl (PerlCAS)
• Python (pycas)
• Ruby (rubycas-client)

相关应用:

• Outlook Web Application (ClearPass + .NET CAS Client)
• Atlassian Confluence
• Atlassian JIRA
• Drupal
• Liferay
• uPortal

当“CAS客户端”出现在本手册中没有进一步的资格，它是指集成组件如jasig java CAS客户端而不是应用程序依赖于（客户）CAS服务器。

协议：

客户端通过任何支持的协议与服务器进行通信。所有支持的协议在概念上是相似的，但一些有功能或特性，

使他们理想的特定的应用程序或用例。例如，CAS协议支持委托（代理）认证，和SAML协议支持属性的释放和单点登出。

支持协议:

• CAS (versions 1, 2, and 3)
• SAML 1.1
• OpenID
• OAuth (1.0, 2.0)

软件组成：

它有助于描述CAS 服务器在三个分层子系统：

• Web (Spring MVC/Spring Webflow)
• Ticketing
• Authentication

几乎所有的部署注意事项和组件配置都涉及这三个子系统。Web层是与所有包括cas客户端的所有外部系统通信的端点。Web层的委托给ticketing子系统生成的客户端访问的门票。单点登录会话开始的授票成功的身份验证票的发行，因此ticketing子系统经常代表认证子系统。
认证系统通常只处理请求的单点登录会话的开始，虽然有其他案件时可以调用（例如强制认证）。

spring 框架

CAS使用Spring框架的许多方面；最值得注意的是，Spring MVC and Spring Webflow。spring 提供核心的CAS代码完整的和可扩展的框架，以及部署；

它直接定制或通过挂和spring 的API扩展点扩展CAS，CAS行为。春天的一般知识，有利于了解一些框架构件之间的相互作用，但它不是严格要求。然而，

用于配置CA和Spring组件的基于XML的配置是安装、定制和扩展的核心关注点。能力与XML一般和spring国际奥委会的容器，特别是CA安装的先决条件。