统一认证与单点登录系统产品需求规格说明书.docx
《统一认证与单点登录系统产品需求规格说明书.docx》由会员分享，可在线阅读，更多相关《统一认证与单点登录系统产品需求规格说明书.docx（20页珍藏版）》请在冰点文库上搜索。
统一认证与单点登录系统产品需求规格说明书
机构图标
统一认证与单点登录系统
产品需求规格说明书
文件状态：
[√]草稿
[]正式发布
[]正在修改
文件标识：
BUPT-SSO-RD-PRS
当前版本：
作者：
完成日期：
2012-06-02
北京邮电大学
版本历史
版本/状态
作者
参与者
起止日期
备注
刘润峰
2012-05-31
2012-06-04
1文档介绍
1.1文档目的
此文档用于描述统一认证与单点登录系统的产品需求，用于指导设计与开发人员进行系统设计与实现。
1.2文档范围
本文档将对系统的所有功能性需求进行消息的描述，同时约定非功能性以及如何与第三方系统进行交互。
1.3读者对象
本文档主要面向一下读者：
1.系统设计人员
2.系统开发与测试人员
3.系统监管人员
4.产品甲方管理人员
1.4参考文档
《凯文斯信息技术有限公司单点登录及统一用户技术方案》
1.5术语与缩写解释
缩写、术语
解释
SSO
全称SingleSignOn，单点登录
…
2产品介绍
产品全名《统一认证与单点登录系统》（以下简称系统），英文名称SSO。
SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。
它是目前比较流行的企业业务整合的解决方案之一。
此系统是与“凯文斯信息技术有限公司”（以下简称凯文斯）进行合作，由我方独立进行研发。
3产品面向的用户群体
此系统主要面向企事业单位以及社会组织，最终实现的软件系统将交由凯文斯方进行使用。
4产品应当遵循的标准或规范
无
5产品范围
系统最终包含统一用户管理、统一认证、单点登录三个部分，最终应用到基于BS框架的各种应用系统中。
系统将采用BS方式进行实现。
6产品中的角色
角色名称
职责描述
系统管理员
负责配置和维护系统功能
HR管理员
负责管理用户信息等
普通用户
使用系统中提供的用户自助服务
7产品的功能性需求
7.1功能性需求分类
功能类别
子功能
外部系统管理
外部系统信息管理
外部系统集成配置
用户管理
用户管理控制台
用户自助管理
统一用户管理
组织结构管理
组织结构管理
外部系统组织结构管理
权限管理
授权管理
鉴权管理
集成管理
外部系统集成
7.1.1产品形态
一级节点
二级节点
三级节点
所属子系统
备注
外部系统
外部系统管理
外部系统配置
用户管理
用户信息管理
注册申请管理
组织结构
统一组织结构管理
外部系统组织结构
权限管理
用户组管理
角色管理
角色授权
7.2外部系统管理
外部系统管理用于对使用本系统的外部系统进行统一管理，例如包括外部系统注册、外部系统单点登录配置等，只有经过注册的外部系统才能够使用本系统的相关功能。
7.2.1外部系统注册
提供外部系统基本信息的管理，所有需要使用本系统的外部系统都需要在本系统进行注册。
外部系统对象参考如下：
1.基本类信息
a）外部系统编码
b）作为外部系统的唯一性标识使用
c）外部系统名称
d）可读的文本组成，用于界面显示、用户选择等
e）外部系统描述
f）用于对外部系统进行详细性描述
2.业务类信息
3.此类信息主要用于本系统对外部系统的管控
a）IP地址信息（可选）
b）标识外部系统的服务器地址，本系统将只针对从本地址请求的单点登录进行处理，其他情况将为非法请求
c）SSO标识
d）用于实现单点登录的服务标识，用于实现单点登录流程
4.辅助类信息
5.此类信息没有实际的业务意义，但有助于管理员对外部系统进行管理
a）隶属组织
b）存储外部系统运行维护的组织
c）联系人
d）联系电话
e）可以存在多个
f）地址
g）电子邮件
6.其他信息
a）测试标记位
b）用于指定此外部系统是否是测试用外部系统，如果是，则不会提供实际业务，仅在测试环境下有效
系统提供外部系统的基础增、删、改、查功能，以及导出、导入等功能。
7.2.2外部系统集成配置
外部系统集成配置用于针对外部系统的各种集成功能进行相应的配置，主要分为以下方面：
1.统一用户管理
2.统一组织结构管理
3.单点登录
有关具体内容请参考后面相关部分功能的集成描述。
7.3用户管理
用户管理部分提供统一的用户管理系统。
7.3.1用户管理控制台
7.3.1.1用户信息管理
用户管理控制台功能为本系统的管理员提供，对系统中所有的用户信息进行一体化管理，包括以下功能：
1.用户添加
2.用户信息修改
3.用户删除
4.用户查询、检索
5.用户调动
6.修改用户隶属的组织结构
7.用户禁用
8.用户启用
9.密码重置
10.用户注册申请审批
11.针对通过用户自助服务提交的申请进行审批。
用户对象包括以下属性：
1.基础类信息
a）用户代码
b）用于登录系统使用
c）用户名称
d）用户的可读名称
2.业务类信息
a）用户来源
b）标识用户的来源，可以有两类来源：
被系统注册、外部系统导入
3.辅助类信息
a）性别
b）年龄
c）固定电话
d）移动电话
e）证件类型
f）证件号码
g）联系地址
h）……
4.认证类信息
a）用户密码
b）用于用户登录系统
c）最后登录地址
d）最后登录时间
5.其他信息
7.3.1.2用户申请管理
用户申请管理针对用户通过自助服务提交的用户注册申请进行管理，管理员可以在这里进行申请的审批操作，具体包括：
1.申请查询与显示
2.审批通过
3.审批不通过
7.3.2用户自助服务
用户自助服务是为系统用户提供的快捷服务，具体包括以下功能：
1.用户信息修改
2.用户密码修改
3.用户注册
4.用户提交注册申请后，将由管理员在用户管理控制台中进行申请审批
7.3.3统一用户管理
统一用户管理是指将本系统与所有外部系统的用户信息进行一体化管理。
7.3.3.1用户接口
为实现统一用户管理，本系统需要提供合适的外部访问接口便于实现本系统与外部系统的用户信息交互。
用户交互的操作如下：
1.用户访问接口
2.此接口用于提供外部系统访问本系统内部用户信息的入口
3.支持依据用户代码、名称等信息的过滤条件查询。
4.用户管理接口
5.具有较高权限的外部访问接口，仅会对部分重要的外部系统开放
6.用户信息同步接口
7.在本系统与外部系统之间进行用户信息同步
通信方式：
1.基于中间件的通信
2.基于凯文斯现有中间件产品提供信息通信接口
3.WebService
4.基于WebService技术实现通信接口
7.3.3.2外部系统用户接口
此接口适用于外部系统存在独立的用户管理系统，并且不易将其改造成统一用户管理的情形下，此时本系统为其提供同一用户与外部系统用户的关系管理，同时未提供单点登录也会外部系统登录用户凭证的管理。
外部系统用户接口的组成与用户接口类似，但其中需要对同一用户与外部系统用户中需要提供关系管理。
7.4组织结构管理
本系统将提供两种方式的组织结构管理，分别为：
1.统一组织结构管理
2.独立组织结构管理
最终形成1+N方式的组织结构管理模式。
统一组织结构管理是指本系统与外部系统的组织结构是一体的，系统提供本系统与外部系统之间的组织结构同步；独立组织结构管理是指本系统提供外部系统组织结构的一个映像，对于每个外部系统都提供一个独立的组织结构映像，本系统内一般仅提供查看功能，所有的组织结构修改都由同步接口进行。
对于每个外部系统都需要设置器组织结构管理模式，是统一还是对立。
对于用户与组织结构之间的关系，确定如下：
1.用户与每套组织结构中的关系是独立的
2.用户对于一套组织结构只能够隶属于一个组织
系统中提供两个功能节点用以实现不同的组织结构管理。
1.组织结构管理
2.组织结构管理对应统一组织结构管理，即为管理模式中的1。
3.组织结构为多层不限层级的树状管理模型。
4.外部系统组织结构管理
5.外部系统组织结构管理对应独立组织结构管理，管理模式为首先在所有独立组织结构管理模式的外部系统中选择一个，然后显示其组织结构
组织结构同步接口
两种管理模式下的组织结构同步接口是一致的，不同之处仅仅是在不同外部系统进行同步时，将依据外部系统设定的组织结构管理模式的不同对应本系统中的统一组织结构数据还是独立组织结构数据。
7.5权限管理
本系统的权限管理仅限于本系统内部使用，不需要为外部系统提供统一授权管理。
权限管理系统采用了经典的RBAC权限模型，并在其基础上进行一定的修改。
图612权限管理模型
在当前模型中，具有以下元素：
1.用户
2.用户组
3.角色
4.功能
5.系统中功能包括节点和节点内操作两种具体形式，其中节点是指每一个能够打开的页面，操作是指节点内具体的操作按键（如增加、修改、删除等）
他们之间的关系为：
1.用户与用户组
2.多对一的关系，一个用户只能够属于一个用户组，一个用户组中可以有多个用户。
3.用户组与角色
4.多对多关系
5.角色与功能
6.多对多关系
图613权限管理系统-模块组成
权限管理系统分为三大部分：
1.用户认证管理
2.管理用户认证相关的内容，包括
a）用户管理
b）管理用户信息
c）用户组管理
d）管理用户组信息
e）认证过程
f）实现用户认证流程
3.用户授权管理
4.管理预授权相关的内容，包括
a）角色管理
b）管理角色信息
c）授权管理
d）为角色收取功能权限
e）鉴权过程
f）实现用户权限鉴别过程
5.用户审计
6.记录用户的系统痕迹，包括
a）登录审计
b）记录用户登录系统、登出系统信息
c）操作审计
d）记录用户系统中主要操作的信息
e）审计信息管理
f）查看已记录的用户审计信息，包括登陆审计信息与操作审计信息。
7.5.1统一角色管理
系统可选地提供统一角色管理。
统一角色管理是指在多个系统中进行角色的同步。
用于暂时此方面的需求不是很明确，所以本系统中仅提供单层的角色管理模型。
7.6单点登录
单点登录存在多种实现形式，为了提供更高的兼容性，本系统将以多种方式提供单点登录模式。
7.6.1基于Httpheader单点登录
场景：
用户在不同的应用系统中拥有相同的用户名，通过平台登录后，平台会携带着用户的用户名信息或者信任凭据登录后段的应用系统。
应用系统通过改造获取请求中携带的用户名信息或者信任凭据并直接登录应用系统
1、用户通过平台访问应用
2、用户的请求被平台拦截，并要求认证
3、认证通过后平台将用户信息或者信任凭据放入httpheader中并向后端应用提交
4、后端应用自动解析凭据或用户信息并直接进入登录系统，不需要再次认证
应用系统改造逻辑：
用户登录后，应用先看请求是否存在认证凭据（用户信息或者信任凭据），如果有则读取凭证进行认证逻辑，如果没有则返回登录页面要求重新登录
7.6.2基于表单代填的方式单点登录
场景：
用户在不同的应用系统中有不同的用户名（账号）和密码。
通过统一用户平台和数据同步把这些账号和密码同步到认证平台中的用户映射表中，该表记录了用户和账号的对应关系和密码。
当用户登录通过平台登录后端的应用时，平台将该用户对应得账号名和密码带填并提交实现单点登录。
1.用户通过平台访问应用
2.用户的请求被平台拦截，并要求认证
3.认证通过后平台到映射表中查找用户要访问系统的用户名和密码
4.平台自动提交用户名和密码单点登录应用系统
7.6.3基于CAS单点登录
7.6.3.1CAS组成
从结构体系看，CAS包含两部分：
1.CASServer
CASServer负责完成对用户的认证工作，CASServer需要独立部署，有不止一种CASServer的实现，YaleCASServer和ESUPCASServer都是很不错的选择。
CASServer会处理用户名/密码等凭证（Credentials），它可能会到数据库检索一条用户帐号信息，也可能在XML文件中检索用户密码，对这种方式，CAS均提供一种灵活但统一的接口/实现分离的方式，CAS究竟是用何种认证方式，跟CAS协议是分离的，也就是，这个认证的实现细节可以自己定制和扩展。
2.CASClient
CASClient负责部署在客户端（注意，我是指Web应用）。
原则上，CASClient的部署意味着，当有对本地Web应用的受保护资源的访问请求，并且需要对请求方进行身份认证，Web应用不再接受任何的用户名密码等类似的Credentials，而是重定向到CASServer进行认证。
目前，CASClient支持非常多的客户端，包括Java、Net、ISAPI、Php、Perl、uPortal、Acegi、Ruby、VBScript等客户端，几乎可以这样说，CAS协议能够适合任何语言编写的客户端应用。
7.6.3.2CAS协议
CAS是通过TGT（TicketGrantingTicket）来获取ST（ServiceTicket），通过ST来访问服务，而CAS也有对应TGT，ST的实体，而且他们在保护TGT的方法上虽然有所区别，但是，最终都可以实现这样一个目的——免去多次登录的麻烦。
下面，我们看看CAS的基本协议框架：
图614CAS基本协议框架
上图是一个最基础的CAS协议，CASClient以Filter方式保护Web应用的受保护资源，过滤从客户端过来的每一个Web请求；同时，CASClient会分析HTTP请求中是否包请求ServiceTicket（上图中的Ticket），如果没有，则说明该用户是没有经过认证的；于是，CASClient会重定向用户请求到CASServer（Step2）。
Step3是用户认证过程，如果用户提供了正确的Credentials，CASServer会产生一个随机的ServiceTicket；然后，缓存该Ticket，并且重定向用户到CASClient（附带刚才产生的ServiceTicket，ServiceTicket是不可以伪造的）；最后，Step5和Step6是CASClient和CASServer之间完成了一个对用户的身份核实，用Ticket查到Username，因为Ticket是CASServer产生的，因此，所以CASServer的判断是毋庸置疑的。
该协议完成了一个很简单的任务，就是User打开IE，直接访问helloservice应用，它被立即重定向到CASServer进行认证，User可能感觉到浏览器在helloservcie和casserver之间重定向，但User是看不到，CASClient和CASServer相互间的ServiceTicket核实（Validation）过程。
当CASServer告知CASClient用户ServiceTicket对应确凿身份，CASClient才会对当前Request的用户进行服务。
7.6.3.3CAS实现SSO
当我们的Web时代还处于初级阶段的时候，SSO是通过共享cookies来实现。
比如，下面三个域名要做SSO：
如果通过CAS来集成这三个应用，那么，这三个域名都要做一些域名映射，
因为是同一个域，所以每个站点都能够共享基于的cookies。
这种方法原始，不灵活而且有不少安全隐患，已经被抛弃了。
CAS可以很简单的实现跨域的SSO，因为，单点被控制在CASServer，用户最有价值的TGC-Cookie只是跟CASServer相关，CASServer就只有一个，因此，解决了cookies不能跨域的问题。
回到CAS的基础协议图，当Step3完成之后，CASServer会向User发送一个Ticketgrantingcookie（TGC）给User的浏览器，这个Cookie就类似Kerberos的TGT，下次当用户被Helloservice2重定向到CASServer的时候，CASServer会主动Get到这个TGCcookie，然后做下面的事情：
1.如果User的持有TGC且其还没失效，那么就走基础协议图的Step4，达到了SSO
7.6.4总结
对于使用何种单点登录方式，需要对外部系统进行调研，采用何种方式比较合适。
由于集成环境比较复杂，所以对于不同外部系统可以设计使用何种单点登录方式。
对于表单代填方式进行集成的外部系统，需要针对外部系统提供用户信息映射，具体将在用户管理中提供。
8产品的非功能性需求
8.1.1性能需求
1、系统设计支撑用户数：
员工数*
2、高峰时支持最大主要单功能点并发用户数：
员工数*15%
3、支持同时在线用户数（按照50％估算）：
员工数*50%
4、出现登陆页面时间：
不超过2秒钟
5、输入用户以及口令登陆系统时间：
平均时间不超过5秒钟
8.1.2接口需求
该系统与外界系统系统进行交互的协议必须是业界比较通用的协议。
如ODBC/JDBC，LDAP，XML等。
9附录B：
需求确认
提示：
需求确认规程请参见SPP-PROC-RM，主要分两步：
（1）需求评审，
（2）需求承诺。
对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”，规程请参见SPP-PROC-TR。
在获取责任人（Stakeholders）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。
需求评审报告摘要
需求文档
输入名称，标识符，版本，作者，完成日期，…
需求评审报告
输入名称，标识符，评审日期，…
评审结论
[]工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。
[√]工作成果基本合格，需要作少量的修改，之后通过审核即可。
[]工作成果不合格，需要作比较大的修改，之后必须重新对其评审。
评审意见
评审小组成员
输入评审小组成员
需求承诺
需求文档
输入名称，标识符，版本，作者，完成日期
客户承诺
承诺…
签字，日期
项目经理承诺
承诺…
签字，日期
升级会员 