java代码跨域sso java实现跨域

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

JAVA跨域问题

跨域问题一般都在后台程序解决，将自己的程序通过配置文件或者代码将其允许跨域，

在有跨域安全的时候，所有前端post请求时，会发送一个与其请求名字一样的OPTIONS

此请求没有任何参数，此机制为post不知道是否有权限请求接口，发送了一个探知请求，探知

请求确认后，允许访问后调用正常Post接口。不允许就会出现你现在的问题跨域异常。

萌新，java是开源的，比NET好多了，多看看底层

相关问答

Q1: java web应用如何实现单点登录

实现方式一：父域 Cookie

实现方式二：认证中心

实现方式三：LocalStorage 跨域

补充：域名分级

在 B/S 系统中，登录功能通常都是基于 Cookie 来实现的。当用户登录成功后，一般会将登录状态记录到 Session 中，或者是给用户签发一个 Token，无论哪一种方式，都需要在客户端保存一些信息（Session ID 或 Token ），并要求客户端在之后的每次请求中携带它们。在这样的场景下，使用 Cookie 无疑是最方便的，因此我们一般都会将 Session 的 ID 或 Token 保存到 Cookie 中，当服务端收到请求后，通过验证 Cookie 中的信息来判断用户是否登录。

单点登录（Single Sign On, SSO）是指在同一帐号平台下的多个应用系统中，用户只需登录一次，即可访问所有相互信任的应用系统。举例来说，百度贴吧和百度地图是百度公司旗下的两个不同的应用系统，如果用户在百度贴吧登录过之后，当他访问百度地图时无需再次登录，那么就说明百度贴吧和百度地图之间实现了单点登录。

单点登录的本质就是在多个应用系统中共享登录状态。如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session，比如可以将 Session 序列化到 Redis 中，让多个应用系统共享同一个 Redis，直接读取 Redis 来获取 Session。

当然仅此是不够的，因为不同的应用系统有着不同的域名，尽管 Session 共享了，但是由于 Session ID 是往往保存在浏览器 Cookie 中的，因此存在作用域的限制，无法跨域名传递，也就是说当用户在 app1.com 中登录后，Session ID 仅在浏览器访问 app1.com 时才会自动在请求头中携带，而当浏览器访问 app2.com 时，Session ID 是不会被带过去的。实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

实现方式一：父域 Cookie

在将具体实现之前，我们先来聊一聊 Cookie 的作用域。

Cookie 的作用域由 domain 属性和 path 属性共同决定。domain 属性的有效值为当前域或其父域的域名/IP地址，在 Tomcat 中，domain 属性默认为当前域的域名/IP地址。path 属性的有效值是以“/”开头的路径，在 Tomcat 中，path 属性默认为当前 Web 应用的上下文路径。

如果将 Cookie 的 domain 属性设置为当前域的父域，那么就认为它是父域 Cookie。Cookie 有一个特点，即父域中的 Cookie 被子域所共享，换言之，子域会自动继承父域中的Cookie。

利用 Cookie 的这个特点，不难想到，将 Session ID（或 Token）保存到父域中不就行了。没错，我们只需要将 Cookie 的 domain 属性设置为父域的域名（主域名），同时将 Cookie 的 path 属性设置为根路径，这样所有的子域应用就都可以访问到这个 Cookie 了。不过这要求应用系统的域名需建立在一个共同的主域名之下，如 tieba.baidu.com 和 map.baidu.com，它们都建立在 baidu.com 这个主域名之下，那么它们就可以通过这种方式来实现单点登录。

总结：此种实现方式比较简单，但不支持跨主域名。

实现方式二：认证中心

我们可以部署一个认证中心，认证中心就是一个专门负责处理登录请求的独立的 Web 服务。

用户统一在认证中心进行登录，登录成功后，认证中心记录用户的登录状态，并将 Token 写入 Cookie。（注意这个 Cookie 是认证中心的，应用系统是访问不到的。）

应用系统检查当前请求有没有 Token，如果没有，说明用户在当前系统中尚未登录，那么就将页面跳转至认证中心。由于这个操作会将认证中心的 Cookie 自动带过去，因此，认证中心能够根据 Cookie 知道用户是否已经登录过了。如果认证中心发现用户尚未登录，则返回登录页面，等待用户登录，如果发现用户已经登录过了，就不会让用户再次登录了，而是会跳转回目标 URL ，并在跳转前生成一个 Token，拼接在目标 URL 的后面，回传给目标应用系统。

