共计 1416 个字符，预计需要花费 4 分钟才能阅读完成。
为什么要做这个尝试？
微服之道，方兴未艾；农之来学者，盖已千者！这句是从《陶山集·太学案问》瞎改出来的。意思就是微服务的架构理念还在不断地发展，现在整个啥都 言必出微服务，差点都到了 没学过微服务的码农不是一个好码农。搞到微服务这个词都快跟区块链差不多臭了。
在将臭未臭之前，我们赶紧把其中的统一认证这块过一下。
在微服务的概念中，恨不得每一个 API 都起一个独立的微服务，所有一个系统有几十个，甚至成百上千个独立的微服务也不见怪。而安全又是每一个服务都必须面对的问题！如果让每一个微服务都独立处理的话，那 Martin Fowler 估计早就被码农拉去祭天了。所以统一认证大势所趋，将安全有关的认证与授权集中到一个服务中进行处理，各个微服务只需简单校验即可，无需另起炉灶！
统一认证的开源实现有很多，目前比较出名的有 Apereo CAS（发音为 /kæ’s/），Keycloak 等，我们尽量都介绍到，今天先看一下 Apereo CAS
什么是 Apereo CAS
首先 CAS 是 Central Authentication Service 的首字母缩写，Apereo CAS 是由耶鲁大学实验室 2002 年出的一个开源的统一认证服务。
据官网介绍，Apereo CAS 是一个开源的企业级单点登录系统，包括了如下特性：
基于 SpringBoot 开发的 Java 系统
一个开放且各种手册齐全的协议
以可插拔的形式支持各种认证协议 (LDAP, database, X.509, 2-factor)
支持各种认证协议 (CAS, SAML, OAuth, OpenID)
各种客户端应有尽有（Java, .Net, PHP, Perl, Apache, uPortal）
跟各种 不大出名 的系统集成 (uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle)
社区文档大把，有问题就吹街
Apereo CAS 的架构与组成
码农上手一个新东西，第一时间还不赶紧把它的架构搂两眼
从这个图可以看到，Apereo CAS 主要组成就两大组件，一个服务器端，还有各种语言的客户端。
应用程序通过 CAS 的客户端，拦截校验用户请求是否通过认证，如果尚未认证，则重定向到 CAS 服务端的用户登录页面进行登录，登录成功后，会生成一个 ticket 给回应用程序，下次用户请求带着这个 ticket 就所向无阻。
Apereo CAS 的历史
前面说了 Apereo CAS 是耶鲁大学 Technology and Planning 实验室的 Shawn Bayern 在 2002 年出的一个开源系统。刚开始名字叫 Yale CAS。Yale CAS 1.0 的目标只是一个单点登录的系统，随着慢慢用开，功能就越来越多了，2.0 就提供了多种认证的方式。目前版本为 6.0
2004 年 12 月，CAS 转成 JASIG(Java Administration Special Interesting Group) 的一个项目，项目也随着改名为 JASIG CAS，这就是为什么现在有些 CAS 的链接还是有 jasig 的字样。
2012 年，JASIG 跟 Sakai 基金会合并，改名为 Apereo 基金会，所有 CAS 也随着改名为 Apereo CAS.
看起来这娃也不容易，嫁鸡随鸡，名字都改了 3 次了。
结论？
关于 Apereo CAS 能不能用的结论这里先不下，等到后面介绍安装部署集成的文章写完再一起看看。这次我们先看看 Apereo CAS 官网出的一幅图，这张图片介绍了 Apereo 的组成以及支持的各种协议，各种特性，不烦看看