单点登录

　　 　　在日常生活中，很多人由于忘记某些网站的登录密码而烦恼，因为大多数用户都要记忆不少于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系统（暂且这么称呼它）里

单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞疯掉。实现单点登录说到底就是要解决如何产生和存储那个信任，再就是其他系统如何验证这个信任的有效性，因此要点也就以下两个： 存储信任 验证信任 如果一个系统做到了开头所讲的效果，也就算单点登录，单点登录有不同的实现方式，本文就罗列我开发中所遇见过的实现方式。 以Cookie作为凭证媒介 最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。 用户登录父应用之后，应用返回一个加密的cookie，当用户访问子应用的时候，携带上这个cookie，授权应用解密cookie并进行校验，校验通过则登录当前用户。 Auth via cookie 不难发现以上方式把信任存储在客户端的Cookie中，这种方式很容易令人质疑： Cookie不安全 不能跨域实现免登 对于第一个问题，通过加密Cookie可以保证安全性，当然这是在源代码不泄露的前提下。如果Cookie的加密算法泄露

1. 单点登录概述 所谓单点登录（SSO），只当企业用户同时访问多个不同（类型的）应用时，他们只需要提供自身的用户凭证信息（比如用户名/密码）一次，仅仅一次。SSO解决方案（比如，CAS）负责统一认证用户，如果需要，SSO也可以完成用户的授权处理。可以看出，当企业用户在不同的应用间切换时，他们不用再重复地输入自身的用户凭证了。在实施SSO后，所用的认证操作都将交给SSO认证中心。现有的SSO解决方案非常多，比如微软的MSN Passport便是典型的SSO解决方案，各Java EE容器都提供了自身的专有SSO能力。 2. CAS 的总体架构 1. CAS 简介 CAS（中央认证服务）是建立在非常开放的协议之上的企业级SSO解决方案。诞生于2001年，在2002年发布了CAS2.0协议，这一新的协议提供了Proxy（代理）能力，此时的CAS2.0支持多层SSO能力。到2005年，CAS成为了JA-SIG旗下的重要子项目。由于CAS2.0版本的可扩展能力不是非常完美，而且他的架构设计也不是很卓越，为了使得CAS能够适用于更多场合，JA-SIG打算开发出同时遵循CAS1.0和CAS2.0协议的CAS3.X版本。 现在的CAS3全面拥抱Spring技术，比如Spring DI容器和AOP技术、Spring Web MVC、Spring Web Flow、Spring Ldap

todo 来源： https://www.cnblogs.com/can-i-do/p/11884907.html

参考文献 单点登录与单点注销： https://www.cnblogs.com/zhuchenglin/p/8968530.html 来源： https://www.cnblogs.com/erdanyang/p/11863894.html

一、简介 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

CAS是一个开源的单点登录解决方案。github地址：http://jasig.github.io/cas 具体什么是单点登录，以及其基本原理，这里先不写了，下次再具体写。 今天只记录一下cas的基本搭建过程。 首先从它的网站上下载cas-server。 最新的4.2.x的是通过gradle构建的，如果不会用grad了就找稍微老一点的版本，以前的版本是可以用maven构建的。如果maven也不会用，或者懒得自己编译，可以找3.5.x及以前的版本，有直接编译好的。 自己编译的话也不是一定要把所有的都编译出来，只要前面几个基本的server-core和server-webapp就可以了。cas-server-webapp编译出来是一个war包，把它扔到tomcat里面就可以了。 然后是客户端，客户端不用自己去下源码编译了，已经都发布在maven仓库里了。 在自己的web工程的pom里加入cas客户端： <dependency> <groupId>org.jasig.cas.client</groupId> <artifactId>cas-client-core</artifactId> <version>3.4.1</version> </dependency> 然后在web.xml里加上过滤器： <!-- 该过滤器负责用户的认证工作 --> <filter> <filter-name

SSO介绍 SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。 方案 -1. 可以配置tomcat的session共享。配置tomcat集群。Tomcat配置好集群后，会不停的向集群中其他的tomcat广播自己的session信息。其他的tomcat做session同步。可以保证所有的tomcatsession中的内容都是一致的。 优点：不用修改代码就可以实现session共享。 缺点：tomcat 是全局session复制，集群内每个tomcat的session完全同步（也就是任何时候都完全一样的) 在大规模应用的时候，用户过多，集群内tomcat数量过多，session的全局复制会导致集群性能下降， 因此，tomcat的数量不能太多，5个以下为好。 -2. 实现单点登录系统，提供服务接口。把session数据存放在redis。 Redis可以设置key的生存时间、访问速度快效率高。 优点：redis存取速度快，不会出现多个节点session复制的问题。效率高。 缺点：需要额外的开发。 -3.用一种新的基于 JWT 的 token 方式来实现，python-jwt 生成与校验,简单来说

在项目中遇到SAML企业应用 想留个后门时候一脸懵 随便的整理记录 记录项目中SAML渗透的知识点。 0x01 前置知识 SAML单点登陆 SAML（Security Assertion Markup Language）是一个XML框架，也就是一组协议，可以用来传输安全声明。比如，两台远程机器之间要通讯，为了保证安全，我们可以采用加密等措施，也可以采用SAML来传输，传输的数据以XML形式，符合SAML规范，这样我们就可以不要求两台机器采用什么样的系统，只要求能理解SAML规范即可，显然比传统的方式更好。SAML 规范是一组Schema 定义。 Web Service 领域，schema就是规范，在Java领域，API就是规范。 SAML 作用 SAML 主要包括三个方面： 1.认证申明。表明用户是否已经认证，通常用于 单点登录。 2.属性申明。表明 某个Subject 的属性。 3.授权申明。表明 某个资源的权限。 SAML框架 SAML就是客户向服务器发送SAML 请求，然后服务器返回SAML响应。数据的传输以符合SAML规范的XML格式表示。 SAML 可以建立在SOAP上传输，也可以建立在其他协议上传输。 因为SAML的规范由几个部分构成： SAML Assertion，SAML Prototol，SAML binding 等 SAML在单点登录中大有用处 ：在 SAML