应用系统拿到 Token 之后，还需要向认证中心确认下 Token 的合法性，防止用户伪造。确认无误后，应用系统记录用户的登录状态，并将 Token 写入 Cookie，然后给本次访问放行。（注意这个 Cookie 是当前应用系统的，其他应用系统是访问不到的。）当用户再次访问当前应用系统时，就会自动带上这个 Token，应用系统验证 Token 发现用户已登录，于是就不会有认证中心什么事了。

这里顺便介绍两款认证中心的开源实现：

Apereo CAS 是一个企业级单点登录系统，其中 CAS 的意思是”Central Authentication Service“。它最初是耶鲁大学实验室的项目，后来转让给了 JASIG 组织，项目更名为 JASIG CAS，后来该组织并入了Apereo 基金会，项目也随之更名为 Apereo CAS。

XXL-SSO 是一个简易的单点登录系统，由大众点评工程师许雪里个人开发，代码比较简单，没有做安全控制，因而不推荐直接应用在项目中，这里列出来仅供参考。

总结：此种实现方式相对复杂，支持跨域，扩展性好，是单点登录的标准做法。

实现方式三：LocalStorage 跨域

前面，我们说实现单点登录的关键在于，如何让 Session ID（或 Token）在多个域中共享。

父域 Cookie 确实是一种不错的解决方案，但是不支持跨域。那么有没有什么奇淫技巧能够让 Cookie 跨域传递呢？

很遗憾，浏览器对 Cookie 的跨域限制越来越严格。Chrome 浏览器还给 Cookie 新增了一个 SameSite 属性，此举几乎禁止了一切跨域请求的 Cookie 传递（超链接除外），并且只有当使用 HTTPs 协议时，才有可能被允许在 AJAX 跨域请求中接受服务器传来的 Cookie。

不过，在前后端分离的情况下，完全可以不使用 Cookie，我们可以选择将 Session ID （或 Token ）保存到浏览器的 LocalStorage 中，让前端在每次向后端发送请求时，主动将 LocalStorage 的数据传递给服务端。这些都是由前端来控制的，后端需要做的仅仅是在用户登录成功后，将 Session ID （或 Token ）放在响应体中传递给前端。

在这样的场景下，单点登录完全可以在前端实现。前端拿到 Session ID （或 Token ）后，除了将它写入自己的 LocalStorage 中之外，还可以通过特殊手段将它写入多个其他域下的 LocalStorage 中。

————————————————

原文链接：

前端通过 iframe+postMessage() 方式，将同一份 Token 写入到了多个域下的 LocalStorage 中，前端每次在向后端发送请求之前，都会主动从 LocalStorage 中读取 Token 并在请求中携带，这样就实现了同一份 Token 被多个域所共享。

总结：此种实现方式完全由前端控制，几乎不需要后端参与，同样支持跨域。

补充：域名分级

从专业的角度来说（根据《计算机网络》中的定义），.com、.cn 为一级域名（也称顶级域名），.com.cn、baidu.com 为二级域名，sina.com.cn、tieba.baidu.com 为三级域名，以此类推，N 级域名就是 N-1 级域名的直接子域名。

从使用者的角度来说，一般把可支持独立备案的主域名称作一级域名，如 baidu.com、sina.com.cn 皆可称作一级域名，在主域名下建立的直接子域名称作二级域名，如 tieba.baidu.com 为二级域名。

Q2: 用java来实现单点登录大概有哪些种方法

1 什么是单点登陆

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

较大的企业内部，一般都有很多的业务支持系统为其提供相应的管理和IT服务。例如财务系统为财务人员提供财务的管理、计算和报表服务；人事系统为人事部门提供全公司人员的维护服务；各种业务系统为公司内部不同的业务提供不同的服务等等。这些系统的目的都是让计算机来进行复杂繁琐的计算工作，来替代人力的手工劳动，提高工作效率和质量。这些不同的系统往往是在不同的时期建设起来的，运行在不同的平台上；也许是由不同厂商开发，使用了各种不同的技术和标准。如果举例说国内一著名的IT公司（名字隐去），内部共有60多个业务系统，这些系统包括两个不同版本的SAP的ERP系统，12个不同类型和版本的数据库系统，8个不同类型和版本的操作系统，以及使用了3种不同的防火墙技术，还有数十种互相不能兼容的协议和标准，你相信吗？不要怀疑，这种情况其实非常普遍。每一个应用系统在运行了数年以后，都会成为不可替换的企业IT架构的一部分，如下图所示。

