前言 为什么整理单点登录? 主要的原因还是自己以前学习的时候曾经用过,但是时间太久,忘记了里面用到了哪些技术.及如何实现的,每次想到单点登录总是感觉即会又不会,这次整理session时,又涉及到了单点登录,而且单点登录里面还用到了redis,也是我这次要整理的内容,故而单独把单点登录抽出来,系统的梳理下,以备下次忘记时重温. 顺便也把以前学习分布式项目中用到的相关技术:double.zookeeper等统一梳理一遍,加强对现在项目的整理架构的理解. 其实,无论是单一的应用,还是分布式项目乃至现在

上一篇我根据框架中OAuth2.0的使用总结,画了SSO单点登录之OAuth2.0 登出流程,今天我们看一下根据用户token获取yoghurt信息的流程: /** * 根据token获取用户信息 * @param accessToken * @return * @throws Exception */ @RequestMapping(value = "/user/token/{accesstoken}", method = RequestMethod.GET) public Resp

我们在搭建cas中已经说过如果不搭建https证书体系的需要去掉https的验证: 单点登录(二)----实战------简单搭建CAS---测试认证方式搭建CAS 因为cas4.2以上的代码做了一些框架的优化,4.2以下的版本的很多配置都是写在xml文件中.4.2以上统一提取到了cas.properties文件中. 所以在去掉https的时候 方式也有所变化. 现在网上查到的资料很多都还停留在对4.2以下版本的配置修改中. 我们这里把两种情况都记录下来. 4.2以上cas server去掉ht

cas启用mongodb验证方式报错com.mongodb.CommandFailureException---Authentication failed. 完整报错信息: 二月 08, 2017 5:34:32 下午 org.apache.catalina.core.ApplicationContext log 信息: Initializing Spring root WebApplicationContext 2017-02-08 17:34:39,577 INFO [org.jasig.c

cas启用mongodb验证方式报错--Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/data/mongo] 完整报错信息如下: 二月 08, 2017 3:49:47 下午 org.apache.catalina.core.ApplicationContext log 信息: Initializing Spring root Web

sso单点登录概念 1.一处登录,处处登录.会单独做一个单点登录系统,只负责颁发token和验证token,和页面登录功能. 2.通过在浏览器cookie中放入token,和在redis中对应token放入用户信息的方式,代替session共享,使用jwt(json web token)自定义一个携带用户信息token加密算法. 3.cookie中的token是已经使用过的token,取名oldToken . url地址栏中的token新颁发的token,取名newToken 做法: 1.首先自

