需求说明书

转载 2007年10月09日 14:38:00
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:
2007-01-25 20:51 | Jeffrey Zhao
标题应该是SSO,不是SOO。:)
  回复  引用  查看    
2007-01-25 20:54 | 亚历山大同志
SSO的话,很多ASP系统有很好的设计,建议可以参考一下
  回复  引用  查看    
2007-01-25 21:37 | Anders Cui
来得好及时,这两天正在烦着这个东东呢.
  回复  引用  查看    
2007-01-25 21:40 | Jeffrey Zhao
.NET下使用没有找到开源或者免费的SSO解决方案,有哪位大哥能够指点一下吗?
  回复  引用  查看    
2007-01-25 21:47 | 亚历山大同志
我这里有电信级系统的SSO模块的设计和源代码,呵呵
  回复  引用  查看    
2007-01-25 21:53 | Jeffrey Zhao
@亚历山大同志
可惜不免费,呵呵。
  回复  引用  查看    
2007-01-25 21:55 | Anders Cui
@亚历山大同志
那老兄能不能再写个 手把手教你写个SSO系统 :)
  回复  引用  查看    
2007-01-25 23:10 | JoeLee [未注册用户]
Passport,非逼我输入个Email。烦的很。
  回复  引用  查看    
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特有研究的给指点指点。
  回复  引用  查看    
2007-01-26 09:41 | 轻舞flash [未注册用户]
如果成员网站和Passport网站的的根域不一样.能读Passprot生成的验证票据吗?
  回复  引用  查看    
#13楼 [楼主]
2007-01-26 10:00 | 海纳百川
To 轻舞flash,

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

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

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

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

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

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

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

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


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

cookie中保存验证票,怎么会相当于保存密码呢?加密的验证票只是表示某个用户登录成功的状态,并且可以通过“登出”,把登录成功的状态清除。当然,没有绝对的安全机制,应该说该机制满足了一般的商务站点的要求。
  回复  引用  查看    
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中的验证票,并使数据库中的验证票失效)就可以保证安全问题。


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

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

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

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

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

请把问题说明白,这样更有利于大家相互沟通,谢谢!
  回复  引用  查看    
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,这是一个不安全的过程,呵呵。
  回复  引用  查看    
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方面您有什么高招吗?谢谢!


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

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

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


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

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

软件需求说明书 编写实例

你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大,但客户会很重视,所以说明必须得到赞同。   现在你正在设计其中的一个特性,已经发现了需求的一些问题...
  • 123hui
  • 123hui
  • 2006-02-17 18:51:00
  • 16210

一份非常好的软件需求说明书模板

  • 2009年06月15日 13:21
  • 38KB
  • 下载

软件需求说明书应包括的内容

软件需求说明书何志丹收藏1,引言     1。1编写目的     1。2背景     1。3定义      1。4参考资料2,任务概述      2。1目标      2。2用户特点       2。...
  • he_zhidan
  • he_zhidan
  • 2003-02-24 09:13:00
  • 2725

软件需求说明书模板

  • 2016年03月19日 09:44
  • 19KB
  • 下载

软件需求说明书(GB856T—88)

1引言 1.1编写目的 软件需求说明书是需求分析阶段的一个文档,是对软件目标及范围的求精和细化,深入描述软件功能和性能以及软件的约束范围,使用户和软件开发者对该软件的初始的规定有个大概的了解,有利于对...
  • changyinling520
  • changyinling520
  • 2015-10-01 12:22:40
  • 2231

软件需求说明书模板1

软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解, 使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下: 1 引言 1.1编写目的   说明编写这份软...
  • sokril
  • sokril
  • 2017-05-10 14:29:37
  • 737

【软件工程】——软件需求说明书

1.什么是软件需求 ?   通俗的讲,对用户的意图不断解释和验判的过程,要对经过系统可行性分析所确定的系统目标做更为详细的描述。   加入你是个建筑工程师,有个客户找你建一个鸡窝,这个时候更需要与...
  • LyySwx
  • LyySwx
  • 2016-10-15 15:03:11
  • 607

微信平台功能需求说明书

  • 2015年07月11日 15:53
  • 2.21MB
  • 下载

简单的软件需求说明书范例

  • 2009年07月17日 20:16
  • 32KB
  • 下载

产品需求说明书 PRD模版

XXX产品需求说明书 [版本号:V+数字]                 编  制:   日  期:   评  审...
  • zouhui1003it
  • zouhui1003it
  • 2017-03-01 07:45:27
  • 459
收藏助手
不良信息举报
您举报文章:需求说明书
举报原因:
原因补充:

(最多只允许输入30个字)