随着企业的发展，业务系统的数量在不断的增加，老的系统却不能轻易的替换，这会带来很多的开销。其一是管理上的开销，需要维护的系统越来越多。很多系统的数据是相互冗余和重复的，数据的不一致性会给管理工作带来很大的压力。业务和业务之间的相关性也越来越大，例如公司的计费系统和财务系统，财务系统和人事系统之间都不可避免的有着密切的关系。

为了降低管理的消耗，最大限度的重用已有投资的系统，很多企业都在进行着企业应用集成（EAI）。企业应用集成可以在不同层面上进行：例如在数据存储层面上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等等。事实上，还用一个层面上的集成变得越来越重要，那就是“身份认证”的整合，也就是“单点登录”。

通常来说，每个单独的系统都会有自己的安全体系和身份认证系统。整合以前，进入每个系统都需要进行登录，这样的局面不仅给管理上带来了很大的困难，在安全方面也埋下了重大的隐患。下面是一些著名的调查公司显示的统计数据：

用户每天平均 16 分钟花在身份验证任务上 - 资料来源： IDS

频繁的 IT 用户平均有 21 个密码 - 资料来源： NTA Monitor Password Survey

49% 的人写下了其密码，而 67% 的人很少改变它们

每 79 秒出现一起身份被窃事件 - 资料来源：National Small Business Travel Assoc

全球欺骗损失每年约 12B - 资料来源：Comm Fraud Control Assoc

到 2007 年，身份管理市场将成倍增长至 $4.5B - 资料来源：IDS

使用“单点登录”整合后，只需要登录一次就可以进入多个系统，而不需要重新登录，这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消耗。请看下面的统计数据：

提高 IT 效率：对于每 1000 个受管用户，每用户可节省$70K

帮助台呼叫减少至少1/3，对于 10K 员工的公司，每年可以节省每用户 $75，或者合计 $648K

生产力提高：每个新员工可节省 $1K，每个老员工可节省 $350 �资料来源：Giga

ROI 回报：7.5 到 13 个月 �资料来源：Gartner

另外，使用“单点登录”还是SOA时代的需求之一。在面向服务的架构中，服务和服务之间，程序和程序之间的通讯大量存在，服务之间的安全认证是SOA应用的难点之一，应此建立“单点登录”的系统体系能够大大简化SOA的安全问题，提高服务之间的合作效率。

2 单点登陆的技术实现机制

随着SSO技术的流行，SSO的产品也是满天飞扬。所有著名的软件厂商都提供了相应的解决方案。在这里我并不想介绍自己公司（Sun Microsystems）的产品，而是对SSO技术本身进行解析，并且提供自己开发这一类产品的方法和简单演示。有关我写这篇文章的目的，请参考我的博客（）。

单点登录的机制其实是比较简单的，用一个现实中的例子做比较。颐和园是北京著名的旅游景点，也是我常去的地方。在颐和园内部有许多独立的景点，例如“苏州街”、“佛香阁”和“德和园”，都可以在各个景点门口单独买票。很多游客需要游玩所有德景点，这种买票方式很不方便，需要在每个景点门口排队买票，钱包拿进拿出的，容易丢失，很不安全。于是绝大多数游客选择在大门口买一张通票（也叫套票），就可以玩遍所有的景点而不需要重新再买票。他们只需要在每个景点门口出示一下刚才买的套票就能够被允许进入每个独立的景点。

单点登录的机制也一样，如下图所示，当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录（1）；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket（2）；用户再访问别的应用的时候（3，5）就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性（4，6）。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。

从上面的视图可以看出，要实现SSO，需要以下主要的功能：

所有应用系统共享一个身份认证系统。

统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。

所有应用系统能够识别和提取ticket信息

要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

上面的功能只是一个非常简单的SSO架构，在现实情况下的SSO有着更加复杂的结构。有两点需要指出的是：

单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中，如下图所示。事实上，只要统一认证系统，统一ticket的产生和效验，无论用户信息存储在什么地方，都能实现单点登录。

统一的认证系统并不是说只有单个的认证服务器，如下图所示，整个系统可以存在两个以上的认证服务器，这些服务器甚至可以是不同的产品。认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。如下图，当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的ticket。当他访问应用系统4的时候，认证服务器2能够识别此ticket是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。

3 WEB-SSO的实现

