由于企业的应用系统较多,为了是员工实现一个用户信息可以进行登陆到其他系统中,故使用单点登陆(Single Sign On , 简称 SSO ) 进行实现,目前使用的SSO框架为CAX (Central Authentication Service)是一款不错的针对 Web 应用的单点登录框架。
到 CAS 官方网站下载 CAS Server 和 Client,地址分别为:
http://www.ja-sig.org/downloads/cas/cas-server-3.1.1-release.zip
http://www.ja-sig.org/downloads/cas-clients/cas-client-java-2.1.1.zip
对于具体CAS 的学习可以在官网和网络平台上进行学习研究,在这就不进行多说了,下面主要介绍企业的应用系统的 SSO 实现逻辑,可以对需要实现SSO 的系统提供解决思路。
逻辑实现时序图:
1) 假设现在有两个应用App1和app2,用户已经登录了App1,需要跳转或者直接访问App2中的功能页面。
App1的访问地址为:http://192.168.1.100/app1/;App2的访问地址为:http://192.168.1.101/app2/,需要访问App2的页面为http://192.168.101/app2/action2.action
2) 假设用户已经登录了App1,用户需要访问App2的页面,先将跳转(外部访问)请求发送给App1的ssoURLRequestServlet,如上图中的环节①。
请求的URL为:http://192.168.1.100/app1/ssoURLRequest?app=app2&url=action2.action
3) App1根据ssoURLRequest获取URL信息获取跳转的目标应用为App2,地址为action2.action(相对地址),并根据App2找到该应用的其它信息,比如:应用首页路径,IP地址,context path 等信息,组成访问App2功能页面的绝对路径以及进行SSO登录校验的绝对路径。
4) App1的ssoURLRequest获取当前登录用户id(比如工号,保持和app2的相关信息一致),将:用户id+app2+sessionId+uuid 数据经过加密生成Token1凭证,并将凭证信息保存到缓存中(内存,集中缓存或者数据库),发送给App2,请求App2生成登录App2的凭证,请求地址为:http://192.168.1.101/app2/tokenGenerat,如上图中的环节②。
5) App2接收到生成校验信息请求之后,获取App1发送过来的Token1凭证,请求App1的http://192.168.1.100/app1/tokenValidate,校验Token1是否有效,如上图中的环节③。如果有效,则生成登录App2凭证信(Token2),并将凭证信息保存到缓存中(内存,集中缓存或者数据库),同时将凭证信息加密后返回给App1的ssoURLRequestServlet。
6) App1的ssoURLRequestServlet接受到App1返回的登录凭证信息后,将凭证信息返回给发送跳转(访问App2)请求的浏览器,并返回浏览器跳转的脚本,浏览器携带登录凭证信息(密文)跳转至App2,如上图中的环节④。
7) App2接收到带有登录凭证的请求后,将凭证信息解密,并校验该凭证信息是否有效,若有效,则根据解密后的凭证信息转换为用户登录信息并保存到session中(或者其他地方),至此实现登录App2,在整个过程中用户不需要输入App2的登录信息就实现了登录App2,如上图中的环节⑤。
web.xml主要是配置单点登录相关的servlet, 如 CAX 的的集成;
sso-common.xml配置每个应用对应的信息,包括应用ID、Token凭证信息保存方式等;
sso-current.properties配置Token过期时间、Token数据库保存时的数据源定义、Token缓存保存时的Redis定义等。
相关推荐
敢说最准确的单点登录图示,因为:1. 我严格对照所画时序图的每个步骤,开发了完整的跨域单点登录范例;2. 所有服务端步骤,都在代码中逐一标注,跟踪代码就能两相对照,实际的深入理解流程;3. SSO核心在写Cookie、...
如何实现单点登陆着信息技术和网络技术的迅猛发展,企业内部的应用系统越来越多。比如在媒体行业,常见的应用系统就有...针对于这种情况,统一用户认证、单点登录等概念应运而生,同时不断地被应用到企业应用系统中。
SSO之CAS单点登录详细图文教程,里面包含实现逻辑分析和流程介绍
单点登录SSO(Single Sign On)说得简单点就是在一个多系统共存的环境下,用户在一处登录后,就不用在其他系统中登录,也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁,例如像...
该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务...
civism-sso基于springmvc+redis+shiro 实现的分布式单点登录系统,继承了登录验证以及数据接口鉴权, 能很好的帮助其他项目做前后端分析,并且不需要其他子系统关心权限,并且该项目支持跨域请求 功能介绍 * sso登录...
简单说一下我的逻辑,我也不知道我理解sso对不对。 假如三个站点 a.baidu.com b.baidu.com c.baidu.com a.baidu.com 作为验证用户登录账户。 b和c作为客户端(子系统)。 b和c需要登录的时候跳转到a,并且携带...
单点登录, SSM框架公共模块 ├── zheng-admin -- 后台管理模板 ├── zheng-ui -- 前台thymeleaf模板[端口:1000] ├── zheng-config -- 配置中心[端口:1001] ├── zheng-upms -- 用户权限管理系统 | ├── ...
CAS 全称集中式认证服务(Central Authentication Service),是实现单点登录(SSO)的一中手段。 CAS 的通讯流程图如下(图片来自Google图库): 对于本文用户可感知的层面,认证过程如下: 前端访问后端登录接口 ...
当时按照最小依赖和最大重用把web系统权限控制划分成了业务逻辑、权限管理、权限验证、登陆代理、登陆服务、用户管理、业务逻辑数据库、业务权限数据库和用户数据库几个部分,现在开始逐一实现以上除业务逻辑的部分...
Concrete5 Windows单点登录(SSO) 一些初始的概念验证代码,用于通过LDAP / ActiveDirectory / Kerberos从Windows机器实现具体的透明传递身份验证(SSO)5 感谢ntisteve通过在以下站点上的Concrete5论坛发布了此...
8、 使用单点登录系统(SSO)来实现集群状态下的用户数据的维护。 9、 使用高性能的KV数据库Redis完成数据的存储以及缓存,提高数网站整体的性能。 10、 使用企业级开源系统Solr完成商品以及订单数据的搜索。 11、 ...
该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务...
该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务...
该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务...
该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务...
sa-token是一个轻量级Java权限认证框架,主要解决:登录认证,权限认证,会话会话,单点登录,OAuth2.0等长度权限相关问题框架针对踢人下线,自动续签,前后台分离,分散会话……等常见业务进行N多适应,通过sa-...
该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务...
Json web token (JWT),适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须...
该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务...