你不可不知的事 | 单点登录成长史

Posted 2021-04-27 IT发烧友

  

单点登录成长史 来自IT发烧友 00:00 18:57

Hi 又见面了，对于不可描述的小编Team来说，今天可是个特别的日子。

为什么会特别呢？

众所周知，随着IT化的转型，IT发烧友一直致力于变革，而单点登陆系统的革新则是这变革中重要的一枪。

大家可以看看下面这张图，截至今日凌晨，新版单点登录系统已经完成了所有在案系统的接入，这标志着新版单点登录系统正式、全面的进入历史舞台~

那么，新版单点登录系统究竟是什么样的？

改造过程中有哪些不可不知的故事？

让我们跟随新版单点登录系统的首席项目经理来一起看看单点登录的成长史~

  序  

Hi 大家好，我是网管室单点登录系统，大家就叫我SSO吧，我很荣幸能够跟随网管室发展的脚步而不断成长。

成长的过程是痛苦的，我为在这个过程中给大家带来的不便和困扰表示深深的歉意，同时我也一直希望自己能够变得稳重成熟，少犯错，来回馈大家一直以来对我的信任和支持。

如今正值网管室进行新技术转型和发展的关键期，我愿意为大家做排头兵，做试验田，用新的技术和理念来武装自己，我知道这一切都只是起步，但我相信经过洗礼和磨练才能更好的服务大家，也能在网管室技术转型之路上添一把火，助一把力。

  自我介绍  

我是改造后的单点登录，得益于网管室的技术转型。

我的使命就是变革，重新采用DevOps理念武装自己，进行技术架构升级，基于spring cloud采用微服务架构进行设计并最终进行容器化部署，整个系统利用网管室内部搭建维护的DevOps生产线进行CI/CD（持续集成/持续交付），对整个软件生命周期进行管控，包括需求管理、源代码管理、代码扫描、单元测试、自动编译构建、自动测试、镜像打包、自动发布镜像到测试环境、预生产环境以及生产环境，镜像自动运行及监测等。

现已经完成所有功能点的开发和部署上线（包括前端界面以及后端微服务化改造），将整个系统拆分成五个微服务（注册中心、SSO服务、API网关、配置中心、前端服务），并在DevOps生产线上成功完成了全流水线的贯通，真正实现了从代码提交到部署发布的全自动化流程。

目前支持针对整个系统或者系统内部某个模块进行CI/CD，完整跑完一次流程的时间目前基本控制在15分钟以内。改造后的我已经和网管系统的几乎全部小伙伴们完成了对接，他们按照我提供的接入说明很容易就能够和我完成业务的对接，目前为止我们合作很愉快，还没有闹过矛盾。下面公布一下我的旧照和新容。

  改造前的我  

改造前的我（旧照）：

1. 采用OSSO + SSO 两个单体结构实现基于CAS protocol的单点登录，其中SSO基于极具重量级的开源CAS server进行代码改造，增加了冗余流程，使得本来简单的业务复杂化，提高了错误率； 

2. 服务端采用了共享Session，有状态，不易扩展，增加了分布式部署难度；

3. 直接读取后台数据库，不支持接口访问；

4. 对外采用老式的WebService接口，不易于扩展与维护；

5. 仍然需要手动部署，不支持自动化部署，无法做到弹性伸缩及高可用；

6. 代码日久失修，尤其SSO部分更是无人打理。

 改造后的我

改造后的我（新颜）：

1. 只有一个SSO，采用主流的Oauth2.0+JWT protocol，基于成熟的spring-security-oauth2.0进行代码实现，并利用spring cloud进行微服务改造；

2. 简化了实现逻辑，降低了复杂度，提高了正确率；

3. 去除原先的服务端session，进行服务端无状态化处理，首次采用k8s进行容器化部署，有很强的横向扩展能力，具有高可用性，支持高并发；

4. 数据库访问采用接口进行交互，提高了系统稳定性；

5. 全部采用Restful接口，前后端分离并首次进行微服务改造，提高系统可维护性；

6. 首次采用网管室部署的DevOps生产线进行开发以及集成，支持自动化部署和升级；

7. 首次从源代码接入DevOps生产线，代码管理集中化，保证了系统的可持续发展。

以前采用单体结构，技术架构过时，交互接口陈旧，不易扩展、且不支持自动化构建与部署，升级后这些问题全部得到解决，这就是技术进步的力量，也是我们室一直致力于技术转型的成效的一个缩影，也希望越来越多的小伙伴加入到这个转型队伍中来。

  我的心路历程  

