基于Cookie和信任链的跨域单点登录方案
基于Ｃｏｏｋ ｉ ｅ和信任链的跨域单点登录方案 雷根平，张晓东 （河南机电学校，河南郑州４５１１９１）
摘要：由于ＨＴＴＰ协议存在无状态性，很多网站采用Ｃｏｏｋｉｅ来认证用户，但Ｃｏｏｋｉｅ不能够跨域传递。在对基于Ｃｏｏｋｉｅ的认证方 式和单点登录的实现机制做了深入分析和研究的基础上，结合信任链观点，提出了一种基于Ｃｏｏｋｉｅ的跨域认证方法。 关键词： Ｃｏｏｋｉｅ；单点登录；信任链；跨域
Ａ Ｄｅｓｉｇｎ ｆｏｒ Ｃｒｏｓｓ Ｄｏｍａｉｎ ＳｉｎｇＩｅ—Ｓｉｇｎ—ｏｎ Ｓｙｓｔｅｍ ｏｎ Ｃｏｏｋｉｅ ａｎｄ Ｔｒｕｓｔ Ｃｈａｉｎ ＬＥＩ Ｇｅｎ－ｐｉｎｇ，ＺＨＡＮＧ Ｘｉａｏ－－ｄｏｎｇ ＃＠ｎａｎ Ｅｌｅｃｔｒ／ｂａｌ ａｎｄ Ｍｅｃｈａｎ／ｃａｌ Ｓｃｈｏｏｌ，Ｚｋｅｎｇｚｈｏｕ．Ｈｅｎａｎ ４５１１９１．∞ｍａ Ａｂｓｔｒａｃｔ：Ｂｅｃａｕｓｅ ＨＴＴｐ ｎｅｇｏｔｉａｔｅｓ ｅｘｉｓｔｅｎｃｅ ｈａｖｅ ｎｏ ｓｔａｔｕｓ，ａ ｌｏｔ ｏｆ Ｗｅｂｓｉｔｅ ａｄｏｐｔｉｏｎ ｔｈｅ Ｃｏｏｋｉｅ ｃｏｍｅ ｔｏ ａｔｔｅｓｔａｔｉｏｎ ｃｏｎｓｕｍｅｒ，ｂｕｔ ｔｈｅ Ｃｏｏｋｉｅ ｉｎｃａｐａｂｉｌｉｔｙ ｅｎｏｕｇｈ＆ｃｒｏｓｓｅｓ ａｎ ａｒｅａ ｔＯ ｄｅｌｉｖｅｒ．Ｔｒｕｓｔ ｃｈａｉｎ ｓｔａｎｄｐｏｉｎｔ ｔｏｗａｒｄｓ ｃａｒｒｙｉｎｇ ｏｕｔ ａ ｍａｃｈｉｎｉｎｇ ｔＯ ｍａｋｅ ｔｈｏｒｏｕｇｈ ａｎａｌｙｓｉｓ ａｎｄ ｓｅａｒｃｈ ｆｏｕｎｄａｔｉｏｎ ａｃｃｏｒｄｉｎｇ ｔｏ ｔｈｅ Ｃｏｏｋｉｅ ａｔｔｅｓｔａｔｉｏｎ ｍｅｔｈｏｄ ａｎｄ ｕｎｉｐｏｌｅ ｄｏｔ ｅｎｔｒｙ ａｓｃｅｎｄｉｎｇ，ｃｏｍｂｉｎｉｎｇ，ｐｒｏｐｏｓｅ ａ ｋｉｎｄ ｏｆ ａｃｃｏｒｄｉｎｇ ｔｏ ｔｈｅ ａｃｒｏｓｓｉｎｇ ｏｆ Ｃｏｏｋｉｅ ａｒｅａ ａｔｔｅｓｔａｔｉｏｎ ｍｅｔｈｏｄ． Ｋｅｙ ｗｏｒｄｓ： Ｃｏｏｋｉｅ：ＳＳＯ：ｔｒｕｓｔ ｃｈａｉｎ：ＣＲＯＳＳ ｄｏｍａｉｎ
１引言 当前绝大多数的计算都采取分布式进行，一个 系统设计首要考虑的问题就是如何安全、方便地对 用户进行鉴别、控制其访问权限。单点登录（ＳＳＯ） 提供一种机制让不同的应用系统迅速得统一的认证 功能，实现全局、安全的软件环境。在实现ＳＳＯ 的系统中，用户只需进行一次主动的登录操作即可 获得所需访问的应用系统和资源的授权，不必多 次输入用广｜名和密码来确定用户身份即：“一次登 录，多方认证”“ 。目前实现的产品和解决方案众 多，然而这些方案和产品有着各自的弱点，且大都 比较复杂且缺乏灵活性，在项目实践中很难快速实 施。在总结这些方案的基础上，本文提出一种简单 的跨域单点登录解决方案，该方案基于信任链信任 关系建立认证信任链，以实现跨域范围的ＳＳＯ。
２相关技术的介绍 ２．１ Ｃｏｏｋｉｅ的定义和功能 Ｃｏｏｋｉｅ是在用户在浏览网页页面时，服务器发 送给浏览器的体积很小的纯文本信息，保存在客户 机的内存中（此种Ｃｏｏｋｉｅ称作ｓｅｓｓｉｏｎ Ｃｏｏｋｉｅ）或 作为文件保存在客户机的硬盘（此种Ｃ ｏｏｋｉｅ称作
６７ 固口呵圈２ ０ １ １ ０ ５ ｗｗ ，．＇ ｒ Ｉ ｒｎ一 １
ｐｅｒｓｉｓｔｅｎｔ Ｃｏｏｋｉｅ）。以后在用户访问同一服务器 时，浏览器将把它们原样发送给服务器，通过让服 务器读取它原先保存的客户端信息，网站能够为浏 览者提供一系列的方便，如在线交易过程中标识用 户身份和在安全要求不高的场合避免用户重复输入 名字和密码、门户网站的主页定制有针对性地投放 广告等等。目前，Ｃｏｏｋｉｅ已广泛应用于Ｗｅｂ服务， 例如Ｌｉｂｅｒｔｙ的单点登录服务就是借助于完Ｃｏｏｋｉｅ 完成的。 ２．２ Ｃｏｏｋｉｅ的组成 Ｃｏｏｋｉｅ由变量名、值组成，其属性里有标准的 变量和用户自己创建的变量。属性中变量是用“变 量＝值”的形来保存，基本格式如下： ＮＡＭＥ＝ＶＡＬＵＥ： Ｅｘｐｉｒｅｓ：Ｄａｔｅ； Ｐａｔｈ：ＰＡＴＨ； Ｄｏｍａｉｎ－－ＤＯＭＡＩＮ—ＮＡＭＥ： Ｓｅｃｕｒｅ； 其中各项以“；”分开，首先是指定Ｃｏｏｋｉｅ的 名称，并为其赋值，接下来分别是Ｃ００ｋｉｅ的有效 期、ＵＲＬ路径以及域名。在这几项除了第一项以外， 其他部分均为可选项。 １）ＮＡＭＥ＝ＶＡＬＵＥ是每一个Ｃｏｏｋｉｅ均必须有 的部分。ＮＡＭＥ是Ｃｏｏｋｉｅ的名称。ＶＡＬＵＥ是该 ＮＡＭＥ的值。在字符串ＮＡＭＥ－－ＶＡＬＵＥ中，不含 分号、逗号和空格等字符，否则是不合法的。 ２）Ｅｘｐｉｒｅｓ＝Ｄａｔｅ中，Ｅｘｐｉｒｅｓ变量是一个只写 变量，它确定ＣＯＯｋｉｅ的有效终止日期，它必须以 特定的格式来书写星期几，“ＤＤ—ＭＭ—ＹＹＨＨ” 表示这是格林尼治时间。反之，不以这样的格式来 书写，系统将无法识别。该变量可省去。如果缺 省时，则Ｃｏｏｋｉｅ属性值不会保存在用户的硬盘中， 而仅仅保存在内存当中。Ｃ ００ｋｉｅ文件将随着浏览 器的关闭而自动消失。 ３）Ｄｏｍａｉｎ：ＤＯＭＡＩＮ—ＮＡＭＥ，Ｄｏｍａｉｎ是 Ｃｏｏｋｉｅ在其内有效的主机或域名。Ｄｏｍａｉｎ确定了 哪些Ｉｎｔｅｒｎｅｔ域中的Ｗｅｂ服务器可读取浏览器所 存取的Ｃ００ｋｉｅ，即只有来自这个域的页面才可以 使用Ｃ ００ｋｉｅ中的信息。这项设置是可选的，如果 缺省时，设置的属性值为该Ｗｅｂ服务器的域名。 ４）Ｐａｔｈ＝ＰＡＴＨ定义了服务器上哪些路径下的 页面可获取Ｗｅｂ服务器设置的Ｃｏｏｋｉｅ。一般如果 用户输入的ＵＲＬ中的路径部分从第一个字符开始 包含Ｐａｔｈ属性所定义的字符串，浏览器就认为通 过检查。如果Ｐａｔｈ属性的值为／，则Ｗｅｂ服务器 上所有的ＷＷＷ资源均可读取该Ｃｏｏｋｉｅ，同样该 项设置是可选的。如果缺省时，则Ｐａｔｈ的属性值 为服务器传给浏览器的资源的路径名。由此，我们 可以看出，借助对Ｄｏｍａｉｎ和Ｐａｔｈ两个变量的设置， 即可有效地控制文件被访问的范围。 （５）Ｓｅｃｕｒｅ在Ｃｏｏｋｉｅ中标记该变量，表明只有 当浏览器和Ｗ ｅｂ服务器之间的通信协议为加密认 证协议时，浏览器才向该Ｗｅｂ服务器提交相应的 Ｃｏｏｋｉｅ，当前这种协议只有一种，即为ＨＴＴＰ。 ２．３ Ｃｏｏｋｉｅ的使用 有两种方式使用Ｃ０ｏｋｉｅ ：一是当用户用浏览 器首次访问某Ｗｅｂ站点（Ｗｅｂ服务器）时，服务 器端先用Ｓｅｔ－Ｃｏｏｋｉｅ ｈｅａｄｅｒ来创建一个Ｃｏｏｋｉｅ， 再用Ｒｅｓｐｏｎｓｅ命令将Ｃｏｏｋｉｅ写入访问者的计算机 ，此过程称为创建Ｃｏｏｋｉｅ；二是当用户用浏览器再 次访问此Ｗｅｂ站点时，用Ｒｅｑｕｅｓｔ命令从访问者 的计算机中以忽略路径的方式取回Ｃ ００ｋｉｅ，此过 程称为读取Ｃｏｏｋｉｅ。 创建Ｃｏｏｋｉｅ的基本语法是： Ｒ ｅ ｓ Ｐ ０ ｎ ｓ ｅ． Ｃ ０ ０ ｋ ｉ ｅ ｓ（Ｃ ０ ０ ｋ ｉ ｅ）． ａｔｔｒｉｂｕｔｅ＝ｖａｌｕｅ； 读取Ｃｏｏｋｉｅ的基本语法是： Ｒｅｑｕｅｓｔ．Ｃｏｏｋｉｅｓ（Ｃｏｏｋｉｅ）．ａｔｔｒｉｂｕｔｅ； 其中，Ｃ ００ｋｉｅ是指定Ｃ ００ｋｉｅ的名称， ａｔｔｒｉｂｕｔｅ指定Ｃ００ｋｉｅ自身的有关属性信息，如 Ｄｏｍａｉｎ、Ｐａｔｈ等。
３基于Ｃｏｏｋｉｅ的Ｗｅｂ ＳＳＯ 在对基于Ｃｏｏｋｉｅ的Ｗｅｂ ＳＳＯ进行简单的描述 之前，我们要先介绍一下什么是单点登录的域，也 简称为单点登录域 。单点登录域指只有一个认证 信任机构的服务实体群域。所有属于该域的服务实 体都信任这个机构所认证过的用户。某一用户在经 过认证流程成功登录单点登录域中的任意一台Ｗｅｂ 服务实体以后，继续访问同一服务实体不需要再次 经过认证流程，并且访问同一域的其他Ｗｅｂ服务 实体，也不需要经过认证流程。登录的过程中使 用登录Ｃｏｏｋｉｅ、授权Ｃｏｏｋｉｅ和会话Ｃｏｏｋｉｅ三种 类型的Ｃｏｏｋｉｅ完成整个过程。登录Ｃ００ｋｉｅ由认 证信任机构在用户登录成功时产生，用于保持用 户在整个域中的认证状态。随着登录Ｃ ０ｏｋｉｅ的产 生，授权Ｃ００ｋｉｅ也同时产生，并交付Ｗｅｂ服务 实体使用，告知Ｗｅｂ服务实体该用户已经被认证。 会话Ｃ ｏｏｋｉｅ在Ｗｅｂ服务实体接收到授权Ｃ ｏｏｋｉｅ 时即时产生，用于保持用户在该Ｗｅｂ服务实体上 的认证状态，即当用户拥有认证信任机构的登录 Ｃｏｏｋｉｅ，便可以产生相应网站的授权Ｃｏｏｋｉｅ。而 Ｗｅｂ服务实体拿到对应自己的授权Ｃｏｏｋｉｅ，将发 布会话Ｃｏｏｋｉｅ，用户即可以ＳＳＯ方式进行访问了。
４基于Ｃｏｏｋ ｉ ｅ和信任链的跨域单点登录 认证方案 跨域认证的目的是允许用户访问跨多个域的多 个服务器的资源，而不必重新认证。应用Ｃ００ｋｉｅ 来实现跨域ＳＳＯ应该是最简单和最常用的方
２ ０ １ １．０ ５￣／６８ ｒｌｓＣ ｏｒｏ ｃｒｌ】 式。但是如果在多个不同域名的系统问实现ＳＳＯ， Ｃｏｏｋｉｅ存在不能跨域共享的问题。因为Ｃｏｏｋｉｅ是 特定于产生它的某个域，例如，如果一个应用位于 ｆｏｏ．ＣＯＩｌｌ中。另一个应用位于ｂａｒ．ｃｏｒｎ中，则 Ｃｏｏｋｉｅ不能用于将数据从ｆｏｏ传输到ｂａｒ中。因此， 利用Ｃ ＯＯｋｉｅ来实现跨多个域的单点登录功能不是 一件简单的事情。为了解决这个问题，我们可以在 两个不同的单点登录域之间建立一种信任关系，利 用这种信任关系来实现跨域登录的问题。 在了解了基于Ｃｏｏｋｉｅ的Ｗｅｂ ＳＳＯ的方法的基 础上，我们可以提出基于Ｃ Ｏｏｋｉｅ和信任链的跨域 单点登录认证方案，那么在存在多个登录域时，当 Ａ域某一用户已经通过认证流程登录到Ａ域，Ｂ域 的服务实体是否为此Ａ域的用户提供服务？定义： 如果Ｂ域的服务实体提供服务，则称Ｂ域信任Ａ域， 形成了Ｂ域到Ａ域的信任链，如果Ｂ域的服务实 体拒绝提供服务，则称Ｂ域不信任Ａ域，没有形 成信任链。 登录过程简单描述如下：Ａ域的用户Ａｎｄｙ访 问Ｂ域的服务实体ＳｅｒｖｉｃｅＢ，ＳｅｒｖｉｃｅＢ将登录请求 重定向到认证服务器Ｂ请求认证，认证服务器Ｂ 通过位置服务判断出此用户属于域Ａ，再将此请求 重定向到认证服务器Ａ，比如Ａｎｄｙ已经登录过Ａ 域，那么Ａｎｄｙ拥有票据Ａ域的Ｃ００ｋｉｅ—Ｌｏｇｉｎ； 如果Ａｎｄｙ还没有登录， Ａｎｄｙ将经过认证流程 完成登录，并拥有Ａ域的Ｃｏｏｋｉｅ－Ｌｏｇｉｎ。一旦 Ａｎｄｙ拥有Ａ域的Ｃｏｏｋｉｅ－Ｌｏｇｉｎ，认证服务器将 为Ａｎｄｙ登录Ｂ域产生Ｃｏｏｋｉｅ—Ｉｎｔｅｒ—ｌｏｇｉｎ，随后 重定向到认证服务器Ｂ当认证服务器Ｂ接收并验证 了Ｃｏｏｋｉｅ—Ｉｎｔｅｒ—ｌｏｇｉｎ的合法性后，即代表Ａｎｄｙ 可以正常访问Ｂ域的服务实体了。如图１所示。 Ａ域 Ｂ域 图１域间用户的认证流程 ６９固口Ⅱ圈２ ０ １ １．０ ５ ＷＷＷ ｎＳＣ ０ Ｃｎ ５方案的评价 评价ＳＳＯ系统主要考虑其可实施性、可管理 性、安全性和易用性。为解决跨域单点登录，基于 Ｃ００ｋｉｅ的技术和创建信任链技术共同为核心的单 点登录方案是一种轻量级的解决方案。单点登录的 客户端可以部署在各个需要加入ＳＳＯ认证的网络 应用中，通过修改配置文件来指定受保护资源，并 可将访问资源设置为完全控制或简单控制。这种机 制灵活、简单、可实施性强。集中式的认证方便了 对用户以及登录的控制，有较强的可管理性，并 且Ｃｏｏｋｉｅ技术在一定的程度上能够防止重放攻击， 消息篡改以及窃听、中间人攻击的威胁。
统一用户认证和单点登录解决方案
统一(tǒngyī)用户认证和单点登录解决方案随着信息技术和网络技术的迅猛发展，企业内部的应用系统越来越多。
比如在媒体行业，常见的应用系统就有采编系统、排版系统、印刷系统、广告管理系统、财务系统、办公自动化系统、决策支持系统、客户关系管理系统和网站发布系统等。
由于这些系统互相独立，用户在使用每个应用系统之前都必须按照相应的系统身份进行登录，为此用户必须记住每一个系统的用户名和密码，这给用户带来了不少麻烦。
特别是随着系统的增多，出错的可能性就会增加，受到非法截获和破坏(pòhuài)的可能性也会增大，安全性就会相应降低。
针对于这种情况，统一用户认证、单点登录等概念应运而生，同时不断地被应用到企业应用系统中。
统一用户管理的基本原理。
一般来说，每个应用系统都拥有独立的用户信息管理功能，用户信息的格式、命名与存储方式也多种多样。
当用户需要使用(shǐyòng)多个应用系统时就会带来用户信息同步问题。
用户信息同步会增加系统的复杂性，增加管理的成本。
多大例如，用户X需要同时使用A系统与B系统，就必须在A系统与B系统中都创建(chuàngjiàn)用户X，这样在A、B任一系统中用户X的信息更改后就必须同步至另一系统。
如果用户X需要同时使用10个应用系统，用户信息在任何(rènhé)一个系统中做出更改后就必须同步至其他9个系统。
用户同步时如果系统出现意外，还要保证数据的完整性，因而同步用户的程序可能会非常复杂。
解决用户同步问题的根本办法是建立统一用户管理系统（UUMS）。
UUMS统一存储所有应用系统的用户信息，应用系统对用户的相关操作全部通过UUMS 完成，而授权等操作则由各应用系统完成，即统一存储、分布授权。
UUMS应具备以下基本功能:1．用户信息规范命名、统一存储，用户ID全局惟一。
用户ID犹如身份证，区分和标识了不同的个体。
2．UUMS向各应用系统提供用户属性列表，如姓名、电话、地址、邮件等属性，各应用系统可以选择本系统所需要的部分或全部属性。
单点登录方案
单点登录方案随着互联网的快速发展，人们在日常生活中使用的各种应用、网站和服务也越来越多。
然而，当我们要使用多个不同的应用或网站时，每次都需要进行繁琐的登录操作，为我们带来了极大的不便。
因此，单点登录方案应运而生，旨在解决这一问题，提供更便捷的用户体验。
一、什么是单点登录？在介绍单点登录方案之前，我们先来了解一下单点登录的概念。
单点登录（Single Sign-On，简称SSO）是一种身份验证服务，允许用户使用一个凭据（比如用户名和密码）登录多个应用或网站，而不需要重复输入凭据。
这意味着用户只需一次登录，就可以访问所有与该单点登录系统集成的应用和服务。
二、单点登录方案的好处1. 提供便捷的用户体验：用户只需一次登录就可以访问多个应用和网站，无需频繁输入账号密码，大大提高了使用效率和便利性。
2. 减少账号密码管理的负担：由于只需记住一个账号密码，用户可以轻松减少对各个应用和网站账号密码的管理工作，降低了安全风险。
3. 提高安全性：通过单点登录方案，可以集中管理用户身份认证和授权，确保用户信息的安全性，减少密码泄露和账号被盗的风险。
4. 降低开发和维护成本：对于应用和网站开发者来说，实现单点登录可以减少重复开发工作和维护成本，同时提升了用户粘性和使用体验。
三、常见的在实际应用中，我们可以选择多种单点登录方案来满足不同的需求。
以下是几种常见的单点登录方案：1. 基于Cookie的单点登录方案：这是一种简单且常见的单点登录方案。
用户在登录成功后，服务器会生成一个包含认证信息的Cookie，并在用户访问其他应用或网站时自动传递该Cookie，实现单点登录的功能。
2. 基于Token的单点登录方案：该方案通过生成和管理访问令牌（Token）来实现单点登录。
用户在登录成功后，服务器会为用户生成一个Token，并将其返回给用户。
用户在访问其他应用或网站时，只需携带该Token进行身份验证，而无需再次输入凭据。
3. 基于OAuth的单点登录方案：OAuth是一种开放标准，可以让用户授权第三方应用访问他们在其他服务提供商上的数据，从而实现单点登录的功能。
单点登陆方案
单点登录方案概述随着互联网的快速发展和多样化的应用系统，用户常常面临着需要在不同的应用系统中进行登录的困扰。
为了解决这一问题，单点登录（Single Sign-On，简称SSO）技术应运而生。
单点登录方案是一种通过一次认证，用户可以访问多个应用系统的技术方案。
本文将介绍单点登录的原理、应用场景和实施方案。
一、单点登录原理单点登录的基本原理是在一个安全的身份认证中心（Identity Provider，简称IdP）完成用户的身份认证，并生成一个授权票据（Token），然后将该授权票据保存在用户的浏览器中的Cookie中。
当用户要访问其他应用系统时，这些应用系统会将用户重定向到IdP，并将授权票据发送给IdP进行验证。
验证通过后，IdP会生成一个新的授权票据并返回给应用系统，应用系统根据授权票据判断用户的合法性，从而实现用户的单点登录。
二、单点登录的应用场景1. 企业内部应用系统：在企业内部，往往存在多个不同的应用系统，如人力资源管理系统、财务管理系统、项目管理系统等。
使用单点登录方案可以避免用户需要在每个系统中单独登录的繁琐操作，提高了工作效率和用户体验。
2. 跨域网站应用：在互联网上，常常会有多个跨域网站应用需要进行集成，如在线购物网站、社交媒体平台等。
用户只需登录一次，就可以在所有的应用系统中自由切换，避免了重复输入账号和密码的困扰。
3. 第三方授权登录：许多网站提供使用第三方账号登录的功能，如使用微信账号登录某个网站。
通过单点登录方案，可以实现将第三方授权的账号映射到本地账号，方便用户进行登录。
三、单点登录实施方案1. 基于SAML的单点登录Security Assertion Markup Language （SAML）是一种基于XML的认证标准，是单点登录方案中最常用的协议之一。
基于SAML的单点登录方案主要包括以下步骤：（1）用户访问应用系统A，应用系统A 发现用户未登录，将用户重定向到IdP。
简单的单点登陆解决方案
简单的单点登陆解决方案1.概述单点登录是指用户在其中一个系统登录之后，用户再漫游至其他相关系统时，不需要重复的登录。
真正使用户感觉到“一点登录、全网通行”。
目前比较流行的COOKIE认证的方式。
其实现示意图如下：2.原理说明统一验证由用户首次登陆Web页面时向用户浏览器写一个包含用户账号,用户Token的Cookie信息。
并且由应用服务器取得这个信息以后提交到验证服务器数据库中进行注册判断。
如果用户信息注册成功，则在应用服务器上面以Session形式记录下此用户己经正确登陆的信息，以后用户再次登录些应用服务器的时候只要对此Session 信息进行判断，如果Session信息存在并且是表示用户正确登陆，则用户通过验证，不需要第二次输入用户名和密码。
若Session信息消失，则应用服务器提取用户浏览器中的Cookie信息再次到验证服务器上进行验证，通过验证以后再次在应用服务器端用Session信息将用户信息保存。
如果用户在应用服务器端跳转的话，每跳转到一个新的应用服务器，则应用服务器必须取得用户浏览器端的Cookie信息到验证服务器上进行一次验证，验证通过以后则同样注，Session信息在应用服务器上，以完成对用户验证的通过。
单点认证由用户首次登陆Web页面时向用户浏览器写内存Cookie，目前暂定为(userToken、loginId)，同时，为了保证Cookie访问的安全性，需要把Cookie 的domain设成统一的domain，只有在访问同一domain的网站才能获取该Cookie。
注：Cookie信息可以根据应用的需要，增加一些公共的字段值，以显示给用户。
3.验证流程3.1.统一登录流程验证流程如下：（1）当用户首次通过Web登陆时，由Web端计算token值（参见第三方接口实现），并写入以上Cookie信息到浏览器中及以Session形式记录下此用户己经正确登陆的信息（2）对于任何一台Web服务器，都是通过以下方法来验证用户身份：a)判断Session是否存在，如果存在，则认为验证通过。
单点登录 解决方案
单点登录解决方案1. 简介随着互联网应用的快速发展，用户对于便捷的登录方式提出了更高的要求。
为了解决用户面临的繁琐的多次登录问题，单点登录（SSO）应运而生。
单点登录是一种身份验证方式，允许用户在多个应用系统中使用同一组凭据（例如用户名和密码）进行登录，从而实现一次登录即可在多个应用系统中访问资源的目的。
在本文中，我们将介绍单点登录的工作原理和常用的解决方案，以及其中的一些实施细节。
2. 工作原理单点登录的核心思想是用户只需要登录一次，就可以在多个应用系统中进行访问。
其工作原理如下：•用户访问第一个应用系统（通常称为身份提供者）并输入凭据进行登录。
•身份提供者验证用户的凭据，并颁发一个令牌。
•用户访问其他应用系统时，令牌会被传递给每个应用系统。
•每个应用系统使用这个令牌来验证用户的身份，并授权其访问该应用系统的资源。
通过这种方式，用户可以在不需要多次输入登录凭据的情况下，方便地访问多个应用系统。
3. 常用解决方案下面介绍几种常见的单点登录解决方案。
3.1 基于Cookie的单点登录基于Cookie的单点登录是最简单和最常见的解决方案之一。
其工作原理如下：1.用户登录第一个应用系统后，该系统会将用户信息加密并存储在一个Cookie中。
2.用户访问其他应用系统时，该系统会验证Cookie并提取用户信息。
3.如果验证通过，用户将被授权访问该应用系统的资源。
优点： - 简单易行，适用于大多数Web应用。
- 无需修改现有的用户数据库。
缺点： - 存在Cookie劫持的风险。
- 无法支持跨域访问。
3.2 基于Token的单点登录基于Token的单点登录是一种更安全和灵活的解决方案。
其工作原理如下：1.用户登录第一个应用系统后，该系统会颁发一个Token给用户。
2.用户在访问其他应用系统时，会将Token附加在请求中。
3.每个应用系统通过验证Token来确认用户的身份，并授权其访问该系统的资源。
优点： - 提供更高的安全性，因为Token是加密的。
Jsp中操作Cookie及跨域访问的详细测试
做J2EE开发已经好几年了,对cookie的了解仅限于知道其使用方式、优缺点及一些简单的基本原理,工作中有些项目也使用cookie,基本上都是用于记录用户的登录信息(有很多知名网站用于记录客户个人信息或访问习惯的鄙视一下),再次访问时不需要再次登录,由于我是做企业应用的,因此一般cookie也会用于做sso的方案,这个确实非常方便,尤其是多机集群环境下,一个节点宕机,只要有另一个节点能提供服务,用户就不会有所感知,避免了session复制这种重量级方案。
网上关于cookie的资料比较多也比较杂,有讨论用各种语言操作cookie的,也有讨论用cookie如何实现sso的,也有变相实现cookie跨域访问的方案,今天准备用java/jsp做一个cookie操作的完整测试,一方面加深印象,一方面给做企业应用的新手朋友一个指引,只要耐心将下边各个测试过程跟下来,保证你对cookie会有一个更深层次的认识。
多的不说了,测试环境JDK1.5 + Eclipse3.6 + Tomcat5.0.28测试过程如下:开发2个web应用,分别为web1和web2,web1应用的web根下创建一个index.jsp,内容如下:<%@ page language="java" contentType="text/html; charset=UTF-8"pageEncoding="UTF-8"%><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "/TR/html4/loose.dtd"><%Cookie[] cookies = request.getCookies();if(cookies != null && cookies.length > 0){for(int i=0;i<cookies.length;i++){Cookie cookie = cookies[i];System.out.println("web1----cookie name:"+cookie.getName()+" value:"+cookie.getValue());if("myCookieName".equals(cookie.getName())){//如果cookie已存在则删除掉cookie.setMaxAge(0);response.addCookie(cookie);}}}//用java代码创建cookie的方法如下,构造的参数是cookie的name和valueCookie cookie = new Cookie("myCookieName","myCookieValue1");cookie.setPath("/");response.addCookie(cookie);%><html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Insert title here</title></head><body>This is web1's index.jsp</body></html>web2应用的web根下创建一个index.jsp,内容如下:<%@ page language="java" contentType="text/html; charset=UTF-8"pageEncoding="UTF-8"%><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "/TR/html4/loose.dtd"><%Cookie[] cookies = request.getCookies();if(cookies != null && cookies.length > 0){for(int i=0;i<cookies.length;i++){Cookie cookie = cookies[i];System.out.println("web1----cookie name:"+cookie.getName()+" value:"+cookie.getValue());if("myCookieName".equals(cookie.getName())){//如果cookie已存在则删除掉cookie.setMaxAge(0);response.addCookie(cookie);}}}%><html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Insert title here</title></head><body>This is web2's index.jsp</body></html>2个应用基本一样,web1负责获取系统中的cookie然后输出name和value到控制台,并创建一个cookie,web2则只获取cookie然后输出name和value到控制台,这两个应用功能非常好理解。
iframe跨域访问cookie和session的解决方法
iframe跨域访问cookie和session的解决方法一、问题背景介绍随着互联网技术的不断发展，前端页面中的IFrame变得越来越普遍。
然而，IFrame在跨域访问时，会遇到Cookie和Session无法传递的问题。
这个问题在一定程度上限制了网页的功能和用户体验。
为了解决这个问题，本文将介绍几种常见的解决方法。
二、IFrame跨域访问原理IFrame本质上是一个浏览器窗口，它与其他域的页面进行交互时，会受到同源策略的限制。
同源策略是指浏览器为了保护用户信息安全，限制来自不同源的页面之间的交互。
在这种情况下，Cookie和Session无法跨域传递，从而导致了一系列问题。
三、解决方案1.服务端设置Cookie和Session为了解决跨域问题，可以在服务端设置Cookie和Session。
当用户访问某个页面时，服务器会为其分配一个唯一的Session ID。
然后将这个Session ID存储在Cookie中，以便下次访问时使用。
这样，即使用户通过IFrame访问其他域的页面，也可以保证Session的连续性。
2.使用JSONP技术JSONP（JSON with Padding）是一种跨域通信的技术。
它通过在HTML 标签中插入一个script标签，来实现跨域数据传输。
JSONP的优势在于它不需要修改服务器端的代码，只需在客户端修改即可。
但是，JSONP只支持GET请求，不支持POST请求。
3.使用代理服务器代理服务器是一种在客户端和服务器之间进行数据传输的中间服务器。
通过使用代理服务器，可以绕过浏览器的同源策略，实现跨域访问。
在服务器端，可以将Cookie和Session存储在代理服务器上，然后在客户端通过Ajax 请求获取数据。
4.使用Ajax进行跨域通信Ajax（Asynchronous JavaScript and XML）是一种异步的Web开发技术。
通过Ajax，可以实现在不刷新页面的情况下，与服务器进行数据交互。
实现单点登录的三种方式
实现单点登录的三种⽅式1.登录功能登录功能通常都是基于 Cookie 来实现的。
当⽤户登录成功后，⼀般会将登录状态记录到 Session 中，或者是给⽤户签发⼀个 Token，然后浏览器将Session 的 ID 或 Token 保存到 Cookie 中，浏览器在之后的每次请求中携带它们。
当服务端收到请求后，通过验证 Cookie 中的信息来判断⽤户是否登录。
2.单点登录（Single Sign On, SSO）单点登录指的是：⽤户只需登录⼀次，就可访问同⼀帐号平台下的多个应⽤系统。
单点登录的本质就是在多个应⽤系统中共享登录状态。
如果⽤户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享Session，⽐如可以将 Session 存到同⼀个Redis 中，⽤户访问时，都可以读取同⼀个Redis 的 Session来获取登录状态。
但由于不同的应⽤系统有着不同的域名，尽管 Session 共享了，但是由于 Session ID 是往往保存在浏览器 Cookie 中的，因此⽆法跨域名传递，也就是说当⽤户在 中登录后，Session ID 仅在浏览器访问 时才会⾃动在请求头中携带，⽽当浏览器访问 时，Session ID 是不会被带过去的。
所以实现单点登录的关键就是，如何让 Session ID（或 Token）在多个域中共享。
实现sessionid或者token多域共享主要有三种⽅式，⽗域cookie、认证中⼼、localstorage3.实现⽅式（1）⽗域cookie将 Session ID（或 Token）保存到⽗域中。
也就是将 Cookie 的 domain 属性设置为主域名，同时将 path 属性设置为根路径，这样所有的⼦域应⽤就都可以访问到这个 Cookie 了。
缺点：不⽀持跨主域名（2）认证中⼼可以部署⼀个认证中⼼，⽤来专门负责处理登录请求。
检查token：⽤户访问某个应⽤系统，应⽤系统检查当前请求有没有 Token，如果没有，说明⽤户在当前系统未登录，跳转⾄认证中⼼。
单点登录实现方案
单点登录实现方案单点登录实现方案引言随着互联网的发展和应用的广泛化，用户需要在多个不同的应用中进行身份认证和登录操作。
为了提高用户体验和方便管理，单点登录（Single Sign-On，简称SSO）技术应运而生。
本文将介绍单点登录的概念、原理、实现方案以及其在实际应用中的优势。
什么是单点登录？单点登录是一种身份验证技术，允许用户只需一次登录即可访问多个相互信任的应用系统，而无需为每个应用系统单独进行身份验证。
简而言之，单点登录通过使用一个中央身份提供者来完成用户认证，并生成一个令牌，该令牌用于在用户访问其他应用时进行身份验证。
单点登录的原理单点登录的原理基于以下几个关键组件：1.用户身份认证：用户向身份提供者提交登录请求，并提供用户名和密码进行验证。
2.令牌生成：身份提供者验证用户的身份后，生成一个令牌，并将该令牌发送给用户。
3.令牌传递：用户在访问其他应用时，将令牌作为身份验证凭据一并传递给该应用。
4.令牌验证：其他应用接收到令牌后，将其发送给身份提供者进行验证。
5.用户认证与授权：身份提供者验证令牌后，如果有效，则向其他应用发送用户信息，并允许用户访问该应用。
单点登录的实现方案基于共享会话的实现方案基于共享会话的实现方案是单点登录的最常见方案之一。
它使用共享的会话存储来跨多个应用共享登录状态。
具体实现步骤如下：1.用户在一个应用上登录后，该应用在服务器端生成一个令牌，并将该令牌存储到共享会话存储中。
2.用户访问其他应用时，这些应用会检查共享会话存储中是否存在该用户的令牌。
3.如果检查成功，应用将允许用户继续访问，并使用令牌作为身份验证凭据。
4.如果检查失败，应用将要求用户重新进行身份验证。
基于共享会话的实现方案具有简单、易于理解的优点，但是需要共享会话存储，这对于分布式环境来说可能会带来一些挑战。
基于令牌验证的实现方案基于令牌验证的实现方案使用数字签名技术来验证令牌的真实性和完整性。
具体实现步骤如下：1.用户在一个应用上登录后，该应用在服务器端生成一个令牌，并使用私钥对令牌进行签名。
localStorage和cookie的跨域解决方案
localStorage和cookie的跨域解决⽅案前⾔和cookie⼤家都⽤过，我前⾯也有⽂章介绍过，⼤家也都了解，我前⾯也有⽂章详细描述过。
但是localStorage和cookie的跨域问题，好多⼩伙伴没有遇到或者不是很清楚，下⾯这篇⽂章，我来简单的聊聊！业务场景cookie跨域的业务场景很多，例如：1、百度www域名下⾯登录了，发现yun域名下⾯也⾃然⽽然登录了。
2、淘宝登录了，发现天猫也登录了，淘宝和天猫是完全不⼀样的2个域名。
cookie跨域⾸先说说同⼀个主域下⾯的跨域问题，类似www.百度和yun.baidu聊到这⾥，必须说⼀说cookie的参数或者属性了。
打开⾕歌浏览器，找到cookie,如下图：关于具体每⼀个参数，这⾥就不详细介绍了，不清楚的⼤家可以搜索⼀下，下⾯主要介绍⼀下domain个pathpathcookie ⼀般都是由于⽤户访问页⾯⽽被创建的，可是并不是只有在创建 cookie 的页⾯才可以访问这个cookie。
在默认情况下，出于安全⽅⾯的考虑，只有与创建 cookie 的页⾯处于同⼀个⽬录或在创建cookie页⾯的⼦⽬录下的⽹页才可以访问。
那么此时如果希望其⽗级或者整个⽹页都能够使⽤cookie，就需要进⾏路径的设置。
path表⽰cookie所在的⽬录，默认为/，就是根⽬录。
在同⼀个服务器上有⽬录如下：/post/,/post/id/,/tag/,/tag/haorooms/，/tag/id/现假设⼀个cookie1的path为/tag/，cookie2的path为/tag/id/，那么tag下的所有页⾯都可以访问到cookie1，⽽/tag/和/tag/haorooms/的⼦页⾯不能访问cookie2。
这是因为cookie2能让其path路径下的页⾯访问。
让这个设置的cookie 能被其他⽬录或者⽗级的⽬录访问的⽅法：document.cookie = "name = value; path=/";domaindomain表⽰的是cookie所在的域，默认为请求的地址，如⽹址为，那么domain默认为。