随着互联网的高速发展，WEB应用几乎统治了绝大部分的软件应用系统，因此WEB-SSO是SSO应用当中最为流行。WEB-SSO有其自身的特点和优势，实现起来比较简单易用。很多商业软件和开源软件都有对WEB-SSO的实现。其中值得一提的是OpenSSO （），为用Java实现WEB-SSO提供架构指南和服务指南，为用户自己来实现WEB-SSO提供了理论的依据和实现的方法。

为什么说WEB-SSO比较容易实现呢？这是有WEB应用自身的特点决定的。

众所周知，Web协议（也就是HTTP）是一个无状态的协议。一个Web应用由很多个Web页面组成，每个页面都有唯一的URL来定义。用户在浏览器的地址栏输入页面的URL，浏览器就会向Web Server去发送请求。如下图，浏览器向Web服务器发送了两个请求，申请了两个页面。这两个页面的请求是分别使用了两个单独的HTTP连接。所谓无状态的协议也就是表现在这里，浏览器和Web服务器会在第一个请求完成以后关闭连接通道，在第二个请求的时候重新建立连接。Web服务器并不区分哪个请求来自哪个客户端，对所有的请求都一视同仁，都是单独的连接。这样的方式大大区别于传统的（Client/Server）C/S结构,在那样的应用中，客户端和服务器端会建立一个长时间的专用的连接通道。正是因为有了无状态的特性，每个连接资源能够很快被其他客户端所重用，一台Web服务器才能够同时服务于成千上万的客户端。

但是我们通常的应用是有状态的。先不用提不同应用之间的SSO，在同一个应用中也需要保存用户的登录身份信息。例如用户在访问页面1的时候进行了登录，但是刚才也提到，客户端的每个请求都是单独的连接，当客户再次访问页面2的时候，如何才能告诉Web服务器，客户刚才已经登录过了呢？浏览器和服务器之间有约定：通过使用cookie技术来维护应用的状态。Cookie是可以被Web服务器设置的字符串，并且可以保存在浏览器中。如下图所示，当浏览器访问了页面1时，web服务器设置了一个cookie，并将这个cookie和页面1一起返回给浏览器，浏览器接到cookie之后，就会保存起来，在它访问页面2的时候会把这个cookie也带上，Web服务器接到请求时也能读出cookie的值，根据cookie值的内容就可以判断和恢复一些用户的信息状态。

Web-SSO完全可以利用Cookie结束来完成用户登录信息的保存，将浏览器中的Cookie和上文中的Ticket结合起来，完成SSO的功能。

为了完成一个简单的SSO的功能，需要两个部分的合作：

统一的身份认证服务。

修改Web应用，使得每个应用都通过这个统一的认证服务来进行身份效验。

3.1 Web SSO 的样例

根据上面的原理，我用J2EE的技术（JSP和Servlet）完成了一个具有Web-SSO的简单样例。样例包含一个身份认证的服务器和两个简单的Web应用，使得这两个 Web应用通过统一的身份认证服务来完成Web-SSO的功能。此样例所有的源代码和二进制代码都可以从网站地址下载。

样例下载、安装部署和运行指南：

Web-SSO的样例是由三个标准Web应用组成，压缩成三个zip文件，从中下载。其中SSOAuth（）是身份认证服务；SSOWebDemo1（）和SSOWebDemo2（）是两个用来演示单点登录的Web应用。这三个Web应用之所以没有打成war包，是因为它们不能直接部署，根据读者的部署环境需要作出小小的修改。样例部署和运行的环境有一定的要求，需要符合Servlet2.3以上标准的J2EE容器才能运行（例如Tomcat5,Sun Application Server 8, Jboss 4等）。另外，身份认证服务需要JDK1.5的运行环境。之所以要用JDK1.5是因为笔者使用了一个线程安全的高性能的Java集合类“ConcurrentMap”，只有在JDK1.5中才有。

这三个Web应用完全可以单独部署，它们可以分别部署在不同的机器，不同的操作系统和不同的J2EE的产品上，它们完全是标准的和平台无关的应用。但是有一个限制，那两台部署应用（demo1、demo2）的机器的域名需要相同，这在后面的章节中会解释到cookie和domain的关系以及如何制作跨域的WEB-SSO

解压缩SSOAuth.zip文件，在/WEB-INF/下的web.xml中请修改“domainname”的属性以反映实际的应用部署情况，domainname需要设置为两个单点登录的应用（demo1和demo2）所属的域名。这个domainname和当前SSOAuth服务部署的机器的域名没有关系。我缺省设置的是“.sun.com”。如果你部署demo1和demo2的机器没有域名，请输入IP地址或主机名（如localhost），但是如果使用IP地址或主机名也就意味着demo1和demo2需要部署到一台机器上了。设置完后，根据你所选择的J2EE容器，可能需要将SSOAuth这个目录压缩打包成war文件。用“jar -cvf SSOAuth.war SSOAuth/”就可以完成这个功能。

