为什么要做这个尝试？
微服之道，方兴未艾；农之来学者，盖已千者！ 这句是从《陶山集·太学案问》瞎改出来的。意思就是微服务的架构理念还在不断地发展，现在整个啥都 言必出微服务，差点都到了 没学过微服务的码农不是一个好码农。搞到微服务这个词都快跟区块链差不多臭了。
在将臭未臭之前，我们赶紧把其中的统一认证这块过一下。
在微服务的概念中，恨不得每一个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的组成以及支持的各种协议，各种特性，不烦看看
