需求说明书

来源:互联网 发布:艾西文一键换ip mac 编辑:程序博客网 时间:2024/06/10 08:55
1、引言
1.1编写目的
              为了单点登录系统(SSO系统)的可行性,完整性,并能按照预期的设想实现该系统,特编写需求说明书。
        同时,说明书也发挥与策划和设计人员更好地沟通的作用。 
1.2背景
          a.鉴于集团运营的多个独立网站(称为成员站点),每个网站都具有自己的身份验证机制,这样势必造成:生活中的
             一位用户,如果要以会员的身份访问网站,需要在每个网站上注册,并且通过身份验证后,才能以会员的身份访问网
           站;即使用户以同样的用户名与密码在每个网站上注册时,虽然可以在避免用户名与密码的忘记和混淆方面有一定的
           作用,但是用户在某一段时间访问多个成员站点或在成员站点间跳转时,还是需要用户登录后,才能以会员的身份访 
            问网站。这样不仅给用户带来了不便,而且成员网站为登录付出了性能的代价; 
           b.如果所有的成员网站,能够实现单点登录,不仅在用户体验方面有所提高,而且真正体现了集团多个网站的兄弟 
            性。通过这种有机结合,能更好地体现公司大平台,大渠道的理念。同时,这样做也利于成员网站的相互促进与相互
            宣传。 
            正是出于上面的两点,单点登录系统的开发是必须的,是迫在眉睫的。 
1.3定义
               单点登录系统提供所有成员网站的“单一登录”入口。本系统的实质是含有身份验证状态的变量,
           在各个成员网站间共用
。单点登录系统,包括认证服务器(称Passport服务器),成员网站服务器。 
            会员:用户通过Passport服务器注册成功后,就具有了会员身份。
            单一登录:会员第一次访问某个成员网站时,需要提供用户名与密码,一旦通过Passport服务器的身份验证,
                              该会员在一定的时间内,访问任何成员网站都不需要再次登录。
            Cookie验证票:含有身份验证状态的变量。由Passport服务器生成,票含有用户名,签发日期时间,
                                 过期日期时间和用户其它数据。  
2、任务概述 
2.1目标
         SSO系统,是集团统一的Passport,SSO系统分两个阶段实施。第一阶段对于新注册的用户提供单点登录的功能。
      第二阶段,整合各个成员网站已有会员到单点登录系统中。
         Passport服务器作为各个成员网站的惟一身份验证入口,需要考虑其性能,扩展性,稳定性,安全性和维护成本。尤其
      要注意第二阶段的开发,做到统筹考虑。 
2.2最终用户的特点
         最终用户是数以万计网民。这就确定了用户使用电脑的水平是参差不齐的,在开发单点登录系统时,力争做到界面友
      好,措词简单明了。用户不用学习,就能使用该系统。 
3、需求规定      
     3.1 需求概述
           1)   注册:
            a.成员网站重定向到Passport服务器的注册页面,并且带有返回URL和成员网站ID。   
            b.通过Passport注册页面创建会员后,保存会员验证票到数据库和passport服务器所在域cookie中。同时,在成员网站
               的数据库上创建与Passport服务器数据库中会员的映射关系。
            c. 重定向到成员网站,填写会员个性信息。
            d. 保存会员个性信息,并把重定向传入的验证票保存到本地cookie和创建Session状态变量。
         2)登录:
            a、 SSO系统要实现各个成员网站的无缝结合,只要会员经过了认证服务器的登录验证(Passport服务器),该会员访
                  问其它任何的网站时,都不需要再次登录。
            b、 会员在第一次登录时,Passport服务器验证身份之后,生成的cookie验证票,只需保存到Passport服务器所在域的
               cookie中,不能采用向每个成员网站所在的域中写cookie,防止响应时间太长,给会员带来不友好的浏览体验。
               时,把下发给会员的cookie票保存到Passport服务器的数据库中,方便验证方式和会员行为统计的扩展。
         c、 会员一经通过身份验证,成功登录了某个成员网站(假设为网站A),需要利用Session和cookie两种方式保存会员已经登
               录的状态。
         d、 同一个浏览器进程中,会员在网站A的页面间跳转时,只需要根据Session中的状态变量加载登录框。不需要再与
               Passport服务器通信验证会员的身份。
         e、 会员通过验证登录了网站A,若会员从网站A跳转或重新打开浏览器登录其它成员网站(假设网站B),都需要与Passport
               服务器通信验证会员的票。但是,这次验证不要Passport服务器与数据库中保存的验证票进行比较验证,只需要验证
               Passport服务器域中的cookie验证票据有效即可。
         f、   对于验证cookie票,能够实现加密和数字签名保证cookie的机密性,完整性和不可抵赖性。
         g、 若果Passport服务器Down掉后,仍可以直接登录成员网站。 
        说明:上面高亮显示的表示二期开发功能。 
         3)登出、修改密码、找回密码和成员网站间的跳转,请查看IPO图表中相应的模块描述。

    