1. MVC Controller 映射 sso 方法. /** * 单点登录(如已经登录,则直接跳转) * @param userCode 登录用户编码 * @param token 登录令牌,令牌组成:sso密钥+用户名+日期,进行md5加密,举例: * String secretKey = Global.getConfig("shiro.sso.secretKey"); * String token = Digests.md5(secretKey + userCode + Dat

转载源:https://www.jianshu.com/p/613c615b7ef1 单点登录之CAS原理和实现 来源于作者刘欣的<码农翻身> + 自己的备注理解 这家集团公司财大气粗,竟然自己建了一个数据中心, 放了数百台机器, 部署了几十个企业内部系统. 在无尘.恒温.恒湿的环境里,这些信息系统的日子过得非常惬意. 他们只需要在白天应对人类的HTTP 请求,及时做出响应, 只要人类一下班, 系统的负载就陡然下降,CPU内存全部都空闲下来. 大家闲来无事, 热热闹闹的机房夜话就开始了. 第一

一:SSO体系结构 SSO ​ SSO英文全称Single Sign On,单点登录.SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统.它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制.它是目前比较流行的企业业务整合的解决方案之一. 体系结构 ​ 当用户第一次访问应用系统1的时候,因为还没有登录,会被引导到认证系统中进行登录:根据用户提供的登录信息,认证系统进行身份校验,如果通过校验,应该返回给用户一个认证的凭据--token:用户再访问别的应用的

单点登录 多系统,单一位置登录,实现多系统同时登录的一种技术. 常出现在互联网应用和企业级平台中. 如:京东. 单点登录一般是用于互相授信的系统,实现单一位置登录,全系统有效的. 三方登录:某系统,使用其他系统的用户,实现本系统登录的方式.如,在京东中使用微信登录.解决信息孤岛和用户不对等的实现方案. 一. Session跨域 所谓Session跨域就是摒弃了系统(Tomcat)提供的Session,而使用自定义的类似Session的机制来保存客户端数据的一种解决方案. 如:通过设置cookie

文章较长,建议推荐,建议转发,建议收藏,建议关注公众号哈. OAuth 2 有四种授权模式,分别是授权码模式(authorization code).简化模式(implicit).密码模式(resource owner password credentials).客户端模式(client credentials),具体 OAuth2 是什么,可以参考这篇文章.(http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html) 本文我们将使用授权码模式和

单点登录 一.Session跨域 所谓Session跨域就是摒弃了系统提供的Session,而使用自定义的类似Session的机制来保存客户端数据的一种解决方案. 如:通过设置cookie的domain来实现cookie的跨域传递.在cookie中传递一个自定义的session_id.这个session_id是客户端的唯一标记.将这个标记作为key,将客户端需要保存的数据作为value,在服务端进行保存(数据库保存或NoSQL保存).这种机制就是Session的跨域解决. 二.Spring Se

[本文版权归微信公众号"代码艺术"(ID:onblog)所有,若是转载请务必保留本段原创声明,违者必究.若是文章有不足之处,欢迎关注微信公众号私信与我进行交流!] 一:SSO体系结构 SSO SSO英文全称Single Sign On,单点登录.SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统.它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制.它是目前比较流行的企业业务整合的解决方案之一. 体系结构 当用户第一次访问应用系统1的时候,因为

ERP与SSO的恩怨情仇--第10篇 用日志记录“开源软件”的诞生 赤龙 ERP 开源地址: 点亮星标,感谢支持,与开发者交流 kzca2000 码云:https://gitee.com/redragon/redragon-erp GitHub:https://github.com/redragon1985/redragon-erp 赤龙ERP官网:https://www.redragon-erp.com 为什么要用单点登录 首先大部分系统都不是孤立存在的,尤其是信息化系统.它们往往在一个大的平

COOKIE & SESSION & TOKEN 主要用来跟踪会话,识别用户所用.cookie 是客户端,session 是服务端的. 因为 http 是无状态协议,每一次的访问都不知道之前的状态,只能通过参数的方式来判断识别等. cookie 也是 http 协议的一个补充. - 有效期 - 不可跨域名 - 编码(unicode 中文,base64 二进制编码) - 属性(name,value,maxAge,domain,secure,path,comment,version) Cook

企业的信息化过程是一个循序渐进的过程,在企业各个业务网站逐步建设的过程中,根据各种业务信息水平的需要构建了相应的应用系统,由于这些应用系统一般是在不同的时期开发完成的,各应用系统由于功能侧重.设计方法和开发技术都有所不同,也就形成了各自独立的用户库和用户认证体系.随着新的业务网站不断的增加,用户在每个应用系统中都有独立的账号,这样就造成在访问不同的应用系统时,需要记录对应的用户名和密码,多个用户名密码极易记混,如果忘记或记错了某一个业务网站的用户名或密码就无法进行登录,耽误工作,影响工作效率,随

CAS实现单点登录 环境 客户端: www.app1.com CAS服务器: www.cas-server.com 1.浏览器:发起请求 www.app1.com 2. 客户端:AuthenticationFilter 发现Session为空,ticket为空,重定向并保存service https://www.cas-server.com/cas/login?service=http://www.web.com/app 3. CAS服务器:展示 login 页面,默认提供 username /

我们在之前的文章中中已经讲到了正确部署运行cas server 和 在cas client中配置. 在此基础上 我们去掉了https的验证,启用了http访问的模式. 单点登录(七)-----实战-----cas server去掉https验证 但是我们之前部署的cas server,用户登录时使用的是简单的文本配置方式. deployerConfigContext.xml中的配置方式是 <alias name="acceptUsersAuthenticationHandler"

使用JWT实现单点登录时,需要注意token时效性.token是保存在客户端的令牌数据,如果永久有效,则有被劫持的可能.token在设计的时候,可以考虑一次性有效或一段时间内有效.如果设置有效时长,则需要考虑是否需要刷新token有效期问题(比如有效期是10分钟,10点登陆,有效时间到10点10分,10点09分再次请求一次,要刷新有效期,有效时间到10点19分). 使用JWT技术生成的token,客户端在保存的时候可以考虑cookie或localStorage.cookie保存方式,可以实现跨域

一.单点登录流程 =====客户端====== 1.拦截客户端的请求判断是否有局部的session 2.1如果有局部的session,放行请求. 2.2如果没有局部session 2.2.1请求中有携带token参数 2.2.1.1如果有,使用HttpURLConnection发送请求校验token是否有效. 2.2.1.1.1如果token有效,建立局部的session. 2.2.1.1.2如果token无效,重定向到统一认证中心页面进行登陆. 2.2.1.2如果没有,重定向到统一认证中心页面