1.1 项目背景

×××大学是教育部直属、省部共建的普通高等学校，是首批进入国家“211工程”和“985工程”建设的若干所重点大学之一。

×××大学信息化建设开展较早，截至2007年，已建成校级信息应用系统20余个，院级应用系统数不胜数，拥有在职教工和在校全日制学生（约5万）的正式用户，同时还有大量的外聘人员，校友，走读人员等用户群体。

随着学校信息化工作的深入开展，建设了众多的面向教师和学生的服务系统，如数据中心、学术创新平台、目录服务、邮件系统、网络接入系统、管理信息系统等。每一个服务系统都储存了自身的用户信息，包括认证信息（如用户id及口令）、授权信息和用户基本信息（如姓名、身份、所在机构、邮箱地址、联系电话等）。对不同服务系统，用户信息的存储和管理往往没有标准，存储的方式包括数据库、目录或者文件，认证的方式有口令校验、令牌等，授权策略的实现方式也多种多样。

服务系统间用户信息相互孤立引发了大量问题，首先导致服务系统不能建立面向用户的统一视图，相互之间信息共享困难，应用之间难以整合。身份信息需要分别由人工维护，人员信息的新建、调整或调离都需要人工调整各个服务系统的用户数据。其次随着管理复杂性的提高，很难或几乎不可能得到全部人员整体身份信息的全貌，同一用户在不同服务系统的信息之间也出现了冲突，同时也带来一些安全漏洞，如当人员变动时，访问权限不能被及时调整，操作流程中的人为错误也会留下安全漏洞。另外，运行过程中，高昂的维护成本也不容忽视，耗费了大量的人工去操作用户信息变更，并且每次变更用户都往往需要等待很长时间。

据初步统计，学校用户登录次数平均为3次/天。

应用管理员密码重置工作为1次/天。

应用管理员用户管理（创建，角色分配、信息维护）工作时间为3小时/天。

应用独立开发登陆认证模块费用为1000元/应用。

应用独立开发用户角色及权限分配模块费用为5000元/应用。

top

1.2 项目实施内容

建设×××大学统一身份信息库

• 将所有×××大学在职教工和学生信息纳入×××大学LDAP统一身份信息库
• 为×××大学教工和学生身份信息制定schema标准集，规范了数据的完整性和有效性

建立×××大学统一身份管理系统建设

• 实现×××大学用户管理功能，完成×××大学用户身份信息统一的增删改查
• 实现×××大学策略管理功能，完成×××大学9个应用系统在身份管理系统中的策略描述、定义和权限设置
• 实现×××大学角色管理功能，根据部门情况，完成×××大学部分角色描述、定义及与用户的关联关系
• 实现在异构环境下的统一身份管理系统与各应用之间的身份信息同步功能
• 完成×××大学用户审批流程配置，实现部门之间的身份信息管理工作自动流转
• 利用身份管理系统标准接口成功完成校园一卡通、学生数据中心、电子离校单、迎新系统、×××大学办公网等7个应用系统的登录改造，实现单点登录效果

开发一套与应用系统所用技术无关的API，能够满足所有应用接入

• Session资源接口，提供远程操作Session的功能
• Policy资源接口，提供远程操作Policy的功能
• userProfile资源接口，提供远程操作用户属性的功能

开发×××大学信息化网站，实现统一身份认证系统的平台展示

• 利用policy接口完成用户个性化服务展示功能，实现后台权限管理和前台资源显示的完美结合
• 实现×××大学委托授权功能，使教师能对自己拥有的权限进行委托管理

top

1.3 项目建设成效

对于学校,实时掌握在校人员基本情况，使学校准确地统计与分析人员情况成为可能，如学校各类人员比例、人员变动趋向等；通过用户身份的映射，使信息的有效整合与共享成为可能；提高了×××大学校园网络信息安全。

对于部门，减轻各部门/学院在用户信息管理上的投入，同时保留原有系统的权限管理权力

对于用户，满足用户对不同安全级别应用的需要，提供相应的身份识别方式。如用户名/密码、数字签名、数字证书、智能卡；满足用户在不同部门办理不同业务时只需一个账号和密码的需求，同时账号可以个性化；满足某些用户应公务繁忙，可以方便地将事务委托他人办理的需要，不会因此带来权限上的滥用；满足用户个性化服务定制要求，针对不同用户显示不同的应用列表。

对于应用提供商，使用标准的登录认证服务模型，减少了用户登录模块开发工作量，加快了应用开发速度。

top