分享吧基于通用业务平台与CAS的单点登录服务的研究

Posted 2021-04-27 大连飞创

一、前言

随着通用业务平台的发展不断壮大，使用通用业务平台架设的业务系统也越来越多，既然涉及到了系统就不能缺少用户的登录认证与权限管理。一旦出现了多个系统，那么单点登录势必是绕不过去的一个问题。如何整合这些系统之间的登录操作也是作为通用业务平台的范畴之内的课题。

下面来隆重介绍下通用业务平台基础组件之一的单点登录系统；

二、什么是单点登陆

 SSO 是英文 Single Sign On 的缩写，翻译过来就是单点登录。顾名思义，它把两个及以上个产品中的用户登录逻辑抽离出来，达到只输入一次用户名密码，就能同时登录多个产品的效果。当前的大型互联网产品都是多系统组成的应用群，或是微服务协同为用户提供服务。那么这些服务直接是相互独立运行部署的。但是他们又保持的相互联系， 比如说用户账号的管理，用户应该保持各个系统中统一的账号，不应该让用户每个子系统分别注册，分别登录登出，系统直接的复杂性要对用户透明。 

这就算我们面临系统直接独立性的痛点，也是我们接下来讨论的如何提供有效的措施来解决这种问题，既SSO (Single Sign On)。当然，我们这里主要讨论的是Web系统，确切地讲，应该叫Web SSO。

  我们先来看下面的场景，首先登录淘宝网www.taobao.com，同过用户密码登录进入系统：

  当我们想到支付宝页面时候并不需要用户密码。

显然，对用户来说，他不希望每个子应用分别登录，因为这都是阿里服务，在用户看来，就相当于一个大系统，当我在一个应用如淘宝上登录后，再访问阿里支付宝、天猫等其它系统，我们发现，系统都显示已登录状态。当在任意一系统退出登录后，再刷新访问其它系统，均已显示登出状态。可以看出，阿里实现了SSO。实际上，几乎所有提供复杂服务的互联网公司，都实现了SSO，如阿里、百度、新浪、网易、腾讯、58等 SSO问题，是大中型Web应用经常碰到的问题，也是Java架构师需要掌握的必备技能之一。

三、基于Cookie的单点登陆

那么如何实现一套SSO登录系统呢，我们先来看下单应用系统下，用户登录的解决方案。对于Web应用，系统是Browser/Server架构，Browser和Server之间的通信协议是HTTP协议。

HTTP是一个无状态协议。即对服务器来说，每次收到的浏览器HTTP请求都是单一独立的，服务器并不考虑两次HTTP请求是否来自同一会话，即HTTP协议是非连接会话状态协议。对于Web应用登录，意味着登录成功后的后续访问，可以看做是登录用户和服务端的一次会话交互过程，直到用户登出结束会话。如何在非连接会话协议之上，实现这种会话的管理？ 我们需要额外的手段。通常有两种做法，一种是通过使用HTTP请求参数传递，这种方式对应用侵入性较大，一般不使用。

另一种方式就是通过cookie。cookie是HTTP提供的一种机制，cookie代表一小撮数据。服务端通过HTTP响应创建好cookie后，浏览器会接收下来，下次请求会自动携带上返回给服务端。利用这个机制，我们可以实现应用层的登录会话状态管理。例如我们可以把登录状态信息保存在cookie中，这是客户端保存方式。由于会话信息在客户端，需要维护其安全性、需要加密保存、携带量会变大，这样会影响http的处理效率，同时cookie的数据携带量也有一定的限制。

比较好的方式是服务端保存，cookie只保存会话信息的句柄。即在登录成功后，服务端可以创建一个唯一登录会话，并把会话标识ID通过cookie返回给浏览器，浏览器下次访问时会自动带上这个ID，服务端根据ID即可判断是此会话中的请求，从而判断出是该用户，这种操作直到登出销毁会话为止。下面是浏览器cookie单点登录的流程图

令人高兴的是，我们使用的Web应用服务器一般都会提供这种会话基础服务，如Tomcat的Session机制。也就是说，应用开发人员不必利用Cookie亲自代码实现会话的创建、维护和销毁等整个生命周期管理，这些内容服务器Session已经提供好了，我们只需正确使用即可。

