java实现单点登录的两种方式
1.如果两个网站域名的一级域名相同，可以使用cookie和filter实现单点登录，因为网站有可能（具体看cookie的设置）可以共享cookie。例如：www.bbs.aa.cn www.news.aa.cn。
第一个网站在登录后，把用户信息写到cookie中，当访问第二个网站时，第二个网站先经过自己的filter，检查session，如果没有，查询cookie，取出用户信息，放在session中登录。
\
1其实单点登录很简单
单点登录的技术实现机制：当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录;根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据--ticket;用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
可以看出，要实现SSO，需要以下主要的功能：
a) 所有应用系统共享一个身份认证系统;
b) 所有应用系统能够识别和提取ticket信息;
c) 应用系统能够识别已经登录过的用户，能自动判断当前用户是否登录过，从而完成单点登录的功能
基于以上基本原则，本人用php语言设计了一套单点登录系统的程序，目前已投入正式生成服务器运行。本系统程序，将ticket信息以全系统唯一的 session id作为媒介，从而获取当前在线用户的全站信息(登陆状态信息及其他需要处理的用户全站信息)。
二. 过程说明：
登陆流程:
1. 第一次登陆某个站：
a) 用户输入用户名+密码,向用户验证中心发送登录请求
b) 当前登录站点，通过webservice请求,用户验证中心验证用户名，密码的合法性。如果验证通过，则生成ticket，用于标识当前会话的用户，并将当前登陆子站的站点标识符记录到用户中心，最后
c) 将获取的用户数据和ticket返回给子站。如果验证不通过，则返回相应的错误状态码。
d) 根据上一步的webservice请求返回的结果，当前子站对用户进行登陆处理：如状态码表示成功的话，则当前站点通过本站cookie保存ticket，并本站记录用户的登录状态。状态码表示失败的话，则给用户相应的登录失败提示。
2. 登陆状态下，用户转到另一子：
a) 通过本站cookie或session验证用户的登录状态：如验证通过，进入正常本站处理程序;否则户中心验证用户的登录状态(发送ticket到用户验证中心)，如验证通过，则对返回的用户信息进行本地的登录处理，否则表明用户未登录。
登出流程
a) 当前登出站清除用户本站的登录状态 和 本地保存的用户全站唯一的随机id
b) 通过webservice接口，清除全站记录的全站唯一的随机id。webservice接口会返回，登出其他已登录子站的javascript代码，本站输出此代码。
c) js代码访问相应站W3C标准的登出脚本
WEB的登录那些事
说道账户登录和注册，其实我们每天都在亲身感受着，像微博、知乎还有简书等等。我们总是需要定期的去重新登录一下，对于这种认证机制，我们都能说出来两个名词，Cookie、Session。的确没错，Cookie和Session是实现这一切的核心。
为什么会有Cookie和Session？区别是什么？
引入这两个概念的根本原因是因为Http协议是无状态的，也就是说它不能建立起多次请求之间的关系。所以需要引入一个能有浏览器或服务器保存的一个上下文状态，也就是Cookie和Session。说到底Session的实现是依赖于Cookie的，因为Cookie是真正的由浏览器保存的状态，Session是利用了JSessionID。在我看来其实两者有差异，但是根本的依赖是一样的。Cookie也是有生命周期的，像Session级别或者有一定“寿命”的Cookie。一切是由浏览器去维护的。
常见的跨域登录问题
之前楼主主要是做账户和Passport这方面的工作，其实在跨域这也是碰见了一些问题。
对于同一个根域下的登录问题
如果我们的站点有不止一个业务，那么他们可能部署在不同的机器上，也往往需要不同的域名进行区分。但是所有的业务又都是依赖于一套账户体系，那么我们这时候需要通过一次登录解决所有站点的登录问题，那么我们这个时候可以使用一个最笨的方法：那就是一次登录成功，将Cookie写到根域下，那么这样所有的站点就能实现，同一个根域下的Cookie共享，自然实现了”单点登录“。
对于多个根域下的登录问题
如果是多个根域名，那么这种情况下上面的机制就不能实现“单点登录”了。因为之所以上面可以实现“单点登录”的效果。是因为浏览器和Http协议的支持。但是对于跨根域的站点之间进行Cookie的共享是比较复杂的。
方法1:登录成功之后将Cookie回写到多个域名下。
这种办法可能十分简单，你可以通过后端的response写修改的是响应头信息 ，也可以用前端js去写，但是必须有对所有需要“单点登录”的站点进行逐一的写入。用脚想这种办法也是行不通的，因为你需要维护一个站点的列表，维护工作十分复杂，同时对于增加站点也会特别痛苦。对于Cookie的销毁也是十分复杂的，因为还是要对所有域名下的Cookie进行删除。也就是说将原来需要做的工作增加了n倍。对于小型站点这种办法是可取的。
方法２:jsonp
搞过前端的可能都知道用jsonp可以做跨域的请求，而我们解决的就是多个域下的统一登录的问题，好像很顺理成章的样子。但是，登录是Server端做的吧？我们在Client端做跨域的处理，这怎么看也不是很合理。同时这种办法需要很大的维护成本，每一次请求都要去固定的域下取相应的Cookie之后再做请求。想想维护有头疼。
方法3 :引入一个中间态的Server
这种办法算是一个简化版的SSO，实现思想也十分的“狡猾”。但是对于小网站做跨域登录的处理却十分的有用，具体思路如下：
首先，我们有两个域名要实现单点登录，同时我们需要一个中间的Server。
我们有一个系统域名为javahelp.com.cn,当我们登录的时候访问javahelp.com.cn/wp-login进行登录，登录成功之后将Cookie回写到javahelp这个域名下。
我们还有一个系统域名为javaWeb.com，当我们访问inside-javaWeb的时候，我们没有Cookie，那么请求跳转到中间系统jump。此时需要将当前域名带到参数中便于jump校验。这个jump系统是在javahelp域下的即：jump.javahelp.net。这时候就能拿到之前写在javahelp域下的Cookie。
jump系统在收到了xulingbo域下的Cookie之后，取出xulingbo域下的Cookie，并redirect请求jump.inside-javaWeb.net,这个接口也是在jump系统中，请求后jump系统将Cookie回写到inside-javaWeb域名下，这样就实现了简易的单点登录。如下图所示：
Paste_Image.png
但是这种方式不是很灵活，对于数据传输的安全性没有保障，并且在销毁Cookie的时候无能为力，只能全部遍历的销毁。
方法4：基于CAS的SSO系统
CAS可不是java中的Compare-And-Swap，它是一个开源的单点登录系统(SSO)。实现的机制不算复杂但是思想十分灵巧。用CAS也可以快速实现单点登录。盗图一张说明sso单个域的登录和验证流程：
Paste_Image.png
CAS主要分为CAS Client 和CAS Server ，其中Client主要是内嵌在需要SSO登录站点的拦截器或过滤器上。
首先浏览器向站点1发起请求。
站点1发现当前请求没有合法的Cookie，那么重定向到CAS Server上，也就是SSO Server。
CAS Server展示登录界面，要求用户登录。
用户登录后，会写CAS Server的Cookie到浏览器，同时生产ticket，利用一个302跳转到CASClient。这样能保证用户无感知。
CAS Client利用生成的ticket发送到CAS Server进行验证，验证通过后，站点1生成自己的Cookie并回写到用户浏览器，然后进行登录成功的跳转。
这样就能保证当前浏览器在站点1的域名下，有站点1的Cookie，同时当前浏览器也有CAS Server的Cookie。
接下来看下站点2的登录：
Paste_Image.png
站点2，在进行登录时和站点1初次登录流程一致，但是在访问CAS Server的时候，由于当前浏览器已经有了CAS Server的Cookie，那么直接校验通过返回ticket。
ticket通过302跳转跳转到CAS Client上，之后的流程就和站点1是一样的了。如果此时认证失败，那么需要重新走一次登录的过程。
其实感觉很麻烦，但是流程却十分的简单，主要是使用CAS Server的Cookie做校验，同时各自系统维护自己的Cookie。
注意的问题：
CAS Server的Cookie劫持问题，如果CAS Server的Cookie被劫持掉，那么就相当于拿到了一切，所以必须要用HTTPS实现这个过程。
ticket的使用，ticket只能被使用一次，一次校验后立即失效。同时需要有时效性，一般5分钟。最后ticket生成规则要随机，不能被碰撞出来。
对于各自系统自己的Session，也可以依赖于SSO，这样就能保证所有的Session规则一致，便于集中控制。
其实SSO的实现很灵活，CAS只是说了一个原理，至于具体怎么实现，需要平衡安全性、易用性等诸多因素，所以也没有一个固定的实现方案。
SSO之CAS单点登录实例演示
一、概述
此文的目的就是为了帮助初步接触SSO和CAS 的人员提供一个入门指南，一步一步演示如何实现基于CAS的单点登录。
CAS的官网：http://www.jasig.org/cas
二、演示环境
本文演示过程在同一个机器上的（也可以在三台实体机器或者三个的虚拟机上），环境如下：
windows7 64位，主机名称：michael-pc
JDK 1.6.0_18
Tomcat 6.0.29
CAS-server-3.4.11、CAS-client-3.2.1
根据演示需求，用修改hosts 文件的方法添加域名最简单方便（这个非常重要），在文件 C:\Windows\System32\drivers\etc\hosts 文件中添加三条
127.0.0.1 demo.micmiu.com
127.0.0.1 app1.micmiu.com
127.0.0.1 app2.micmiu.com
demo.micmiu.com=>> 对应部署cas server的tomcat，这个虚拟域名还用于证书生成
app1.micmiu.com=>> 对应部署app1 的tomcat
app2.micmiu.com=>> 对应部署app2 的tomcat
三、JDK安装配置
这个详细过程就不在描述，如果是免安装版的，确保环境变量配置正确。
本机环境变量：JAVA_HOME=D:\jdk，如果看到以下信息则表示安装成功：
四、安全证书配置
有关keytool工具的详细运用见：http://www.micmiu.com/lang/java/keytool-start-guide/
4.1. 生成证书：
1keytool -genkey -alias ssodemo -keyalg RSA -keysize 1024 -keypass michaelpwd -validity 365 -keystore g:\sso\ssodemo.keystore -storepass michaelpwd
截图中需要输入的姓名和上面hosts文件中配置的一致；
keypass 和 storepass 两个密码要一致，否则下面tomcat 配置https 访问失败；
4.2.导出证书：
1keytool -export -alias ssodemo -keystore g:\sso\ssodemo.keystore -file g:\sso\ssodem
4.3.客户端导入证书：
1keytool -import -keystore %JAVA_HOME%\jre\lib\security\cacerts -file g:\sso\ssodemo.crt -alias ssodem
ps：该命令中输入的密码和上面输入的不是同一个密码；如果是多台机器演示，需要在每一台客户端导入该证书。
五、部署CAS-Server相关的Tomcat
5.1. 配置HTTPS
解压apache-tomcat-6.0.29.tar.gz并重命名后的路径为 G:\sso\tomcat-cas，在文件 conf/server.xml文件找到：
修改成如下：
参数说明：
keystoreFile 就是4.1中创建证书的路径
keystorePass 就是4.1中创建证书的密码
5.2. 验证HTTPS配置
其他按照默认配置不作修改，双击%TOMCAT_HOME%\bin\startup.bat 启动tomcat-cas 验证https访问配置:
如果看到上述界面表示https 访问配置成功。
5.3 部署CAS-Server
CAS-Server 下载地址：http://www.jasig.org/cas/download
本文以cas-server-3.4.11-release.zip 为例，解压提取cas-server-3.4.11/modules/cas-server-webapp-3.4.11.war文件，把改文件copy到 G:\sso\tomcat-cas\webapps\ 目下，并重命名为：cas.war.
启动tomcat-cas，在浏览器地址栏输入：https://demo.micmiu.com:8443/cas/login ，回车
CAS-server的默认验证规则：只要用户名和密码相同就认证通过（仅仅用于测试，生成环境需要根据实际情况修改），输入admin/admin 点击登录，就可以看到登录成功的页面：
看到上述页面表示CAS-Server已经部署成功。
六、部署CAS-Client相关的Tomcat
6.1Cas-Client 下载
CAS-Client 下载地址：http://downloads.jasig.org/cas-clients/
以cas-client-3.2.1-release.zip 为例，解压提取cas-client-3.2.1/modules/cas-client-core-3.2.1.jar
借以tomcat默认自带的 webapps\examples 作为演示的简单web项目
6.2 安装配置 tomcat-app1
解压apache-tomcat-6.0.29.tar.gz并重命名后的路径为 G:\sso\tomcat-app1，修改tomcat的启动端口，在文件conf/server.xml文件找到如下内容：
修改成如下：
启动tomcat-app1，浏览器输入 http://app1.micmiu.com:18080/examples/servlets/ 回车：
看到上述界面表示tomcat-app1的基本安装配置已经成功。
接下来复制 client的lib包cas-client-core-3.2.1.jar到 tomcat-app1\webapps\examples\WEB-INF\lib\目录下， 在tomcat-app1\webapps\examples\WEB-INF\web.xml文件中增加如下内容：
有关cas-client的web.xml修改的详细说明见官网介绍：
https://wiki.jasig.org/display/CASC/Configuring+the+Jasig+CAS+Client+for+Java+in+the+web.xml
6.3 安装配置 tomcat-app2
解压apache-tomcat-6.0.29.tar.gz并重命名后的路径为 G:\sso\tomcat-app2，修改tomcat的启动端口，在文件 conf/server.xml文件找到如下内容：
修改成如下：
启动tomcat-app2，浏览器输入 http://app2.micmiu.com:28080/examples/servlets/ 回车，按照上述6.2中的方法验证是否成功。
同6.2中的复制 client的lib包cas-client-core-3.2.1.jar到 tomcat-app2\webapps\examples\WEB-INF\lib\目录下， 在tomcat-app2\webapps\examples\WEB-INF\web.xml文件中增加如下内容：
七、 测试验证SSO
启动之前配置好的三个tomcat分别为：tomcat-cas、tomcat-app1、tomcat-app2.
7.1 基本的测试
预期流程： 打开app1url —-> 跳转cas server 验证 —-> 显示app1的应用 —-> 打开app2url —-> 显示app2应用 —-> 注销cas server —-> 打开app1/app2 url —-> 重新跳转到cas server 验证.
打开浏览器地址栏中输入：http://app1.micmiu.com:18080/examples/servlets/servlet/HelloWorldExample，回车：
跳转到验证页面：
验证通过后显示如下：
此时访问app2就不再需要验证：
地址栏中输入：https://demo.micmiu.com:8443/cas/logout，回车显示：
上述表示 认证注销成功，此时如果再访问 : http://app1.micmiu.com:18080/examples/servlets/servlet/HelloWorldExample 或 http://app2.micmiu.com:28080/examples/servlets/servlet/HelloWorldExample 需要重新进行认证。
7.2 获取登录用户的信息
修改类：webapps\examples\WEB-INF\classes\HelloWorldExample.java 后重新编译并替换 webapps\examples\WEB-INF\classes\HelloWorldExample.class文件。
HelloWorldExample.java修改后的代码如下：
再进行上述测试显示结果如下：
http://app1.micmiu.com:18080/examples/servlets/servlet/HelloWorldExample ：
http://app2.micmiu.com:28080/examples/servlets/servlet/HelloWorldExample
从上述页面可以看到通过认证的用户名。
到此已经全部完成了CAS单点登录实例演示
作者：Java帮帮
链接：https://www.jianshu.com/p/fdb02c641918
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。