P3P多站跨域互通概要设计.docx
- 文档编号：11213806
- 上传时间：2023-05-29
- 格式：DOCX
- 页数：20
- 大小：500.07KB
P3P多站跨域互通概要设计.docx
《P3P多站跨域互通概要设计.docx》由会员分享，可在线阅读，更多相关《P3P多站跨域互通概要设计.docx（20页珍藏版）》请在冰点文库上搜索。
P3P多站跨域互通概要设计
多站跨域互通系统概要设计
朱孙盛
2012年05月
【开发原由】
-项目编号：
-需求文档：
（如果有需求文档，直接填写这两项，不需后面再写开发源由）
-开发原由：
如果没有技术方案，在此处填写是谁（哪个部门或员工）提出该项目，目的是为了达到什么业务、技术目标
注：
本模板所有粗体斜体字为说明性文字，请在做方案时全部去掉
版本历史：
版本号
作者
时间
变动内容
1.0
朱孙盛
2012.05
创建文档
1.引言
编写目的
总体设计出软件系统框架，对系统关键部分做出详细设计。
预期读者
开发人员、技术主管、运营人员、运维人员
参考资料
《统一身份认证（CAS）》
《新浪-微博登录认证》
《太平洋网等登录认证》
《官网单点登录调研报告.docx》
项目技术开发背景
项目名称
需求提出者
开发小组
2.任务
设计目标
提供用户在我们某一个官网登录后，访问其他官网不需要再次登录；退出一个官网之后，其他官网相应退出；登录成功之后定位到之前浏览的页面。
每个官网各有各的域名。
开发环境
Windows、Eclipse、Resin、Mysql
运行环境
Linux、Resin、Mysql
3.名词定义
【说明】
相当于字典表。
字段
说明
SSO
SSO英文全称SingleSignOn，单点登录
P3P
（PlatformforPrivacyPreferences）个人隐私保护策略
ticket
可以进行身份校验且一次性使用的通行票据
RSA
RSA是目前最有影响力的公钥加密算法，它能够抵抗到目前为止已知的所有密码攻击，已被ISO推荐为公钥数据加密标准。
CAS
一种开源的企业级单点登录解决方案
4.系统设计
产品定义：
在目前互联网上，有些比较大型的网站，如：
新浪网、太平洋网等，使用了多个不同域名官站，但这些网站的登录用户是一至的。
如果能做到在某一个官网成功登录之后，访问自己其他官站都不需要再登录，将会给用户带来更为方便和更友好体验。
由于不同域名之间，采用传统共享cookie方式不可实现，本文将采用新的更简捷的方式，实现Ochirly、fivePlus、更多站点…官网的用户SSO互通。
4.1.系统功能结构描述
单点登录分为认证服务中心、EC官网、和客户端三大部分，客户端针对网友用户，EC官网需要实现登录、登出、鉴权处理等模块。
认证服务中心有EC官网管理、授权校验、登录统计等功能。
功能模块
功能
描述
前端
用户浏览器
用户访问和浏览EC官网的工具
EC官网
登录处理
登录到官网的cookie设置等
执行正常登录到官网处理流程。
登出处理理
登出官网的cookie的清除
执行正常退出官网处理流程。
鉴权处理
访问资源鉴权
鉴权器过滤需要需要鉴权的链接和地址。
认证服务中心
EC官网配置
配置域名
配置接入EC官网的域名,实现它们之间的互通
授权校验
身份校验
判断用户账号和密码是否正确
登录统计
统计信息
统计登录用户数，登录状态，在线时长等信息。
4.2.系统架构设计
服务器描述：
官网服务器，就是我们现在的Ochirly、FivePlus等对外的前端服务器。
数据库服务器,存储官网会员用户信息的服务器。
浏览器，会员用户的个人电脑浏览器、手机、平板电脑浏览器等。
认证服务器，对会员进行合法性登录认证的服务器。
4.3.系统软件功能实现逻辑描述
系统主要实现主要有划分为登录处理，登出处理和票据生成和验证等主要功能。
4.3.1登录处理
当用户尚未登录，或者访问一个需授权页面而未登录时，都要进行登录处理。
登录处理的详细流程：
1.当用户访问授权页面或者点击登录时，就进入登录流程。
2.EC官网根据用户提交的cookie判断是否处于已登录状态，如果以是，则返回页面，如果不是，则保留当前请求地址，返回需要重定向的页面。
3.如果尚未登录，浏览器获取EC官网返回的指令，进行重定向处理。
重定向到认证中心的登录页面，并携带最终的跳转地址。
4.认证中心返回登录账户和密码输入框页面。
5.浏览器用户输入账户和密码等信息，并提交到认证中心。
6.认证中心获取用户提交的账户和密码信息，并且查询数据库获得该账户的相关信息。
7.数据库返回登录账户的基本信息。
如果该账户不存在，返回空值。
8.认证中心判断提交的账户和密码是否有效。
进行合法性验证。
9.如果失败，认证中心返回浏览器登录失败的信息和原因。
10.如果成功，认证中心会获得目前所有的官网列表，并且每一个官网都生成其Ticket门票，加上最终跳转地址等信息，一起返回给浏览器。
11.浏览器获得带Ticket门票的官网列表之后，会异步自动完成到各官网Ticket门票的挂号注册。
12.各官网收到浏览器带Ticket门票的上门登录时，校验Ticket的合法性，Ticket包含账户的UserId,如果失败，返回登录无效。
如果合法，则完成账户的登录过程，返回登录成功，并且携带了cookie等信息。
13.如果登录成功，浏览器根据官网返回的cookie值，自动设置目前账户已是登录状态,完成登录过程。
14.浏览器的会继续向EC官网请求之前的最终跳转地址。
15.由于刚才完成了登录，EC官网判断账户已经处于登录状态，直接返回用户需要浏览的页面。
4.3.2登出处理
当需要退出时，需要同时在其他官网退出，下面是登出处理过程。
登出处理的详细流程：
1.当用户登出链接时，就进入登出流程。
2.EC官网保留最终登出地址，并返回重定向地址。
3.浏览器收到重定向地址，并重定向到认证中心的登出页面。
并携带原来官网的最终登出地址。
4.认证中心进行登出处理，会获得目前所有的官网列表，并且每一个官网都生成其Ticket凭票，加上最终跳转地址等信息，一起返回给浏览器。
5.浏览器获得带Ticket凭票的官网列表之后，会异步自动完成到各官网Ticket凭票的注销处理。
6.各官网收到浏览器带Ticket凭票的上门登出时，校验Ticket的合法性，Ticket包含账户的UserId,如果失败，返回登出无效。
如果合法，则完成账户的登出过程，返回登出成功，并且携带了清除的cookie等信息。
7.如果登出成功，浏览器根据官网返回的cookie值，自动清除目前账户的登录状态,完成登出过程。
8.浏览器的会继续向EC官网请求之前的最终登出跳转地址。
9.EC官网返回请求的页面信息。
4.3.3票据Ticket的生成与验证
每当认证服务中心要向EC官网传递用户的登录或者登出操作时，票据的生产和验证就需要。
票据的生产一般在认证服务中心。
票据的验证在每一个EC官网，验证的核心是使用RSA算法，认证服务中心拥有私钥，EC官网使用公钥。
另外，认证中心服务器和EC官网服务器系统时间必须相同或者接近。
票据生成的流程：
1.请求生成一个票据
2.系统随机产生一个32位的字符串hash
3.获取当前系统的时间time，是一个长整形的数字。
4.加上账户的ID和其它信息，第2、3步生成的值，结合为一个字符串类型的摘要。
5.采用RSA算法，用私钥将第4步的摘要数据加密。
6.采用Base64算法，对第5步的进行加密，生成一个新的字符串数据
7.得到并返回票据字符串
票据验证的流程：
1.请求验证一个票据。
2.采用Base64算法，对票据进行解密，如果不成功，返回验证失败。
3.采用RAS算法，用公钥对第2部数据进行解密，如果不成功，返回验证失败。
4.从中分析出hash，time，和用户id以及其它信息，如果不成功，返回验证失败。
5.获取当前系统的时间curtime，是一个长整形的数字。
6.通过curtime减去time，两者时间差必须在有效范围之内。
如果不是，返回票据超时失效，认证失败。
7.通过当地缓存，根据key=hash，获取其值，判定是否已经存在，如果存在，返回票据已被使用，验证失败。
8.使用当地缓存，设置hash已经被使用，下次不能再用。
9.如果上述步骤执行有异常，则通常情况下默认票据验证失败。
10.经过第1-9步之后，认为票据正常，返回验证成功。
4.3.4利用P3P技术实现Cookie的跨域设置和访问
在通常情况下，不同的域名之间，页面的Cookie信息是受到限制和保护的。
如果想在认证服务器认证通过之后，对其它官网和进行cookie设置，标记其已经登录是不可行的。
但是我们可以通过携带认证中心的Ticket,到官网并授权认证之后，在官网的Http协议返回头加入下面P3P的信息，即可实现上的跨域问题。
P3P:
CP="CURaADMaDEVaPSAoPSDoOURBUSUNIPURINTDEMSTAPRECOMNAVOTCNOIDSPCOR"
在本中，认证服务器有两处用到此方法，分别是：
a.异步自动完成各官网Ticket门票的挂号注册。
b.异步自动完成各官网Ticket凭票的注销。
请看下面细节分析:
1.当认证服务器确定用户认证成功之后，需分别到官网和进行“门票的挂号注册”或“凭票的注销”时，认证服务器页面会返回（如下图）信息。
在标签