3.2对功能的规定

         SSO
系统包括注册、登录、登出、密码修改、密码找回、成员网站间跳转与用户管理模块。本说明书使用HIPO图描述
      系统机构和模块内部处理功能,它主要包括层次结构图和IPO图两个部分。层次结构图描述了整个系统的结构以及各个
      模块之间的关系;IPO图则描述了在某个特定模块内部的输入(I)、处理过程(P)、输出(O)思想。

     A、系统结构图
         
                                             
                           
1 SSO系统结构图

B、层次结构图
                     

                                       2系统层次结构图

CIPO图表    
备注:红色高亮部分,表示修改的逻辑

模块名称:会员注册
使用者:Passport服务器与各成员网站
输入部分   I
处理描述   P
输出部分   O
1. 重定向到Passport服务器,带
有返回URL和成员网站ID
2. 输入信息:邮箱、密码、区域(暂时没有使用验证码)。
3 3.提交注册信息,发出注册请求。
 4.注册用户从邮件中获得验证码,利用验证号激活用户,此时用户将成为合法会员。
5.会员个性信息(在成员网站填写)
1.邮箱是否可用的实时检查,及时提示邮箱是否可用(这里的可用仅仅是表示符合邮箱的规范,并且该邮箱没有被注册,不表示真正的可用)。
2.密码安全级别实时提示。根据字符长度、含有字符的种类,计算安全级别,并实时提示用户。安全级别分为:太短,差,良,优四个等级。
3.根据区域数据库,获得区域信息下拉框,结合会员区域IP,实现区域自动筛选,在允许的误差范围内不需手动选择区域。
4. 建立新会员
(1)验证会员提交的注册信息,若合法,把用于激活帐号的验证码发送到会员测试使用的邮箱中。
(2)会员使用验证码激活帐号,若激活成功,保存会员信息和会员验证票到数据库(Passport服务器数据库),并且验证票也保存到cookie中。同时调用成员网站的Web Service接口,把刚才产生的Passid保存到成员网站数据库中(建立映射关系)。
(3)重定向到成员网站。
(4)成员网站接收数据,提示会员填写个性信息,并提交到成员网站服务器。
(5)保存个性信息与接收的会员验证信息到成员网站数据库与cookie中,同时在Session中保存会员已验证的状态信息。
(5)导航会员到某个页面。
1.   Passort服务器保存新会员信息和会员验证票到数据库中。
2.   成员网站Web Service,在成员网站数据库中添加会员信息,利用Passid建立与Passport服务器上会员的映射关系,并返回操作成功或失败状态信息。
3. 修改成员网站数据库中会员的个性信息。
4.保存会员验证票到cookie中,同时保存会员通过验证的状态到Session中。

                                                                  1:会员注册模块

 
 

模块名称:会员登录
使用者:Passport服务器与各成员网站
输入部分   I
处理描述   P
输出部分   O
1. 会员第一次登录时输入Email
和密码。
2. 提交会员信息到Passport服务
  器。
 
说明:加载登录框之前,成员网
站会首先与Passport服务器通信,
获得会员是否已经登录过,根据
状态加载登录框。
1.在成员网站A含有登录框页面的
<head>区,利用
<script src=meber_auth.aspx> 在页头嵌入.aspx文件(成员网站上的文件)。
a.页面首先查看Session中的状态变量,如果状态变量为NULL,则查看cookie中的状态变量。
b.根据SessionCookie中状态变量的情况,实现与Passport服务器上的Web Service通信,确定会员是否已经登录。
2.根据会员登录与否,加载登录框。
3.如果没有登录,显示会员输入Email和密码的登录框。
4.会员提交信息到Passport服务器上的Web Service ,通过验证后生成cookie票,并返回登录状态值和cookie票到成员网站。成员网站保存登录状态变量与cookie票。
 
