sso

原文是一个系列： http://www.cnblogs.com/baibaomen/p/sso.html ，曾上博客园推荐榜首。建议看原文，此处排版全乱了。转载需注明原文链接。 单点登录SSO概述 本系列将由浅入深的，带大家掌握最新单点登录SSO方案选型，以及架构开发实战。系列将结合示例、源码以及演示视频，让大家能够直观、深入学习。 文末附5个满足不同单点登录场景的gif动画演示。本系列后继文章会深入它们的实现方式以及适用场景，大家也可以先观看揣摩其实现。单点登录即Single Sign On（SSO）。它是大型政府OA、企事业单位OA的标配解决方案。它概言之就是在多个Web、桌面或移动应用系统中，用户只需要登录一次，就可以访问所有的应用系统。 从业十多年，为政府、电信、跨国公司顾问和实施的单点登录解决方案无数，深谙其痛点与关键。 和很多人直观猜测相反，单点登录方案的定制性很强。很多企业的单点登录，实施是有问题的。尤其是被一些软件产品的销售人员牵着走的企业，它的单点登录方案实施，从产品方案选型起就存在根本性问题。这些方案常常要求大量现有业务系统的改造（基于统一身份认证服务，采用OpenId，OAuth，SAML等技术创建和传递认证凭据），或者只是体验较差的类似浏览器自动填充账号密码的功能（如Oracle的ESSO）。它们要么改动面大、周期长，要么服务端和客户端局限性多

单点登录SSO 一.单点登录SSO(只提供思路,不提供实现) 什么是单点登录？单点登录全称Single Sign On（以下简称SSO），是指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分(类似在新浪微博与新浪博客那样子) 二. 思路 (以java web来讲解) 1.相比于单系统登录，sso需要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，sso认证中心验证用户的用户名密码没问题，创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。 2.在web中怎么实现,也就是说在浏览器中怎么知道用户使用的多个系统是否是你的多个系统且是否登录了呢 ———————————————-cookie 3.使用cookie 来验证用户是否登录有3种情况, (1.)所有子系统与认证中心系统同域 (类似 www.a.com/sso1 www.a.com/case1 www.a.com/case2 ) (2.)所有子系统与认证中心系统同父域 (类似 case.a.com/sso1 case1.a.com/case1 case2.a.com/case2 )

study 全栈工程师学习笔记，不求最深最好，只做开源技术的搬运工 全包括系统登录和Spring登录和shiro登录、CAS单点登录和Spring boot oauth2单点登录、Spring data cache 缓存、web安全、redis、mq等组件的实践、quartz定时任务持久化到数据库、docker以及常用image、mybatis实践、spring、spring boot常用集成等知识点的实践 会持续进行更新维护，总结一些平时使用的小技术点 github链接 https://github.com/bage2014/study 模块说明 按照创建顺序 (不是按照显示顺序) 说明如下 项目模块 项目说明 study-spring-boot spring-boot 学习笔记 study-redis redis 学习笔记 study-docker docker 学习笔记 study-java java 学习笔记 study-cryption cryption 学习笔记 study-swagger swagger 学习笔记 study-spring-dependencies spring-dependencies 依赖模块 study-spring spring 学习笔记 study-utils utils 学习笔记 study-mybatis mybatis 学习笔记

　　 　　在日常生活中，很多人由于忘记某些网站的登录密码而烦恼，因为大多数用户都要记忆不少于10个用户名和相应密码。为了便于记忆，很多人都在不同的站点使用相同的用户名和密码，虽然这样可以减少负担，但是同时也降低了安全性，而且使用不同的站点同样要进行多次登录。同时，随着信息化飞速发展，大型企业和政府部门等都开始使用电子系统进行办公，而且整个办公系统由多个不同的子系统构成，如办公自动化(OA)系统，财务管理系统，档案管理系统，信息查询系统等。如果每个系统都使用独立的登录和验证机制，那么每天工作人员都要登录不同的系统进行办公。用户登录的频繁操作，降低了员工的工作效率，造成工作成本的浪费。而大量的密码和用户名的记忆时间长了也会出现问题，忘记密码或者混淆密码都会造成很大的麻烦。基于以上原因，为用户提供一个畅通的登录通道变得十分重要。 　　单点登录(SingleSign-On，SSO)是一种帮助用户快捷访问网络中多个站点的安全通信技术。单点登录系统基于一种安全的通信协议，该协议通过多个系统之间的用户身份信息的交换来实现单点登录。使用单点登录系统时， 用户只需要登录一次，就可以访问多个系统 ，不需要记忆多个口令密码。单点登录使用户可以快速访问网络，从而提高工作效率，同时也能帮助提高系统的安全性。 来源： https://www.cnblogs.com/wq-9/p/11947535.html

单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。实现单点登录说到底就是要解决如何产生和存储那个信任，再就是其他系统如何验证这个信任的有效性，因此要点也就以下几个： 存储信任 验证信任 只要解决了以上的问题，达到了开头讲得效果就可以说是SSO。最简单实现SSO的方法就是用Cookie，实现流程如下所示： 不然发现以上的方案是把信任存储在客户端的Cookie里，这种方法虽然实现方便但立马会让人质疑两个问题： Cookie不安全 不能跨域免登 对于第一个问题一般都是通过加密Cookie来处理，第二个问题是硬伤，其实这种方案的思路的就是要把这个信任关系存储在客户端，要实现这个也不一定只能用Cookie，用flash也能解决，flash的Shared Object API就提供了存储能力。 一般说来，大型系统会采取在服务端存储信任关系的做法，实现流程如下所示： 以上方案就是要把信任关系存储在单独的SSO系统（暂且这么称呼它）里