解压缩SSOWebDemo1和SSOWebDemo2文件，分别在它们/WEB-INF/下找到web.xml文件，请修改其中的几个初始化参数

init-param

param-nameSSOServiceURL/param-name

param-value;/param-value

/init-param

init-param

param-nameSSOLoginPage/param-name

param-value;/param-value

/init-param

将其中的SSOServiceURL和SSOLoginPage修改成部署SSOAuth应用的机器名、端口号以及根路径（缺省是SSOAuth）以反映实际的部署情况。设置完后，根据你所选择的J2EE容器，可能需要将SSOWebDemo1和SSOWebDemo2这两个目录压缩打包成两个war文件。用“jar -cvf SSOWebDemo1.war SSOWebDemo1/”就可以完成这个功能。

请输入第一个web应用的测试URL（test.jsp）,例如 SSOWebDemo1/test.jsp，如果是第一次访问，便会自动跳转到登录界面，如下图

使用系统自带的三个帐号之一登录（例如，用户名：wangyu,密码：wangyu），便能成功的看到test.jsp的内容：显示当前用户名和欢迎信息。

请接着在同一个浏览器中输入第二个web应用的测试URL（test.jsp）,例如 SSOWebDemo2/test.jsp。你会发现，不需要再次登录就能看到test.jsp的内容，同样是显示当前用户名和欢迎信息，而且欢迎信息中明确的显示当前的应用名称（demo2）。

3.2 WEB-SSO代码讲解

3.2.1身份认证服务代码解析

Web-SSO的源代码可以从网站地址下载。身份认证服务是一个标准的web应用，包括一个名为SSOAuth的Servlet，一个login.jsp文件和一个failed.html。身份认证的所有服务几乎都由SSOAuth的Servlet来实现了；login.jsp用来显示登录的页面（如果发现用户还没有登录过）；failed.html是用来显示登录失败的信息（如果用户的用户名和密码与信息数据库中的不一样）。

SSOAuth的代码如下面的列表显示，结构非常简单，先看看这个Servlet的主体部分：

package DesktopSSO;

import java.io.*;

import java.net.*;

import java.text.*;

import java.util.*;

import java.util.concurrent.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class SSOAuth extends HttpServlet {

static private ConcurrentMap accounts;

static private ConcurrentMap SSOIDs;

String cookiename="WangYuDesktopSSOID";

String domainname;

public void init(ServletConfig config) throws ServletException {

super.init(config);

domainname= config.getInitParameter("domainname");

cookiename = config.getInitParameter("cookiename");

SSOIDs = new ConcurrentHashMap();

accounts=new ConcurrentHashMap();

accounts.put("wangyu", "wangyu");

accounts.put("paul", "paul");

accounts.put("carol", "carol");

}

protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

PrintWriter out = response.getWriter();

String action = request.getParameter("action");

String result="failed";

if (action==null) {

handlerFromLogin(request,response);

} else if (action.equals("authcookie")){

String myCookie = request.getParameter("cookiename");

if (myCookie != null) result = authCookie(myCookie);

out.print(result);

out.close();

} else if (action.equals("authuser")) {

result=authNameAndPasswd(request,response);

out.print(result);

out.close();

} else if (action.equals("logout")) {

String myCookie = request.getParameter("cookiename");

logout(myCookie);

out.close();

}

.....

}

从代码很容易看出，SSOAuth就是一个简单的Servlet。其中有两个静态成员变量：accounts和SSOIDs，这两个成员变量都使用了JDK1.5中线程安全的MAP类： ConcurrentMap，所以这个样例一定要JDK1.5才能运行。Accounts用来存放用户的用户名和密码，在init()的方法中可以看到我给系统添加了三个合法的用户。在实际应用中，accounts应该是去数据库中或LDAP中获得，为了简单起见，在本样例中我使用了ConcurrentMap在内存中用程序创建了三个用户。而SSOIDs保存了在用户成功的登录后所产生的cookie和用户名的对应关系。它的功能显而易见：当用户成功登录以后，再次访问别的系统，为了鉴别这个用户请求所带的cookie的有效性，需要到SSOIDs中检查这样的映射关系是否存在。

在主要的请求处理方法processRequest()中，可以很清楚的看到SSOAuth的所有功能

