cas如何实现多系统间的相互认证_cas如何实现多系统间的相互认证_浅谈认证的发展历史及方向...

在企业信息系统的建设过程中,认证是我们必须面临的问题,从用户的登录,PC端,移动端,智能设备的访问,到关键业务的强身份认证,多因子确认,从实现业务操作安全,到实现转账,系统间的通信,与外部系统的集成等等都少不聊认证的参与,而当今云计算容器化的崛起,认证方式也从最初的cookie,session等手段发展到了现在的多端登录,多因子强认证,多端扫码,api令牌,用户目录等多种方式,并且针对用户的认证方式和手段的创新从未停止过,也会一直不断发展.

本文将与大家一起从认证的角度看看系统建设中的那些事.

发展历史

单体应用时期

企业在IT系统的建设初期,大多需求都是针对具体的领域中的业务,所以在建设过程中专注于系统业务的快速实现,对于认证的实现,往往都采用简单的账号密码进行认证(登录),并在登录后返回服务器的cookie/session,作为登录后用户的登录凭据,其交互流程如下:

在此模式下,系统提供单一的账号密码的认证方式,用户使用系统管理员或自行注册的账号密码进行登录,后端的服务器根据用户提交的账号密码进行认证,并依托于web服务器中间件(例如:tomcat,jetty,weblogic)对于session的实现,将凭据保存到session中.

SOA时期

在一个一个的业务系统慢慢的建设过程中,企业信息化能力得到了较大的提升,各系统搭建方便了企业中的各领域内的业务的快速开展,信息交换,产生了较大的价值,但是各业务系统间的信息却无法快速整合,难以形成集体效益.

这时,各系统的壁垒也越来越高,主要表现如下:

各系统有独立的认证方式

各系统间的交互以人工协调为主

各系统间领域不同,对业务的字段要求也不一致

随着问题的产生,解决方案也逐渐诞生,在面对以上问题时,SOA脚踏祥云,披着彩霞,以英雄的姿态在各系统之间诞生了.

SOA以面向服务的方式整合各个单体系统,将其变为整个信息化系统中的服务,不再成为孤岛,通过中立的接口通信方式将各系统连接起来,在此时期CAS,SSO,ESB等等闪耀的明珠熠熠生辉,这时期典型的认证流程如下:

CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。

CAS以独立的CAS Server组件为各系统提供用户的认证功能,再也不用去记下来各系统的登录账号密码,但是也遗留下来很多的问题:

各系统需要自行实现CAS Client的协议(也就是重定向等动作)

系统间的相互调用未被关注

还主要关注在浏览器端,并未延伸到app,智能设备

前后端分离时期

在一个系统中,前端和后端主要关注点是不一致的:

前端以静态资源为主,期望尽可能的利用浏览器缓存;

职责更明确,对中间件的要求也更明确;

在开发期间,前端严重依赖后端;

后端追求的是高并发,高可用,高性能,安全,存储,业务执行,前端追求的是页面表现,流畅展示,兼容性,用户体验

既然SOA时,拆分了专门的CAS Server为认证提供服务,那么前端的资源因为和后端关注的不一样,也理应分离出去,但拆分前端和后端也会面临以下问题:

后端的session无法在前端使用;

前端还需要前后端分离的框架;

需要一个网关来路由前后端资源(因nginx支持静态资源,顺势使用);

因前端无法使用session,那么需要提供一种更好的认证方式

虽然面临的不止以上的这些问题,但是前后端分离已成不可阻挡的趋势,同时jwt认证逐步在各系统中被应用,典型的交互方式如下:

此模式优点也非常明显:

token机制实际上已经可以脱离浏览器支持;

前端因框架工具等支持出现了很大提升;

token是无状态的,后端多实例支持较为方便(避免了以前的session共享);

但是,SOA中的需要入侵业务系统才能支持jwt认证和系统间相互调用的问题还是没有得到妥善解决.

至此,前端在angular,vue,react这些工具和框架的加持下,从jquery进入到了mv*时代,前端也从jquery组件进入到了三大框架三分天下的时代

微服务时期

得益于spring cloud和一系列基于此的框架开源,后端(特别是java)进入到了一个新的时代,后端也从ssh/ssm进入到了spring cloud为主的微服务时代,后端开始强调业务上的区分,系统的限界上下文的战略设计.

微服务更专注业务的划分,各业务系统使用各自适合的语言专注自身业务特点进行建设,而不入侵各系统实现认证则成为了一个必要的要求.

此时,zuul,spring cloud gateway等网关又成了冉冉的新星,为认证提供了很大的施展空间.

此时的认证如下:

通过独立的认证中心,专注为认证服务,其优势如下:

职责更为明确

对业务系统无入侵(在网关和认证服务中完成认证)

认证中心可以提供更多的认证模式

对于其他语言也有较好的支持

在此时期,因spring cloud系列带给我们太多技术上的便利,也导致了java语言在微服务中占据的优势较为明显,其他语言只能通过spring cloud sidecar方式间接接入系统中,虽有劣势,但是在中等规模的系统中也还可以接受.

云时代建设方向

微服务的崛起,也出现了新的问题: 如何大规模标准化的部署和运维这些服务?如何做到真正的跨语言?

docker的出现,解决了标准化部署的问题;

kubernetes以容器化编排王者的姿态为我们解决了大规模部署,运维等问题;

以Istio为首的Service Mesh方案则在积极的推进跨语言;

那么在此模式下我们的认证又是怎么样的呢?

得益于kubernetes,istio这些工具,此方案优点如下:

无入侵支持认证

不再依赖具体某语言的框架,跨语言支持

认证中心可以根据用户属性决定路由(金丝雀部署)

各业务服务中注入sidecar,支持服务间TLS加密

认证等功能向基础设施转移,服务更”业务化”

基础设施功能更为齐备,并且可以提供较多扩展

针对内部和外部分开认证和授权

在多”云”的时代,我们的认证方式也需要多样化,认证也将分为两个大的体系:

内部系统认证

内部认证主要针对企业内部的信息化系统,为这些内部的信息化系统提供用户的认证功能,用户通过认证服务进行认证,并通过网关转发认证后的用户标识,业务系统不再关注认证.

针对内部系统间的相互调用,提供TLS加密功能,保障内部调用的安全性.

外部系统授权

外部的系统与内部的系统交互应以OAuth2/OIDC等协议为核心的开放平台为主,通过协议来完成与第三方系统的协作授权,并保证系统的安全性.

总结

在架构的衍进过程中,认证系统和认证方式也在不断的衍化进步,针对多种的认证方式,需要理清其中关系,逐步系统性的建设.

在互联网的浪潮之中,创新不止,浪潮不息.