环境：vmware centos7.4 工具：ab压力测试工具 测试对象：sso单点登录系统 电脑：win10 4核 项目环境：flask+uwsgi+nginx（uwsgi 2进程，4线程） 1. 100个用户，总共100个请求 测试截图 2. 500个用户，总共500个请求 测试截图 500个用户并发0.86秒， 3. 1000个用户并发，总共1000个请求 测试截图 1000个并发1.622，4进程4线程可以接受啊，如果加了协程是不是更快一点 4. 2000个用户并发，总共2000个请求 测试截图 测试用例： 结论 1000个并发登录才一秒，完全可以接受啊，毕竟csdn登录的时候都要1秒多，以后要买个带宽高的服务器，和上一篇对比简直是天壤之别啊！ 来源： https://www.cnblogs.com/vinic-xxm/p/11908688.html

回顾 在前几天，我使用apache+tomcat搭建了一个集群，有一个简单的网站应用。 Apache httpd与tomcat集群 。 今天在此基础上，我要为其开发一个登录页面，并开启网站的认证和授权。 基本概念 在动手之前，我需要先了解网站认证和授权的几个基本组成部分的概念。是什么构成了网站应用的认证和授权？ Realm - 翻译过来叫做“域”。Realm是web容器所持有的用户集合。无论tomcat, glassfish,jboss还是websphere，均是符合j2ee规范或最佳实现。Realm是需要网站系统管理员进行配置的。常见的Realm有三种：数据库，LDAP和文件系统。数据库realm是指用户信息都存在数据库中，Ldap则存放在ldap中，文件系统的realm则是用户信息按照一定的格式，存放于文件中。Realm是认证的关键，web容器会将用户输入的用户名和密码跟realm中的用户信息进行比对。当比对成功的时候，认证也就成功了。 Role - 角色。 这是授权的部分。当Realm被配好以后，系统管理员可以为realm中的用户分配角色。建立用户role-mapping. 每次用户通过web容器的认证以后，web容器会将其role信息也查询出来，放入用户信息中。 security-constraint。 这是web应用web.xml中的配置。 一个web应用将在web

CAS实现SSO单点登录原理 1. CAS 简介 1.1. What is CAS ？ CAS （ Central Authentication Service ） 是 Yale 大学发起的一个企业级的、开源的项目，旨在为 Web 应用系统提供一种可靠的单点登录解决方法（属于 Web SSO ）。 CAS 开始于 2001 年， 并在 2004 年 12 月正式成为 JA-SIG 的一个项目。 1.2. 主要特性 1、 开源的、多协议的 SSO 解决方案； Protocols ： Custom Protocol 、 CAS 、 OAuth 、 OpenID 、 RESTful API 、 SAML1.1 、 SAML2.0 等。 2、 支持多种认证机制： Active Directory 、 JAAS 、 JDBC 、 LDAP 、 X.509 Certificates 等； 3、 安全策略：使用票据（ Ticket ）来实现支持的认证协议； 4、 支持授权：可以决定哪些服务可以请求和验证服务票据（ Service Ticket ）； 5、 提供高可用性：通过把认证过的状态数据存储在 TicketRegistry 组件中，这些组件有很多支持分布式环境的实现，如： BerkleyDB 、 Default 、 EhcacheTicketRegistry 、

第一节：单点登录简介 第一步：了解单点登录 SSO主要特点是: SSO应用之间使用Web协议(如HTTPS) ，并且只有一个登录入口. SSO的体系中有下面三种角色: 1) User(多个) 2) Web应用(多个) 3) SSO认证中心(一个) SSO实现包含以下三个原则: 1) 所有的登录都在 SSO 认证中心进行。 2) SSO认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是通过认证的用户. 3) SSO认证中心和所有的 Web 应用建立一种信任关系. CAS的基本原理CAS(Central Authentication Service) 是 Yale 耶鲁大学发起的构建Web SSO的Java开源项目。 1.CAS术语解释: SSO－Single Sign On单点登录 TGT－Ticket Granting Ticket 用户身份认证凭证票据 ST－Service Ticket服务许可凭证票据 TGC－Ticket Granting Cookie存放用户身份认证凭证票据的cookie. 第二步：了解单点登录体系结构 1) CAS Server负责完成对用户信息的认证，需要单独部署，CAS Server会处理用户名/密码等凭证(Credentials). 2) CAS Client部署在客户端，当有对本地Web应用受保护资源的访问请求，并且需要对请求方进行身份认证

一、简介 1、cas是有耶鲁大学研发的单点登录服务器 2、所用环境 · Linux系统 · Tomcat7.0 · JDK1.7 · CAS Service 版本 CAS Server 3.5.2 Release · CAS Client版本 cas-client-3.3.3-release 二、生成证书 证书对于实现此单点登录非常之重要，证书是服务器端和客户端安全通信的凭证，目前只是使用了JDK自带的证书生成工具keytool。 1、用JDK自带的keytool生成证书 keytool -genkey -alias demo -keyalg RSA -keystore /home/ Java /keys/demo 此命令是生成一个证书，其中 demo 是证书别名 此命令的执行如图所示： 其中名字与姓氏这一写你的 域名 ，如果在单击测试你可以在C:\Windows\System32\drivers\etc\hosts文件中映射一个虚拟域名， 注意不要写 IP 。 结果可以在/home/java/keys文件夹下生产demo文件，刚才输入的密码为1qaz2wsx 2、导出证书 keytool -export -file/home/java/keys/demo.crt -alias demo -keystore /home/java/keys/demo