jasig-CAS架构
来源:互联网 发布:flash整站源码 编辑:程序博客网 时间:2024/05/16 12:39
http://jasig.github.io/cas/4.0.0/planning/Architecture.html
Architecture
System Components
The CAS server and clients comprise the two physical components of the CAS system architecture that communicate by means of various protocols.
CAS Server
The CAS server is Java servlet built on the Spring Framework whose primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets. An SSO session is created when the server issues a ticket-granting ticket (TGT) to the user upon successful login. A service ticket (ST) is issued to a service at the user’s request via browser redirects using the TGT as a token. The ST is subsequently validated at the CAS server via back-channel communication. These interactions are described in great detail in the CAS Protocol document.
CAS Clients
The term “CAS client” has two distinct meanings in its common use. A CAS client is any CAS-enabled application that can communicate with the server via a supported protocol. A CAS client is also a software package that can be integrated with various software platforms and applications in order to communicate with the CAS server via some authentication protocol (e.g. CAS, SAML, OAuth). CAS clients supporting a number of software platforms and products have been developed.
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
When the term “CAS client” appears in this manual without further qualification, it refers to the integration components such as the Jasig Java CAS Client rather than to the application relying upon (a client of) the CAS server.
Protocols
Clients communicate with the server by any of several supported protocols. All the supported protocols are conceptually similar, yet some have features or characteristics that make them desirable for particular applications or use cases. For example, the CAS protocol supports delegated (proxy) authentication, and the SAML protocol supports attribute release and single sign-out.
Supported protocols:
- CAS (versions 1, 2, and 3)
- SAML 1.1
- OpenID
- OAuth (1.0, 2.0)
Software Components
It is helpful to describe the CAS server in terms of three layered subsystems:
- Web (Spring MVC/Spring Webflow)
- Ticketing
- Authentication
Almost all deployment considerations and component configuration involve those three subsystems. The Web tier is the endpoint for communication with all external systems including CAS clients. The Web tier delegates to the ticketing subsystem to generate tickets for CAS client access. 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.
The authentication system is typically only processing requests at the start of the SSO session, though there are other cases when it can be invoked (e.g. forced authentication).
Architecture
System Components
The CAS server and clients comprise the two physical components of the CAS system architecture that communicate by means of various protocols.
CAS Server
The CAS server is Java servlet built on the Spring Framework whose primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets. An SSO session is created when the server issues a ticket-granting ticket (TGT) to the user upon successful login. A service ticket (ST) is issued to a service at the user’s request via browser redirects using the TGT as a token. The ST is subsequently validated at the CAS server via back-channel communication. These interactions are described in great detail in the CAS Protocol document.
CAS Clients
The term “CAS client” has two distinct meanings in its common use. A CAS client is any CAS-enabled application that can communicate with the server via a supported protocol. A CAS client is also a software package that can be integrated with various software platforms and applications in order to communicate with the CAS server via some authentication protocol (e.g. CAS, SAML, OAuth). CAS clients supporting a number of software platforms and products have been developed.
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
When the term “CAS client” appears in this manual without further qualification, it refers to the integration components such as the Jasig Java CAS Client rather than to the application relying upon (a client of) the CAS server.
Protocols
Clients communicate with the server by any of several supported protocols. All the supported protocols are conceptually similar, yet some have features or characteristics that make them desirable for particular applications or use cases. For example, the CAS protocol supports delegated (proxy) authentication, and the SAML protocol supports attribute release and single sign-out.
Supported protocols:
- CAS (versions 1, 2, and 3)
- SAML 1.1
- OpenID
- OAuth (1.0, 2.0)
Software Components
It is helpful to describe the CAS server in terms of three layered subsystems:
- Web (Spring MVC/Spring Webflow)
- Ticketing
- Authentication
Almost all deployment considerations and component configuration involve those three subsystems. The Web tier is the endpoint for communication with all external systems including CAS clients. The Web tier delegates to the ticketing subsystem to generate tickets for CAS client access. 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.
The authentication system is typically only processing requests at the start of the SSO session, though there are other cases when it can be invoked (e.g. forced authentication).
- jasig-CAS架构
- jasig cas配置过程
- jasig CAS客户端配置
- jasig cas单点登录配置笔记
- 单点登录cas jasig学习笔记
- 使用jasig cas 时汉字乱码
- jasig CAS实现单点登录(数据库认证)
- JASIG-CAS原理抓包解析
- JASIG-CAS原理抓包解析2
- jasig cas github地址和wiki
- jasig CAS实现单点登录(数据库认证)
- jasig CAS实现单点登录(数据库认证)
- JASIG-CAS单点登陆服务端客户端配置
- org.jasig.cas.client.session.SingleSignOutHttpSessionListener
- jasig.cas客户端认证成功后ConnectionTimedout
- Jasig CAS使用手札——一、了解Jasig CAS,简单运行!
- cas 单点登录(SSO)之一: jasig cas-server 安装
- jasig cas单点登录配置笔记之二
- android_仿安卓版微信位置选取的
- linux如何模糊查找一个文件
- ubuntu创建、删除文件及文件夹方法
- Evernote快捷键大全
- php 访问oracle
- jasig-CAS架构
- linux内核字符串转换函数 -- linux内核
- 我的第一个php程序
- ubuntu 14下的双屏显示,安装 显卡驱动
- PHP 单一入口程序
- struts2 跳转类型、 result type=chain、dispatcher、redirect(redirect-action)
- c++pair的用法
- iOS开发那些事--iOS6 UI状态保持和恢复
- python中的requests使用