基于 Cookie 的 SSO 中间件 kisso

kisso  =  cookie sso

基于 Cookie 的 SSO 中间件,它是一把快速开发 java Web 登录系统(SSO)的瑞士军刀。欢迎大家使用 kisso !!

kisso 帮助文档下载

1、支持单点登录

2、支持登录Cookie缓存

3、支持防止 xss攻击, SQL注入,脚本注入

4、支持 Base64 / MD5 / AES / PBE / RSA 算法

5、支持浏览器客户端校验

6、支持Cookie参数配置及扩展

7、支持跨域登录,模拟登录

8、支持在线人数统计

9、支持生成动态图片验证码

10、支持 app 移动端 api 服务验证,采用微信公众平台 api 验证机制认证

11、自带权限验证逻辑,支持基础 Shiro , SpringSecurity 权限系统

kisso 依赖 jars

kisso_oauth2 演示 demo

kisso_ApiServer 移动 APP 端 API 演示 demo

kisso_JFinal 演示 demo

kisso_SpringMvc 演示 demo

kisso_crossdomain 跨域演示 demo

实例演示
SSM 架构后台管理系统

Maven 坐标:

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.baomidou%22%20AND%20a%3A%22kisso%22

?


1

2

3

4

5

<dependency>

    <groupId>com.baomidou</groupId>

    <artifactId>kisso</artifactId>

    <version>Maven
官方最新版本为准</version>

</dependency>

(1)、kisso 是什么,与 cas 区别 ?

1、cas
是单点登录系统,它给你制定好了规则按照它的要求做就可以,配置(复杂)好一切即可实现单点登录。

2、kisso
是一个中间件,提供 cookie 搭建 java web sso 的组件式解决方案。你不管使用任何架构都可以使用它,就像一个 U 盘需要使用就插入、不用就拔掉。

3、cas
集中验证,所有请求都由 cas 集中验证,缺点cas服务压力巨大。kisso 分散验证,由各个系统验证 cookie 合法性,缺点秘钥要保护好。

(2)、为什么是
cookie 而不是 session 它们有何区别 ?

kisso
采用的是加密会话 cookie 浏览器关闭立即失效,同时支持后台登录超时自动退出,支持客户端浏览器验证、访问 ip 及 cookie 安全配置等。

1、session
存放在服务器端,cookie 存放在客户端,存在 2 种状态:“ 第一种:持久 cookie 具有时效性,以文件的形式存放在客户机硬盘中,时间一到生命周期结束自动被删除。第二种:临时 cookie 又叫会话 cookie 放在浏览器内存中,浏览器关闭生命周期结束自动失效 ”。

2、单纯不做任何改变而言
session 更安全,如果 cookie 采取各种安全保护措施,此时的 cookie 一样安全。

3、cookie
轻松实现分布式服务部署,单点登录跨域访问等问题,换成 session 需要处理 session 复制及各种问题实现困难。

(3)、经常被问及的问题 ?

在此重申下,下载源码的朋友先按照
demo 提供的例子运行跑通后,再修改不要上来就急急忙忙改,不会了就截图发问,这样一则没有理解透彻实现原理,二则耽误别人的时间,实在是得不偿失。

1、跨域是什么
? 这里跨域有 2 种  :

第一种、同一个根域名不同子域名,比如 my.baomidou.com 、  sso.baomidou.com  、other.baomidou.com 此时配置  domain 只需要配置   .baomidou.com  即可。

查看普通 demo : kisso_JFinal
演示 demo
   kisso_SpringMvc
演示 demo

第二种、完全不同的域名,比如  sso.baomidou.com     git.oschina.net 此时比较复杂 kisso 采用的是 rsa 加密询问验证(较复杂)

查看跨域 demo: kisso_crossdomain
跨域演示 demo

2、改成 ip 支持么 ?

支持! 注意访问时候使用 ip 访问,domain 的配置 ip 即可,不要是  .192.168.1.3  注意此时不要在前面加个  .  点。

3、sso.properties  怎么去配置 ?

除了密钥、域名、必须修改,其他默认配置或根据需要选择配置即可 查考点击 根据自己的需求选择配置。

很多朋友问?都谁在用 kisso !?

不要问我星星有几颗, 我会告诉你很多很多!!(保密)

(1)sso 登录状态

(2)跨域登录

hosts:

127.0.0.1 sso.test.com

127.0.0.1 my.web.com

访问 my.web.com:8090/index.html 如果未登录会重定向至sso域登录页面

登录成功 my.web.com 如图

普通登录

原文地址:https://www.cnblogs.com/jpfss/p/9273689.html

时间: 2024-10-01 11:58:20

基于 Cookie 的 SSO 中间件 kisso的相关文章

SSO 中间件 kisso

kisso  =  cookie sso,基于 Cookie 的 SSO 中间件.kisso 不是一套完整的登录系统, 它的定位是一把高速开发 java Web 单点登录系统的瑞士军刀. 开源地址:http://git.oschina.net/juapk/kisso 经过生产环境的考验希望很多其它的朋友參与进来给 kisso 添砖加瓦使之成为更加强大的利器. 支持: 支持单点登录 支持登录Cookie缓存 支持防止 XSS攻击, SQL注入,脚本注入 支持 Base64 / MD5 / AES