说明:会员通过任何一个成员网站登录成功后,表示已经登录了所有的成员网站。
1.根据登录状态加载登录框
2. Passport服务器上创建会员
验证票,保存到数据库与cookie
3.Passport Web Service 返回登录
状态值与cookie验证票到成员网站。
4.保存会员验证票到cookie中,同时保存会员通过验证的状态到Session中。

                                                                              2:会员登录模块

 

模块名称:会员登出
使用者:Passport服务器与各成员网站
输入部分   I
处理描述   P
输出部分   O
1.成员网站重定向到Passport服务器的登出页面,并带有返回URL,成员网站ID和验证票。
 
1.在成员网站A重定向到Passport服务器,Passport接收cookie验证票,并验证是否合法。
2.Passport修改数据库中验证票使之失效,清除cookie中的验证票。
3.重定向到成员网站,清除cookie中的验证票和Session中登录状态变量。
4.导航会员到某个页面。
1.修改数据库中的验证票使之失效,并清除cookie
2.重定向到成员网站。

                                                                                    3:会员登出
 

模块名称:修改密码
使用者:Passport服务器与各成员网站
输入部分   I
处理描述   P
输出部分   O
1.成员网站重定向到Passport服务器修改密码页面,并带有返回URL,验证cookie票。
2.会员输入原密码和新密码。
3.提交数据。
1.在成员网站A重定向到Passport服务器,Passport接收cookie验证票,并验证是否合法。
2.Passport修改会员密码。
3.重定向到成员网站,并带有修改成功与否的状态变量。
4.导航会员到某个页面。
1.修改数据库中会员的密码。
2.重定向到成员网站。

                                                                                    4:会员登出
 

模块名称:找回密码
使用者:Passport服务器与各成员网站
输入部分   I
处理描述   P
输出部分   O
1.成员网站重定向到Passport服务器找回密码页面,并带有验证cookie票。
2.会员输入Email地址
3.提交数据
4.激活新密码(邮箱将收到一个激活密码的URL)
1.在成员网站A重定向到Passport服务器,Passport接收cookie验证票,并验证是否合法。
2.Passport为会员生成新密码,并向会员邮箱中发送一个激活密码的URL
3.激活新密码
4.使用新的密码登录
1.为会员生成新密码,但未激活。
2.提示会员收邮件激活新密码,激活后方可使用。

                                                                                    5:找回密码

 

模块名称:成员网站间跳转
使用者:Passport服务器与各成员网站
输入部分   I
处理描述   P
输出部分   O
成员网站A链接到其它成员网站B,之后处理同会员登录模块。

                                                                              6:成员网站跳转
 

模块名称:票据加解密及验证
使用者:Passport服务器
输入部分   I
处理描述   P
输出部分   O
1.会员Passid、票据发布时间、票据有效时间、会员其它信息数据。
2.调用Web Service方法验证
a. 传入Email和密码
b. 传入cookie验证票
 
1.接收成员网站请求数据(Email与密码)
2. 由会员Passid、票据发布时间、票据有效时间、会员其它信息数据生成加密的cookie验证票,并且保存到数据库和cookie中。
3. 接收cookie验证票,解密并验证,返回给成员网站登录状态值。
 
1.生成加密的cookie票。
2.返回会员登录状态值。

                                                                        7票据加解密及验证

  Tags:单点登录系统,单一登录系统,SSO系统

【声明】本文版权属于个人所有,转载需经本人同意。谢谢合作

FeedBack:
#1楼 
2007-01-25 20:51 | Jeffrey Zhao
标题应该是SSO,不是SOO。:)
  回复  引用  查看    
#2楼 
2007-01-25 20:54 | 亚历山大同志
SSO的话,很多ASP系统有很好的设计,建议可以参考一下
  回复  引用  查看    
#3楼 
2007-01-25 21:37 | Anders Cui
来得好及时,这两天正在烦着这个东东呢.
  回复  引用  查看    
#4楼 
2007-01-25 21:40 | Jeffrey Zhao
.NET下使用没有找到开源或者免费的SSO解决方案,有哪位大哥能够指点一下吗?
  回复  引用  查看    
#5楼 
2007-01-25 21:47 | 亚历山大同志
我这里有电信级系统的SSO模块的设计和源代码,呵呵
  回复  引用  查看    
#6楼 
2007-01-25 21:53 | Jeffrey Zhao
@亚历山大同志
可惜不免费,呵呵。
  回复  引用  查看    