当然，为了灵活性和效率，开发人员也可直接使用cookie实现自己的这种会话管理。对于Cookie，处于安全性考虑，它有一个作用域问题，这个作用域由属性Domain和Path共同决定的。也就是说，如果浏览器发送的请求不在此Cookie的作用域范围内，请求是不会带上此Cookie的。

四、企业级基于CAS的单点登陆

那么下面我们进入正题，企业级实现SSO登录方案CAS：

1、CAS的介绍

SSO仅仅是一种架构，一种设计，而CAS则是实现SSO的一种手段。两者是抽象与具体的关系。

CAS是中央认证服务Central Authentication Service的简称。最初由耶鲁大学的Shawn Bayern 开发，后由Jasig社区维护，经过十多年发展，目前已成为影响最大、广泛使用的、基于Java实现的、开源SSO解决方案。

    2012年，Jasig和另一个有影响的组织Sakai Foundation合并，组成Apereo。Apereo是一个由高等学术教育机构发起组织的联盟，旨在为学术教育机构提供高质量软件，当然很多软件也被大量应用于商业环境，譬如CAS。目前CAS由Apereo社区维护。

CAS的官方网址是：https://www.apereo.org/projects/cas

工程代码网址：https://github.com/Jasig/cas

2、CAS的术语

 我们先来认识些CAS的术语

TGT是CAS为用户签发的登录票据，拥有了 TGT，用户就可以证明自己在 CAS 成功登录过。TGT 封装了 Cookie 值以及此 Cookie 值对应的用户信息。当 HTTP 请求到来时，CAS 以此 Cookie 值（TGC）为 key 查询缓存中有无 TGT ，如果有的话，则相信用户已登录过。

TGC：Ticket Granting Cookie

CAS Server 生成TGT放入自己的 Session 中，而 TGC 就是这个 Session 的唯一标识（SessionId），以 Cookie 形式放到浏览器端，是 CAS Server 用来明确用户身份的凭证。

ST：Service Ticket 

ST是CAS为用户签发的访问某一 service 的票据。用户访问 service 时，service 发现用户没有 ST，则要求用户去 CAS 获取 ST。用户向 CAS 发出获取 ST 的请求，CAS 发现用户有 TGT，则签发一个 ST，返回给用户。用户拿着 ST 去访问 service，service 拿 ST 去 CAS 验证，验证通过后，允许用户访问资源。

了解这些术语，可以帮助我们了解CAS的实现流程步骤，我们用个场景来描述下CAS 实现 SSO 的详细步骤，顺便加深理解之前提出的概念。

3、CAS单点登陆步骤

官网给出的时序图

4、搭建CAS服务中心  

概念我们都已经清楚了，我们来实际搭建一套CAS服务中心：

我们选择CAS的版本为5.1.x，要求JDK1.8+。

第一步：获取CAS部署包模板CAS Overlay Template

git clone https://github.com/apereo/cas-overlay-template 

在获取下来的cas-overlay-template包中，查看README.md可以找到部署方法。

第二步：增加Service Registry功能

如果缺失这一步，后面会报错。CAS支持的协议http/https协议就是这里配置的。

第三步：配置域名

在cas-overlay-template/etc/cas/config/cas.properties中默认配置域名如下：

cas.server.name: https://cas.dce.com:8443

cas.server.prefix: https://cas.dce.com:8443/cas 

为了能让demo运行，需要在/etc/hosts中加入如下类似配置：

第四步：生成服务器端HTTPS证书

cd cas-overlay-template/ 

chmod +x build.sh 

sudo ./build.sh gencert 

这一步会在/etc/cas目录下生成thekeystore和cas.cer两个文件。

第五步：构建并运行CAS Server

sudo ./build.sh 

第六步：登录CAS

系统内置了一个默认的测试用户名和密码，即casuser/Mellon.该用户名可以在cas-overlay-template/target/cas/WEB-INF/classes

中as.authn.accept.users找到。

访问

https://cas.dce.com:8443/cas/login，输入用户名和密码即可登录成功。如下所示：

我们成功的搭建了一套CAS单点登录服务系统，下一步我们将在我们的客户端系统里使用CAS系统。

 加入两个CAS客户端测试单点登录，

 部署CAS客户端1主机

第一步：获取CAS客户端部署包

git clone https://github.com/cas-projects/cas-sample-java-webapp

第二步：配置域名

在/etc/hosts中增加CAS服务器的域名 cas.dce.com 映射到cas服务器的主机ip。