如果用户还没有登录过，是第一次登录本系统，会被跳转到login.jsp页面（在后面会解释如何跳转）。用户在提供了用户名和密码以后，就会用handlerFromLogin()这个方法来验证。

如果用户已经登录过本系统，再访问别的应用的时候，是不需要再次登录的。因为浏览器会将第一次登录时产生的cookie和请求一起发送。效验cookie的有效性是SSOAuth的主要功能之一。

SSOAuth还能直接效验非login.jsp页面过来的用户名和密码的效验请求。这个功能是用于非web应用的SSO，这在后面的桌面SSO中会用到。

SSOAuth还提供logout服务。

Q3: 怎么用java实现跨域cookie

通常情况下的话，可以用url的参数来实现。这需要两个站点有一套固定的规则。比如用户访问A站点之后，A站点向url添加一个参数。参数包括了cookie的内容或代表的id，然后重定向到B站点。B站点才能根据A站点传送的参数解析cookie并进行设置。

Q4: 单点注销地址和应用访问地址有区别吗

打开APP

aa46449521

关注

单点登录与单点注销原创

2018-02-05 15:22:59

aa46449521

码龄11年

关注

前言：

单点登录的原理，请参见：

单点登录

什么是单点登录？单点登录全称Single Sign On（以下简称SSO），是指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分。

下面开始单点登录的过程：认证系统根据用户在浏览器中输入的登录信息，进行身份认证，如果认证通过，返回给浏览器一个证明ticket(票)；用户再访问其它应用系统时，会带着ticket；应用系统接收到ticket后，会将其发送到认证系统进行合法性校验；校验通过后，用户就不需要再次输入用户名密码来登录了，从而实现了单点登录的功能。

要实现SSO，首先必须要有统一的认证系统，其次每个应用系统都通过认证系统来校验用户，所以这需要两方面的配合。WEB-SSO是比较好实现的，尤其是共同父域的情况下，我们可以通过浏览器的cookie来保存ticket。今天我用Servlet技术实现了SSO的主要功能，可以在下载项目。

下载源码地址：点击打开链接

域名准备

修改hosts文件，我的hosts在C:\Windows\System32\drivers\etc路径下映射3个域名：

127.0.0.1 testsso.yao.com

127.0.0.1 testsso2.yao.com

127.0.0.1 passport.yao.com

3个域名必须拥有共同父域(.yao.com)，testsso和testsso2用于访问应用系统，passport用于访问认证系统。

项目部署

项目中包含的是两个Eclipse Project，导入到Eclipse/MyEclipse后，可能需要设置下JavaEE类库。SSOAuth为认证系统，SSODemo为应用系统，如果映射的域名和我设置的一样，不需要设置，直接部署即可。如果不一样，需要修改下两个项目的web.xml文件。关键配置信息如下：

SSOAuth/WEB-INF/web.xml：

servlet

servlet-nameSSOAuth/servlet-name

servlet-classcom.yao.servlet.SSOAuth/servlet-class

init-param

param-namecookieName/param-name

param-valueSSOID/param-value

/init-param

init-param

param-namedomainName/param-name

param-value.yao.com/param-value

/init-param

init-param

param-namesecure/param-name

param-valuefalse/param-value

/init-param

init-param

param-namesecretKey/param-name

param-value111111112222222233333333/param-value

/init-param

init-param

param-nameticketTimeout/param-name

param-value10080/param-value

/init-param

/servlet

servlet-mapping

servlet-nameSSOAuth/servlet-name

url-pattern/SSOAuth/url-pattern

/servlet-mapping

SSODemo/WEB-INF/web.xml：

?xml version="1.0" encoding="UTF-8"?

web-app xmlns:xsi="" xmlns="" xmlns:web="" xsi:schemaLocation=" " id="WebApp_ID" version="2.5"

display-nameSSODemo/display-name

filter

filter-nameSSOAuth/filter-name

filter-classcom.yao.filter.SSOAuth/filter-class

init-param

param-nameSSOService/param-name

param-value;/param-value

/init-param

init-param

param-nameSSOLogin/param-name

param-value;/param-value

/init-param

init-param

param-namecookieName/param-name

param-valueSSOID/param-value

/init-param

/filter

filter-mapping

filter-nameSSOAuth/filter-name

url-pattern*.jsp/url-pattern

/filter-mapping

filter-mapping

filter-nameSSOAuth/filter-name

url-pattern/logout/url-pattern

/filter-mapping