基于cookie的SSO单点登录系统 - waen - 博客园

原文:基于cookie的SSO单点登录系统 - waen - 博客园 利用数据库触发器实现定期自动增量更新缓存 原文地址:https://www.cnblogs.com/lonelyxmas/p/10434813.html

基于Cookie的SSO登录分析和实现

什么是SSO? 现在很多大的互联网公司都会有很多的应用,比如以下是淘宝网的截图: 天猫 聚划算 头条等都是不同的应用,有的甚至采用完全不同的域名,但是所有在淘宝注册的用户都是使用的一套用户名和口令,如果在这些系统直接切换做不到登陆状态的同 步,体验是非常差的.再举个栗子,很多公司内部系统也有很多个,比如HR系统,财务系统,考勤系统等等,如果员工在一个系统登陆了,跳转到另外一个系统还 需要登陆,就会让人很不爽... 基于此,SSO(Single Sign On)应运而生.当然,我们来现实这个需求的

SSO 基于Cookie+fliter实现单点登录(SSO):工作原理

SSO的概念: 单点登录SSO(Single Sign-On)是身份管理中的一部分.SSO的一种较为通俗的定义是:SSO是指访问同一服务器不同应用中的受保护资源的同一用户,只需要登录一次,即通过一个应用中的安全验证后,再访问其他应用中的受保护资源时,不再需要重新登录验证. SSO的用途: 目前的企业应用环境中,往往有很多的应用系统,淘宝.天猫.爱淘宝等等产品和如办公自动化(OA)系统,财务管理系统,档案管理系统,信息查询系统等等.这些应用系统服务于企业的信息化建设,为企业带来了很好的效益.但是,

基于cookie共享的SSO中的遇到的问题

什么是SSO? 现在很多大的互联网公司都会有很多的应用,比如以下是淘宝网的截图: 天猫 聚划算 头条等都是不同的应用,有的甚至采用完全不同的域名,但是所有在淘宝注册的用户都是使用的一套用户名和口令,如果在这些系统直接切换做不到登陆状态的同 步,体验是非常差的.再举个栗子,很多公司内部系统也有很多个,比如HR系统,财务系统,考勤系统等等,如果员工在一个系统登陆了,跳转到另外一个系统还 需要登陆,就会让人很不爽... 基于此,SSO(Single Sign On)应运而生.当然,我们来现实这个需求的

认证和SSO(五)-基于token的SSO

1.修改项目使其基于浏览器cookie的SSO 1.1.修改回调方法,获得到token后,由存放到session改为存放到cookie /** * 回调方法 * 接收认证服务器发来的授权码,并换取令牌 * * @param code 授权码 * @param state 请求授权服务器时发送的state */ @GetMapping("/oauth/callback") public void oauthCallback(@RequestParam String code, Strin

基于cookie在nginx实现业务灰度发布

基于cookie在nginx实现业务灰度发布 背景 灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式. 灰度发布可以保证整体系统的稳定, 在初始灰度的时候就可以发现.调整问题,以保证其影响度. 业务存在灰度发布的需求, 可以通过nginx+lua形式实现业务的灰度发布, 目前这一形式已在广平互动广告相关业务已经实现. 流程 用户使用帐号登录后,判断用户帐号是否在灰度发布的名单中,如果再则给用户的cookie中增加灰度发布标识,然后刷新页面. 当用户访问页面时,业务接入层的nginx方向代理会

nginx第三方模块---nginx-sticky-module的使用(基于cookie的会话保持)

目前的项目网站架构中使用了F5和nginx,F5用来做负载均衡,nginx只用作反向代理服务器.最近应客户的要求准备去掉F5,使用软负载.大家都知道nginx抗并发能力强,又可以做负载均衡,而且使用nginx对我们目前的网站架构不会有大的变动,所以首选方案是nginx.但问题来了,nginx在会话保持这方面比较弱,用ip_hash做会话保持有很大的缺陷,它是通过客户端ip来实现,根据访问ip的hash结果分配请求到后端的app服务器,负载不会很均匀.之前在一个小项目前中使用过这种方法,已经得到验

浏览器禁用Cookie,基于Cookie的会话跟踪机制失效的解决办法

当浏览器禁用Cookies时,基于Cookie的会话跟踪机制就会失效,解决办法是利用URL重写机制跟踪用户会话. 在使用URL重写机制的时候需要注意,为了保证会话跟踪的正确性,所有的链接和重定向语句中的URL都需要调用encodeURL()或encodeRedirectURL()方法进行编码.另外,由于附加在URL中的SessionID是动态产生的,对于每一个用户都是不同的,所欲对于静态页面的相互跳转,URL重写机制就无能为力了,但是,我们也可以通过将静态页面转换为动态页面来解决这个问题. 在w