#7楼 
2007-01-25 21:55 | Anders Cui
@亚历山大同志
那老兄能不能再写个 手把手教你写个SSO系统 :)
  回复  引用  查看    
#8楼 
2007-01-25 23:10 | JoeLee [未注册用户]
Passport,非逼我输入个Email。烦的很。
  回复  引用  查看    
#9楼 
2007-01-26 08:40 | 高海东
学习
  回复  引用  查看    
#10楼 [楼主]
2007-01-26 09:09 | 海纳百川
To 亚历山大,

能把你电信级系统的SSO模块的设计和源代码,给大家共享吗?

  回复  引用  查看    
#11楼 [楼主]
2007-01-26 09:18 | 海纳百川
To Jeffrey zhao,
本文SSO设计方案已经在.NET框架(.NET 1.1+MS SQL +IIS)和PHP(Apache+MySql+php)框架的站点间实现了。
开发前期,也在网上找了好长时间,但没有找到免费和开源的SSO方案。各位大虾,对SSO特有研究的给指点指点。
  回复  引用  查看    
#12楼 
2007-01-26 09:41 | 轻舞flash [未注册用户]
如果成员网站和Passport网站的的根域不一样.能读Passprot生成的验证票据吗?
  回复  引用  查看    
#13楼 [楼主]
2007-01-26 10:00 | 海纳百川
To 轻舞flash,

文章中谈到的cookie验证票,要借助cookie才能使用的,但cookie肯定是不能跨域的,在passport网站域中保存的验证票成员网站是读不了的。利用重定向,重定向到要访问验证票的域就可以访问验证票了。

下篇中会有这方面的接口定义。请关注.....
  回复  引用  查看    
#14楼 
2007-01-26 10:50 | 冬冬
我们学校也用的这种东西,不过成员站点的集成一直是问题,也就是文中的第二部分。

我觉得用WebService提供统一验证服务,自身加载网站特有数据,是个不错的办法。

可以在用户登录后,将登录相关信息生成标记储存在数据库中。解决Cookie的问题,这个标记只在用户进入其它成员网站的时候使用,如果用户Session匹配,则成员网站生成自身的Session。登录标记应该和IP、浏览器等信息相关。
  回复  引用  查看    
#15楼 
2007-01-26 10:50 | 亚历山大同志
@海纳百川
最近会给武汉电信做一个类似的系统,到时候会把互联星空的SSO模块剥离出来,等剥离出来了我单独的弄一个发布出来
  回复  引用  查看    
#16楼 
2007-01-26 11:51 | 臭石头
这个方案,简直和我们公司的方案一摸一样。
现在我最烦的就是,每进入一个新的系统,都要跳转两次,先跳到SSO,再跳回来。

可有好的方案?
  回复  引用  查看    
#17楼 [楼主]
2007-01-26 12:33 | 海纳百川
To 臭石头,

你说的两次跳转,一般是在第一次登录某个系统需要这样。如果你访问的站点的域中cookie保存有验证票,直接进入该网站或利用Web Server验证你的票后,再进入该网站。
我们是按照上面说的第二个方法实现的。
  回复  引用  查看    
#18楼 [楼主]
2007-01-26 12:38 | 海纳百川
本设计有个致命的弱点,如果Passport服务器宕机,则整个系统会死的很难堪的!我们的passport要双机(或多机)备份的。除该方案外,大家伙还有好的方案吗?

  回复  引用  查看    
#19楼 
2007-01-28 18:42 | 臭石头
To 海纳百川

可以说得更明白一点么?
在网站的域cookie中保存验证票,岂不是相当于在这个网站保存密码了?这不是我要的效果,很多网站,是不允许保存这个Cookie的。关闭所有窗口后,再进入站点,是需要跳转到SSO的。保存密码是在SSO那里实现的。


  回复  引用  查看    
#20楼 [楼主]
2007-01-29 08:52 | 海纳百川
To 臭石头,

cookie中保存验证票,怎么会相当于保存密码呢?加密的验证票只是表示某个用户登录成功的状态,并且可以通过“登出”,把登录成功的状态清除。当然,没有绝对的安全机制,应该说该机制满足了一般的商务站点的要求。
  回复  引用  查看    
#21楼 
2007-02-11 15:22 | 臭石头
我进入成员网站A,执行要求登录的操作的时候,重定向到SSO,在SSO登录完成后,重定向到A,已登录,操作……

关闭浏览器。