变革是痛苦的，但是前途是光明的，这是我一路走来总结的一句话。我先给大家列出一个时间轴：

可以看出整个蜕变过程十分紧凑，也困难重重，这里尽可能列出来整个过程中遇到的坑，希望能够帮助大家绕过这些障碍，尽快到达期望的彼岸。

首先，在改造初期就遇到一个大的麻烦，我已经在服很多年，虽然出过很多问题，但是修修补补也趋于稳定，为什么还要改造，但是新技术的吸引力以及网管室技术转型的决心坚定了我克服难题完成转变的信念；

其次，原来样子虽然丑，但是大家都看习惯了，你突然整个容，大家都不认识了怎么办；经过几番调研和探讨，最终达成了折衷：我的容颜还是保持不变（对外仍旧嵌套iframe），只优化内核（只是优化实现架构和部署方案），润物无声中，让大家接受全新的SSO；

第三，DevOps流水线还在施工，作为第一个入驻产品，遇到很多挑战；所幸DevOps流水线包工头曾海剑同志拥有一颗热心肠，一直帮助我完成整个的流水线贯通；

接入流水线需要完成依赖梳理，Docker镜像梳理以及部署管理，其中部署管理是最繁琐的一步，需要清楚配置生效环境，熟悉第三方中间件镜像特点，熟悉网络连通配置流程，另外还要掌握持久化文件的配置，日志存储的配置，域名的配置，各个服务端口的配置等，每一步都要清楚明了。在这些填坑的过程中，生产线也已经逐渐趋于成熟，相信大家的接入会越来越轻松。

第四，改造升级路线的确认也是一个很费周折的过程，中间经历了无数次的推倒重来，才有了最终的解决方案。这部分遇到的技术和应用问题以及我们的解决策略，也是我最想和大家分享的核心内容。

最初方案是：采用开源的CAS server，在此基础上进行代码改造使用CAS protocol进行单点登录实现。这也是OSSO+SSO架构中SSO的原型；

那么小伙伴要问了——什么是CAS server?

CAS server究竟起到了怎样核心的作用？

企业级单点登录-CAS提供了一个支持WEB实现单点登录的友好开源框架，他的组成架构如下图：

系统包含服务端和客户端两个物理组件，支持多种认证通信协议，包括CAS、SAML、OAuth以及OpenID等。CAS Server构建于Spring Webflow/Spring MVC之上，包含TicketRegistry和ExpirationPolicy两种可配置票据组件，支持多种认证方式(jwt,database,MongoDB等)。 客户端支持多种平台实现，比如Java、.Net、php、Perl、Apache等。

 

什么是CAS protocol?：

CAS协议是一个基于票据漫游的单点登录协议。它包含一个或者多个客户端和一个服务端。客户端被嵌入到需要实现单点登录的系统中，服务端则是一个单独运行的系统。服务端负责用户校验和授权，客户端则用来与服务端通信验证用户身份以确保各个子系统被合法访问。用到的几个关键词分别是TGT(Ticket Granting Ticket)，被存储在CASTGC cookie中，代表了一个合法用户的登录session；ST (Service Ticket)， 以GET parameter的形式存在于链接urls中被漫游，代表了服务端授权指定用户访问客户端资源的凭证。整个CAS单点登录交互时序图如下：

结合我们自己的网管系统架构考虑，如果照搬整个CAS架构，则需要每个客户端都植入CAS client,也就是全部需要实现CAS客户端协议，这对其他各个系统来说是不可接受的，他们希望尽可能简化他们的接入，并将这些繁琐的协议处理流程交给CAS server来做。为了解决这个问题，提出了改进方案

1.1：各个接入系统通过Iframe嵌入CAS Server SSO登录框。与前期方案1需要客户端植入CAS client相比，本方案中客户端只需要嵌入服务端提供的Js脚本，并实现通过获得的ST向服务端提请验证的接口即可，复杂的认证流程完全交给服务端和嵌入的JS脚本，极大地降低了各个系统接入难度；但是SSO代码已经年久失修，没人清楚其中的逻辑，没人敢动，目前还在发挥着重要作用。于是产生了解决方案

1.2：新增OSSO将其包裹一层对外提供服务，整个交互时序图如下：

