CAS 之 Apereo CAS 简介（一）

CAS 之 Apereo CAS 简介（一）

Background（背景）

随着公司业务的不断扩展，后台接入子系统不断增多，那么咱们将针对不一样的平台进行拆分为各自对应的子系统，
权限是不变的，那么咱们不能每一个子系统都单独进行登陆认证，否则管理人员进行切换系统时会疯掉。
那么，通过考察选用开源框架 Apereo CAS , 选定版本为 5.2.0。目前系统已在线，并已稳定。
接下来我会将系统进行脱敏整理出一套完善的基于微服务的CAS单点系统实施方案。
因为CAS是相对比较大的工程，因此建议使用者认真阅读官方文档进行调整。

---

Intro（介绍）

Central Authentication Service (CAS)，一般称为CAS。 CAS是一种针对Web的企业多语言单点登陆解决方案，并尝试成为您的身份验证和受权需求的综合平台。

下面是官方的一段简述：

CAS Enterprise Single Sign-On

• Spring Webflow/Spring Boot Java server component.
• 可拔插认证支持 (LDAP, Database, X.509, SPNEGO, JAAS, JWT, RADIUS, MongoDb, etc)
• 多种协议支持 (CAS, SAML, WS-Federation, OAuth2, OpenID, OpenID Connect, REST)
• 经过各类提供商支持多因素身份验证 (Duo Security, FIDO U2F, YubiKey, Google Authenticator, Microsoft Azure, Authy etc)
• 支持外部提供者的委托认证，例如： ADFS, Facebook, Twitter, SAML2 IdPs, etc.
• Built-in support for password management, notifications, terms of use and impersonation.
• Support for attribute release including user consent.
• 实时监控和跟踪应用程序行为，统计信息和日志。
• 用特定的认证策略管理和注册客户端应用程序和服务。
• 跨平台的客户端支持 (Java, .Net, PHP, Perl, Apache, etc).
• Integrations with InCommon, Box, Office365, ServiceNow, Salesforce, Workday, WebAdvisor, Drupal, Blackboard, Moodle, Google Apps, etc.

由以上能够看出， Central Authentication Service (CAS) 支持的功能普遍。

Architecture（架构）

System Components （系统组件）

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

CAS Server（CAS服务器）

CAS服务器是基于Spring框架构建的Java servlet，其主要职责是验证用户并经过发布和验证票证来授予对启用CAS的服务（一般称为CAS客户端）的访问权限。 当服务器在成功登陆时向用户发出票证授予票证（TGT）时，将建立SSO会话。 根据用户的请求，经过使用TGT做为标记的浏览器重定向向服务发出服务票据（ST）。 ST随后经过反向信道通讯在CAS服务器上进行验证。 CAS Protocol文档中详细描述了这些交互。

CAS Clients（CAS客户端）

术语“CAS客户”在其通用中有两个不一样的含义。 CAS客户端是能够经过支持的协议与服务器进行通讯的任何CAS支持的应用程序。 CAS客户端也是一个软件包，能够与各类软件平台和应用程序集成，以便经过某种身份验证协议（例如CAS，SAML，OAuth）与CAS服务器进行通讯。 已经开发了支持多种软件平台和产品的CAS客户端。

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:（平台）

• Canvas
• Atlassian Confluence
• Atlassian JIRA
• Drupal
• Liferay
• uPortal
• …

Supported Protocols （支持协议）

客户端经过几种支持的协议与服务器进行通讯。 全部支持的协议在概念上都是类似的，但有些协议的特征或特征使得它们适用于特定的应用程序或用例。 例如，CAS协议支持委托（代理）认证，而且SAML协议支持属性发布和单一注销。

Supported protocols:

• CAS (versions 1, 2, and 3)
• SAML 1.1 and 2
• OpenID Connect
• OpenID
• OAuth 2.0
• WS Federation

Software Components（软件组件）

根据三层子系统来描述CAS服务器是有帮助的：

• Web（Spring MVC / Spring Webflow）
• Ticketing
• Authentication

几乎全部的部署考虑和组件配置都涉及这三个子系统。 Web层是与包括CAS客户端在内的全部外部系统进行通讯的端点。 Web层委托票务子系统为CAS客户端访问生成票证。 SSO会话以成功认证时颁发票证授予票证开始，所以票务子系统常常委托给认证子系统。
认证系统一般只在SSO会话开始时处理请求，尽管还有其余状况能够调用它（例如强制认证）。

Conclusions（结论）

由上图能够看出， Central Authentication Service (CAS) 在不少大公司内进行了很好的应用。

Recommendations（建议）

It is recommended to deploy CAS locally using the WAR Overlay method.

1. 建议使用WAR Overlay方法在本地部署CAS。
2. 建议明白几点
   • 2.1 何种应用在何种状况下产生何种事物用于何种目的，白话一点就是要清楚 一种事物的生命周期及变换过程。
   • 2.2 一种新的事物的产生必然有其原因，知其然知其因此然 才能不断地成长。
   • 2.3 通常状况下，相对完善的事物产生的同时，都会有与之对应的文档。那么学习的最好途径就是仔细阅读实践。
   • 2.4 即便是官方推出的，对自身应用来说也不必定是最好的，要根据实际状况进行对应的实践验证。
   • 2.5 尽信书不如无书。

---

参考资料

Apereo CAS
https://github.com/apereo/cas

---

原创声明

做者：随风浮云
出处：http://www.cnblogs.com/ljmatlight 本文版权归做者全部，欢迎转载，但未经做者赞成必须保留此段声明。 文中有不妥或者错误的地方，欢迎勘误，若是你有更好的建议，能够给我留言讨论，共同进步。 互联网技术时效性较强，引用请慎重。