重新进入A,执行要求登录的操作,此时,必须再次重定向到SSO进行登录;如果你要说,在上面SSO登录后,在A中把cookie验证票保存到A所在域的Cookie,以实现第二次进入A的时候不需要重定向到SSO登录,那么就存在授权和SSO不同步的问题,已经不安全的问题(仅仅靠这个Cookie历史中的验证票,A就认定来访者为合法用户,太冒险了,如果这个票挨偷了怎么办?)

呵呵,如果你真是这么做,那么,要远远的比我们公司的要差。
  回复  引用  查看    
#22楼 [楼主]
2007-02-11 16:54 | 海纳百川
To 臭石头,

1、第二次登录的时候,若A站中的验证存在,则需要调用Web Service(SSO提供)接口验证cookie验证票的合法行。

2、当然保存到cookie中的验证票是不安全的,容易伪造或盗取,但如果用户离开网站的时候,及时地登出(或者叫注销:删除本地cookie中的验证票,并使数据库中的验证票失效)就可以保证安全问题。


  回复  引用  查看    
#23楼 
2007-02-11 18:45 | 臭石头
◎海纳百川

如果真的这么做……呵呵,可能更适用于一台机子固定某个用户使用吧,多个人使用的话,你也应该知道会出现什么问题的了。

我们公司的SSO用了一年多,在安全方面,我想应该要远比你这方案要强,但它缺点就是跳,整天跳来跳去,每个开发人员,以及用户,都觉得挺烦的。现在公司要求改进,所以我看看你们有没有什么更好的解决方案。
  回复  引用  查看    
#24楼 [楼主]
2007-02-12 09:09 | 海纳百川
To 臭石头,

多个人使用一台机子会出现什么问题?

请说一下你们公司SSO在安全方面是怎么做的好吗?

请把问题说明白,这样更有利于大家相互沟通,谢谢!
  回复  引用  查看    
#25楼 
2007-02-12 13:09 | 臭石头
计算机PC1中,如果在A站点的域中保存了User1的Cookie票,那么,User2使用PC1的进入A站点的时候,按你的说法,将会自动登录为User1,因为它提交了User1的Cookie票;

如果在PC1中没有保存Cookie票,那么,不管是哪个User进入A站点,都将会跳转到SSO。

上面是按照“我所理解的你的说法”推理的,不知道是否理解正确。

在PC1,用户User1第一次登录A站点的时候,会跳转到SSO进行登录验证,验证完成后,会把工作票附加到重定向的URL后面传递给A,这是一个不安全的过程,呵呵。
  回复  引用  查看    
#26楼 
2007-03-11 11:17 | 臭石头
没下文了……
  回复  引用  查看    
#27楼 [楼主]
2007-03-12 16:40 | 海纳百川
@臭石头

1、
你理解的没错,如果User1没有登出的话,User2(其实是任意用户)使用PC1登录网站A,都会登录为User1

2、在PC1,用户User1第一次登录A站点的时候,会跳转到SSO进行登录验证,验证完成后,会把工作票附加到重定向的URL后面传递给A,这是一个不安全的过程。这个过程确实不安全,可以从防止监听上下功夫

3、在cookie中保存验证票,给安全带来很大的威胁。如何cookie值被仿造,后果很严重。


请问,在处理上面的两个问题时,您是怎么作的?如果必须要在cookie中保存验证票,在防止伪造cookie方面您有什么高招吗?谢谢!


  回复  引用  查看    
#28楼 
2007-03-12 17:35 | 臭石头
使用数字签名以及非对称加密就可以保证安全了,更具体的我就不能说了,这是公司机密。

而我要解决的问题,就是跳转的问题,能不能不跳?
  回复  引用  查看    
#29楼 [楼主]
2007-03-12 18:40 | 海纳百川
@臭石头

1、使用数字签名和非对称加密也不能解决伪造cookie验证票给安全带来的安全威胁。正在为这个问题困惑呢?老兄有高招吗?


2、如果不在客户端保存cookie验证票,跳转就不能避免。
  回复  引用  查看    
#30楼 
2007-03-12 20:05 | 臭石头
1,不是不能解决,而是可能你签名的地方不对。呵呵,真的不好意思,我不能说太多,公司对这些管理很严格的。

2,这是一般认识,我希望有更好的,MS的就不错
posted on 2007-01-25 19:28 海纳百川 阅读(5065) 评论(35)  编辑  收藏 所属分类: 互联网 、WEB开发/.NET
原创粉丝点击