这里又遇到了第二个问题：由于历史原因，本来可以集中到一个CAS服务器的功能被拆分成了两个服务器（OSSO+SSO），从而造成了这两个服务器之间的密集交互，极大的增加了系统的不稳定性，可维护性也差了很多（需要部署两套服务器，建立两套域名和IP）；另外由于采用CAS协议，中间需要大量使用ST票据漫游，同时需要服务端支持SESSION保存用户登录TGT以及ST，服务端就有了状态，横向扩展变的困难；OSSO和SSO以及与其他系统之间的接口交互全部采用webService接口，数据格式以XML为主，代码耦合性强，可扩展性差。

鉴于此，方案

1.3准备继续沿用旧的技术框架和协议，用最新版的CAS5.2替换原来的CAS3.2，同时将OSSO和SSO进行整合；但是很快就发现了这种方案的弊端：CAS集成了很多功能和协议，是比较重量级的框架，使用起来并不方便；SSO本身采用的是CAS3.2，里面使用了大量的webService接口，并不利于扩展；CAS协议本身要求服务有状态，并存在大量票据漫游，不易系统扩展和维护；单纯做升级对系统的改造意义不大，而且依旧保留了系统可维护性差的缺点。

继续调整，得到方案

1.4：与其在旧的上面进行改造，不如弄一个新的出来，这时候已经基本弄清楚了原来的实现原理，发现CAS不仅仅支持CAS协议，也支持Oauth协议，既然采用CAS协议必须使用XML传递用户信息，不支持简单的restful接口，那么采用Oauth协议呢？

关于Oauth协议，请大家移步

https://tools.ietf.org/html/rfc6749（Oauth2.0）和https://tools.ietf.org/html/rfc5849（Oauth1.0）自行取阅，里面有非常详尽的介绍，本文就不赘述。简而言之，Oauth2.0是专门针对应用授权的符合工业标准的协议框架，致力于简化客户端接入开发难度，同时分别针对web应用、桌面应用以及移动客户端应用提供精确的授权流程。它支持四种授权模式，分别是授权码模式(authorization code)、密码模式(resource owner password credentials)、简化模式(implicit)和客户端模式(client credentials)。

仔细研究发现CAS Server通过配置可以支持该协议授权码模式，而且支持restful接口交互，但是有一个比较严重的缺点就是Cas Server在架构设计上完全依赖后台SESSION来存储ticket，造成了后台始终还有状态，不易横向扩展，这个是硬伤。

到这里基本决定放弃继续使用CAS Server。继续调整，得到方案

1.5，既然CAS 协议以及Oauth2.0的授权码模式都会造成票据漫游和后台SESSION，CAS Server又是基于后台SESSION的实现架构，那么这些务必不可选。经过一番调研，发现spring-security-oauth2.0是专门针对Oauth2.0协议基于spring-security实现的一种轻量级框架，可以在这个框架下开发新版的SSO。下面就面临选择授权模式的问题，四种模式里面经过筛选就只剩下密码模式可用，但是单纯使用密码模式构建，就又会引起客户端适配复杂（都要实现客户端协议）的问题，同时各个客户端因为能获得用户信息也会造成信息泄漏，造成安全隐患。

鉴于此便有了方案

1.6，整合iframe嵌入以及spring-security-oauth2.0框架支持密码模式，依旧采用密码模式，但是核心协议处理流程交给SSO服务完成，客户端只需要完成JS嵌入和实现restful验证接口调用就能满足要求。但是这样实现的弊端就是SSO服务仍然需要引入SESSION存储token信息，从而引入状态。再次经过几番调研，发现token本身可以包含状态，那就是引入JWT，关于JWT的介绍可以移步https://jwt.io/ ，这里就不赘述，总之通过引入JWT可以通过仅仅在浏览器端设置Cookie的形式取消后台SESSION，

这样便有了最终的方案

1.7，那就是基于IFRAME+JWT+ SPRING-SECURITY-OAUTH2.0框架的方案，从而奠定了整个SSO的实现基础…

最终方案的详细介绍，以及这期间与Devops，预生产/生产容器云环境，微服务、基础网络还有各个联调系统之间的处理过程，将在以后的文章中呈现出来，争取能带给大家一个较为全面的系统生命周期图。

 

结束！

本期嘉宾

本期嘉宾  | 史森   广东移动网络管理中心平台架构主管，具备多年的电信设备研发运维、信息系统集成工作经验。在企业级信息系统架构、大规模并发系统设计、微服务总线设计与集成方面，拥有丰富的从业经验。目前聚焦于广东移动企业单点登录集成、企业微服务总线平台建设等工作。

P.S. 同事评价：外表高大威猛真汉子，内心温柔细腻小清新，热情开朗的技术牛人~

你可能还喜欢