配置cas-sample-java-webapp/src/main/webapp/WEB-INF/web.xml将所有8443前面默认的ip替换为：cas.dce.com

第三步：创建客户端证书

第四步：导入服务器端证书

先将服务器端生成的/etc/cas/cas.cer下载到本地的当前目录，然后执行如下命令：

提示是否要信任该证书时，输入”是”。

第五步：运行CAS客户端

部署CAS客户端2主机所有步骤与”部署CAS客户端1主机”的操作一样，把对应的example1.dce.com替换为example2.dce.com即可。

测试CAS客户端与服务器的集成情况:

第一步：先访问CAS客户端1：

https://example1.dce.com:8180，系统会跳转到 https://cas.dce.com:8443/cas/login，然后提示登录，输入用户名casuser和密码Mellon之后，系统回到https://example1.dce.com:8180页面。登录成功。

第二步：再访问CAS客户端2：

https://example2.dce.com:8180，这时不再需要登录。

重复上面的步骤，做另外一个客户端CAS2。需要修改的地方包括：

[1] /etc/hosts

[2] cas-sample-java-webapp/src/main/webapp/WEB-INF/web.xml

[3] 创建证书

至此，我们实现了单点登录CAS系统的搭建与客户端的测试工作，

5、结合通用业务平台的CAS系统

 经过上面的演示加操作，相信大家都能自己完成一套基于CAS的单点登录系统，那么通用业务平台中是如何集成CAS的，单点登录系统又是如何在通用业务平台中运用的，接下来我们来分析下通用业务平台的单点登录系统。 

首先，搭建单点登录系统，下载CAS官网的源码，https://github.com/apereo/cas ，将源码拷贝到通用业务平台。目录结构如下：

目录中src文件夹就是通用业务平台单点登录开发代码所在的地方，要完成业务平台的单点登录和个性开发就需要在这里面实现。比如说，原始的单点登系统是不提功验证码功能的，所以需要自己去开发相应的功能。

接下来我们进行代码改造工作，我们通过数据库来获取用户名称密码来进行登录验证，在CAS系统中的配置文件为我们提供了不同的数据库，我们按照自己需要来进行配置，配置文件是标准的springboot配置文件格式：

上面cas.authn.jdbc配置数据库信息的配置项，配置后便可通过数据库的用户密码来验证登录，对于数据库密码加密的策略，CAS也提供了加密几种加密策略包括MD5、SHA等。对于自定义加密也提供了接口，你需要继承并且实现它，代码如下：

我们也可以开启CAS配置文件中的redis缓存功能，这样我们就能保证当我们使用CAS集群的时候可以共享登录信息。

验证码我们可以选择使用开源的Captcha，开发步骤是在pom.xml文件中引入jar包，

然后我们通过controller提供http请求发送给前端image的图片流，在通过CAS自己webflow添加进去相应的流程验证代码：

目前通用业务平台是前后端分离的策略，这样用户不想通过通用登录页面进入到系统中去，那么当用户想通过自己的登录页面再实现统一登录，实现的方式是通过LT方式

CAS统一登录页面的原理是，首先进入页面时，会获取到LT和execution，submit的时候，会对该LT进行验证。因此LT方式的目标是，自定义页面中，首先也获取到LT和execution，后续过程和统一的登录页面基本没区别。

So，第一步：获取到LT和execution。一般如下流程：

webflow中，添加action-state，根据传入的参数，判断走自定义的流程分支；

自定义流程分支中，要调用UniqueTicketIdGenerator生成LT，参考自带state：generateLoginTicket；

自定义流程分支中，要添加view-state及对应jsp页面，通过jsp页面做response返回。如：<%out.print(“json String”)%>

需要注意的是，此处如果是web端自定义登录页面，会有跨域问题。因此一般通过jsonp方式或iframe等，这里前端就不多提。获取LT后，应该能正常登录了。后续过程和统一的登录页面刚说基本没区别。

五、总结与展望：

通用业务平台已经通过服务化的方法将CAS集成到客户端应用中，这样大大减少了客户端开发的成本，通过配置文件引入安装插件方式灵活使用CAS服务。通用业务平台未来也将单点登陆作为一个重要的课题，后续对OAuth、OpenID等方案进行研究并整合融到平台中，同时进一步推进单点登录服务在交易所业务系统中的落地应用。关于通用业务平台的单点登录介绍到这里，希望对大家了解单点登录系统有所帮助。

1

END

1