/web-app

如果域名或端口号和我的不一致，可以修改对应配置项。最后部署到应用服务器中，启动服务器。

SSO使用

首先输入第一个应用系统的访问地址，，如果是第一次访问的话，会自动跳

转到登录页：

系统中内置了3个用户，张三、李四、王五，用户名和密码皆为拼音全拼，输入zhangsan/zhangsan登录后，会自动跳转到我们刚才访问的页面，页面中显示了登录的用户名及欢迎信息，如下图：

这时，我们再输入第二个应用系统的访问地址，，我们发现，没有进行第二次登录，同样页面中显示了登录的用户名及欢迎信息，如下图：

我们接着点击Logout注销用户，页面跳转到了登录页面，这时我们再回头访问第一个应用系统的页面，发现同样跳转到了登录页面。这给用户的使用效果就是，一个应用登录了，其它的应用都会自动登录，而一个应用中注销了，其它的应用也都会自动注销。

项目中提供了源码，代码的实现思路就是上面的那个图，ticket保存在cookie中，利用cookie域的特性，实现了ticket在不同应用中都能够获取到，ticket的验证过程是使用了HttpClient来发送的验证请求，ticket的加密使用了3DES，具体可以看DESUtils.java

下载源码地址：点击打开链接

打开CSDN，阅读体验更佳

单点登录、注销实现原理（SSO）

SSO实现原理简介一、SSO登录原理：设计案例二、SSO注销原理：1.设计案列总结简介单点登录是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统的保护资源，若用户在某个应用系统中进行注销登录，所有的应用系统都不能再直接访问保护资源，像一些知名的大型网站，如：淘宝与天猫、新浪微博与新浪博客等都用到了这个技术。提示：以下是本篇文章正文内容，下面案例可供参考一、SSO登录原理：有一个独立的认证中心，只有认证中心才能接受用户的用户名和密码等信息进行认证，其他系统不提供登录入口，只

继续访问

最新发布单点登录与注销系统原理与实现

一、单系统登录机制 1、http无状态协议 web应用采用browser/server架构，http作为通信协议。http是无状态协议，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联，这个过程用下图说明，三次请求/响应对之间没有任何联系。但这也同时意味着，任何用户都能通过浏览器访问服务器资源，如果想保护服务器的某些资源，必须限制浏览器请求；要限制浏览器请求，必须鉴别浏览器请求，响应合法请求，忽略非法请求；要鉴别浏览器请求，必须清楚浏览器请求状态。既然http协议无状态，那就让服务器

继续访问

SSO单点登录详解------三、单点注销流程解析

一、前言单点登录自然也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁，用下面的图来说明: 单点注销流程步骤分析: 1. 用户在CRM系统中点击注销按钮.会重定向到统一认证中心的注销方法 2. 统一认证中心接受到注销请求之后,会销毁全局的会话. 3. 统一认证中心会拿到之前在该系统中注册的子系统集合. 4. 依次的调用子系统的登出方法,销毁局部会话. 5. 每个系统中的会话都已经销毁之后,跳转到登陆页面. 二、系统中的Cookie和Session存储图解以下图解是基于单点登录图

继续访问

PHP 完全跨站点跨域名单点(SSO)同步登录和注销

先来说说什么是单点登录(SSO)。来自百科的介绍：SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。首先想到的单点登录，应该就是，在某个服务器或者站点进行登录，登录之后携带登录ticket，跳转到原来登录的站点。原来登录的站点通过远程验证ticket是否合法。这个方法很容易，只要所有连接都带上.

继续访问

SSO单点登陆，单点注销设计思想

5、设计思路及折衷在常见的web站点中，当存在多个站点需要登陆，而这些站点都是使用同一套的登陆流程，当用户在其中一个站点登陆后，其他站点并未记录用户的登陆信息，导致用户每次登陆新站点需要进行新的登陆过程，这样给用户的体验是十分的不友好的，这时候就可以使用单点登陆，单点注销的方式实现用户的登陆流程。由于站点是使用session存储用户信息的，所以该设...

继续访问

单点登录教程(三)单点注销流程分析

作者：蓝雄威，叩丁狼教育高级讲师。原创文章，转载请注明出处。一、前言单点登录自然也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁，用下面的图来说明:步骤分析:1.用户在CRM系统中点击注销按钮.会重定向到统一认证中心的注销方法2.统一认证中心接受到注销请求之后,会销毁全局的会话.3.统一认证中心会拿到之前在该系统中注册的子系统集合.4.依次的调用子系统的登出方法,销毁局部会话.5.每个...

继续访问

单点登录原理与简单实现

(2017-09-22更新)GitHub：一、单系统登录机制 1、http无状态协议 web应用采用browser/server架构，http作为通信协议。http是无状态协议，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联，这个过程用下图说明，三次请求/响应对之间没有任何联系但这...

继续访问

单点登录的三种实现方式

单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞

继续访问

单点登录和单点注销

1.在分布式系统架构下是每一个系统都是由一个团队进行维护，每个系统都是单独部署运行一个单独的应用容器如Tomcat，所以，不能将用户的登录信息保存到session中。多个tomcat的session一般是不能共享的，虽然我们可以利用tomcat自身的session同步功能，但随着机器和业务量增加，效率会越来越低。而且这样做会使业务和Tomcat严重耦合，不利于扩展，所以我们需要一个单独的系统...

继续访问

SSO单点登录教程(五)自己动手写SSO单点注销服务端和客户端

作者：蓝雄威，叩丁狼教育高级讲师。原创文章，转载请注明出处。一、前言单点登录自然也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁，用下面的图来说明。单点注销难点在于在其中一个系统注销之后,需要把其他的子系统的会话销毁.所以肯定需要子系统在令牌校验通过之后,统一认证中心要把该子系统的地址和会话记录起来.才能在注销的时候找到这些子系统通,依次调用子系统通的注销方法,销毁局部会话.二、单点注...

继续访问

热门推荐 CAS单点登录-单点登出/退出/注销（十二）

CAS单点登录-单点登出/退出/注销（十二）据说cas3.x开始支持单点注销，但我们目前讲的是5.1.x，当然我们加入了单点登录，一般来说都需要单点注销的，让个子系统支持单点注销需要做一些工作本章目标 logoutTyle类型讲解 cas退出流程分析 cas client单点退出配置 buji（shiro、pac4j）单点退出配置重点目标： A系统需要访问cas输入

继续访问

自己动手写SSO单点注销服务端和客户端

本文为转载，发表在：一、前言单点登录自然也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁，用下面的图来说明。单点注销难点在于在其中一个系统注销之后,需要把其他的子系统的会话销毁.所以肯定需要子系统在令牌校验通过之后,统一认证中心要把该子系统的地址和会话记录起来.才能在注销的时候找到这些子系统通,依次调用子系统通的注销方法,销毁局部会话. 二、单点注销流程图三、代码实现客户端(注意:两个客户...

继续访问

单点登录与单点登出

一、标准流程描述 CAS官网的标准流程： SSO标准流程流程描述： First Access：第3步数据走向第4步数据走向第一次访问app.example.com（service地址），请求参数中session为空，app service没做过权限认证，所以重定向到CAS认证服务（cas.example.com/cas/login），经过URL编码的service地址作为参数一同...

继续访问

SSO单点登录三种情况的实现方式详解

单点登录（SSO——Single Sign On）对于我们来说已经不陌生了。对于大型系统来说使用单点登录可以减少用户很多的麻烦。就拿百度来说吧，百度下面有很多的子系统——百度经验、百度知道、百度文库等等，如果我们使用这些系统的时候，每一个系统都需要我们输入用户名和密码登录一次的话，我相信用户体验肯定会直线下降。当然，对于个人博客这类系统来说根本就用不上单点登录了。假如，我们的系统很庞大，但是就

继续访问

单点登录、单点注销，唯一登录，角色权限系统流程

1.单点登录 2.单点注销 3.唯一登录 4.角色权限

继续访问

谁都能看懂的单点登录（SSO）实现方式（附源码）

SSO的基本概念 SSO英文全称Single Sign On（单点登录）。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。（本段内容来自百度百科）今天这篇文章将介绍SSO的一种实现方式，代码超简单，仅用来验证我的思路是否可行，具体细节请大家来完善！...

继续访问

sso servert端注销

sso server端注销功能 ,完全跨域的SSO，采用java编写

单点登录单点注销 sso

写评论

Q5: java session 跨域丢失

首先，跨域操作是所有安全范畴内都被严格禁止的。

Session共享，包含同根域与不同根域的两个情况，如

1. abc.ccc.com和

2. abc.ccc.com和

第一种情况，处理办法相对简单，第二种就要复杂一些。

如果你想实现Session共享，可以学习一下有关SSO的相关知识。SSO不是一段代码，而是一个应用系统，它是基于企业级的应用，所以要学习SSO，需要下一番深功夫。