校园统一身份认证平台建设方案.docx
《校园统一身份认证平台建设方案.docx》由会员分享，可在线阅读，更多相关《校园统一身份认证平台建设方案.docx（22页珍藏版）》请在冰豆网上搜索。
校园统一身份认证平台建设方案
校园统一身份认证平台
建设方案
1.项目概述
1.1.项目名称
项目名称：
校园统一身份认证平台
1.2.项目背景
建设以目录服务和认证服务为基础的统一用户管理、授权管理和身份认证体系，将组织信息、用户信息统一存储，进行分级授权和集中身份认证，规范应用系统的用户认证方式。
提高应用系统的安全性和用户使用的方便性，实现全部应用的单点登录。
在学校工作人员进行了调动、调级、调职等变更后，或者学校体制改革、组织机构变动后，使用户的身份和权限在各系统之间协调同步，减少应用系统的开发和维护成本。
1.3.建设依据
本项目软件系统设计和建设严格遵循国家及地方标准规范，以及工信部相关的规范与标准，具体如下：
网络标准：
IEEE802.3，IEEE802.3u，IEEE802.3ab，ANSI/IEEE802.3N，IEEE802.3x，IEEE802.3af，IEEE802.3az,IEEE802.11b/g
1）《信息安全等级保护管理办法》（公通字〔2007〕43号）
2）《信息系统安全等级保护测评要求》GB/T28448
3）《政务信息资源交换体系》（GB/T21062-2007）
4）《计算机软件开发规范》（GB8566-88）
5）《计算机软件产品开发文件编制指南》（GB8567-88）
6）《软件工程术语》（GB/T11457—89）
7）《计算机软件配置管理计划规范》（GB/T12260-90）
8）《计算机软件质量保证计划规范》（GB/T12504-90）
9）《计算机软件需求说明编制指南》（GB9385-88）
10）《计算机软件测试文件编制指南》（GB9386-88）
11）《软件维护指南》（GB/T14079-93）
12）《计算机软件可靠性和可维护性管理》（GB/T14394-93）
13）《大学信息标准与规范国家及教育部代码集》
14）《大学信息标准与规范校内自编代码集》
15）《大学信息标准与规范信息系统建设规范》
2.总体设计
2.1.总体目标
采用信息化手段，通过计算机应用软件、3G/4G无线网络技术建设校园统一身份认证平台。
1、从学校全局观点出发，管理学校的所有用户、角色，以及所有的数据资源。
2、为校园网的用户提供网上身份认证和信任服务。
为校园网的通信建立信任关系，保证身份的真实性，为信息的保密性、完整性以及交易的不可抵赖性提供全面的服务。
其宗旨是保证校园网提供的服务和享受服务的用户实现安全交互，并为校园网的用户提供网上身份认证和信任服务。
3、稳定可靠的统一身份管理：
建立全校信息系统统一的集中身份库，该身份库将包含管理信息系统所有用户资料信息，人员信息的日常更新、人员的登录认证等活动将全部基于该身份库的基础之上进行操作。
用户和权限完全由内部自主管理。
区别于其他公共身份认证中心，完全享有组织内部信息的保密性和独立性，管理方便，安全可靠，不受第三方控制。
完全基于WEB界面，加密传输，无需专用客户端，随时随地可进行管理，方便安全。
用户信息采取实名制。
用户不能自己进行帐号注册，管理员基于用户实际身份和基本信息建立帐号，用户帐号独立且唯一。
用户名的统一管理和权限分配的灵活性。
系统管理员可对用户进行统一管理，主系统中用户删除或禁用后，其他各子系统中该用户信息自动删除或禁用；而各个子系统权限控制完全独立，同一用户，在不同的系统中可以具有完全不同的身份，各子系统用户权限可独立管理，对一个子系统中权限的修改，与其他子系统完全无关联，保证各子系统独立、安全、可靠。
身份数据的处理方式除了新生入学、新教师报道的身份创建，还包括学生离校、教师离职的身份类别变化的同步处理和权限模型的建立，为学校各类用户提供注册、变更、转化、注销的全生命周期的身份数据管理方案。
支持用户多重身份属性的定义和存储，符合学校教工多重身份、多重职务的现状。
分布式数据采集机制，符合学校数据源分散管理的特点。
系统应具有良好的稳定性和可集成性。
支持对不同开发平台、不同开发模式的应用系统的认证集成，提供多种成熟认证接口，实现对网络层服务的集成，支持Unix、Linux、Windows多种平台，完全支持跨平台部署。
4、先进的技术和安全策略：
充分利用各种安全、认证技术来实现整个系统平台的安全性，同时各种认证技术可以灵活选择，比如：
可使用用户名/密码、校园卡/密码、数字证书、支持与其他CA认证系统建立交叉认证机制，实现有效集成。
通过整体部署的安全机制、日志审核和访问策略等多种控制手段保证平台高度安全。
对用户的操作行为进行日志记录，以追溯用户的行为过失，确保数据安全。
为了保证敏感信息的安全性，需要对学生成绩、用户登录密码等信息在传输过程和存储方面进行不同程度的加密处理。
针对办公系统中的审批等功能需要数字签名。
系统需要提供数字签名和签名认证等功能来保证网上办公的可靠性和安全性。
5、具有单点登录功能。
用户只需要登录（认证）一次，就可以访问许可范围内的所有数字化校园应用系统，为用户去除不停输入密码的烦恼，也避免了用户密码过多导致密码遗忘或遗失而带来的麻烦。
6、具有密码恢复功能。
用户不慎遗失密码时，可以自己通过该功能，输入详细的个人信息及密码提示答案恢复密码。
大大降低系统管理员的负担。
7、采用灵活的基于角色的权限管理模型。
8、可定制不同粗细粒度的访问控制策略。
2.2.设计原则
根据系统特点和要求，在“先进性、实用性、标准化、开放性、整体性、共享性、安全性、保密性、可靠性、经济性、可扩展性、可维护性”等十二个方面提出原则性要求如下：
（1）先进性
系统采用国际先进的软件体系结构，先进的技术标准，保证系统的生命力。
系统的建设应以“高起点、高标准”严格要求，在系统设计上，首先应当具有前瞻性。
（2）实用性
系统结合实际的业务处理流程以及业务管理工作流程，设计结构合理、功能实用、符合实际业务需要的系统。
系统的设计在运行环境、使用操作等方面以实用为主，以方便使用和维护为出发点。
（3）标准化
系统建设采用的软件平台、数据标准、开发技术应符合公认的标准，符合国家、地方的有关标准与规范。
采用标准的数据描述语言以及标准的通信协议，适应以后的数据交换标准以及系统间互连的标准协议等。
（4）开放性
软件体系结构上，应充分考虑系统的开放性。
以模块化设计和基于组件的多层结构体系保证系统的开放性和灵活性。
（5）整体性
系统建设需进行整体的规划完善，通过科学的分布实施，建立全面覆盖业务，符合要求的系统。
系统建设具有整体性，即内容上全包括、数据上全部共享、流程上相互衔接、管理上协调统一。
（6）共享性
系统通过搭建共享平台接口进行数据共享，同时，系统提取和分析的信息库也能以标准的数据接口开放给其他部门使用，打破部门壁垒、信息孤岛，为业务管理提供有力的依据和手段。
（7）安全性
从身份验证到资源授权访问再到数据的安全性。
系统应能提供网络层和应用层的安全手段，防止系统外部成员的非法侵入以及操作人员的越级操作，从多个角度、环节考虑，确保系统和数据的安全。
（8）保密性
系统在权限功能规划上要考虑全责明晰，建立合理的可分配权限，使内容、功能管理有效、有序，减少人为的操作风险。
系统的访问和操作具备可回溯性，操作人员进行了哪些操作都有记录可查。
（9）可靠性
本系统为多部门使用的系统，系统需健壮、无故障运行周期长，应具有较高的性能可靠性。
（10）经济性
系统在规划和实施过程中，必须立足于现状，着眼于未来，遵循“统筹规划、分布实施、整合资源”的原则，避免系统的重复建设以及资源浪费。
（11）可扩展性
系统可以根据实际情况进行灵活的配置和组合，能方便地进行功能的调整以及系统的升级、扩展，以适应业务的不断发展和更新。
（12）可维护性
将应用与技术分离，建设方维护人员可自行维护本系统，如人员岗位的调整、工作流程的变化等，不需要对软件本身进行任何重新编码，通过维护模块的调整即可实现。
2.3.总体架构
系统主要由“1个规范、1个数据库、1个系统”构成。
“一个规范”即数据标准规范，根据管理要求，基于国家、省、市相关技术标准规范编制一套适应管理建设要求和实际情况的标准规范体系；
“一个数据库”即“人员基础信息资源库”，作为整个项目的基础数据支撑；
“一个系统”面向身份认证服务工作，实现校园统一身份认证平台，主要包括：
用户管理、权限管理、角色管理、单点登录等。
总体架构主要包括感知层、网络层、数据层、服务层、平台层、应用层、政策法规、安全标准等层面。
项目建设基于信息标准，实现信息数据的集中部署，要做到以下五个方面的统一:
●统一数据标准（数据系统架构、数据库结构、数据表）；
●统一基础信息（文字、图片、音视频、虚拟素材等）；
●统一地理信息（位置信息、GPS数据、电子地图）；
●统一交换接口（内部数据交换接口规范、开放数据接口规范）；
●统一技术平台（硬件、软件、网络、安全）。
感知层：
通过各类数据采集和感知技术，如：
RFID、条形码、传感器、摄像头等，实现数据采集和存储，为整个系统治理应用体系提供基础数据的支撑；
网络层：
构建应用级物联、感知、互联、通信、卫星网络，为数据信息的传输流通起到支撑作用；
数据层：
系统业务处理的逻辑平台，它通过对数据核心层的调用访问业务数据，实现不同的功能模块，满足不同的业务需求；所有业务功能在此统一平台上得到良好的封装和定义，以Web、手机终端服务的形式，运作在平台上，为用户提供各类信息服务；
应用层：
对于应用层，提供多样化的界面逻辑，实现对业务逻辑的应用。
2.4.应用架构
1.采用B/S多层体系结构：
系统需要采用B/S多层体系结构实现。
三层结构包括表示层、业务逻辑层、数据访问层；
2.采用面向服务的架构（SOA）：
为了降低服务架构模块之间的耦合度，增强系统的可扩展性；需要采用面向服务的构架（SOA），各个功能模块分别提供不同的服务，通过服务总线集成为用户提供一体化的服务；
3.基于J2EE体系：
为了保证系统的兼容性，高可用性、高可靠性和可扩展性，系统必须沿用前期项目的技术路线，要选择支持强大的企业级计算的成熟的J2EE企业标准；
4.基于Web服务（WebService）：
为了让地理上分布在不同区域的计算机和设备一起工作，以便为用户提供各种各样的服务。
用户可以控制要获取信息的内容、时间、方式，而不必像现在这样在无数个信息孤岛中浏览，去寻找自己所需要的信息，系统对外接口统一需要采用WebService服务的方式定义；
5.采取XML数据交换：
系统的外部接口需要采用XML数据交换格式，用XML作为数据定义和交换的中介。
2.5.数据库设计
2.5.1.历史数据库设计
历史数据库用来存储实时数据库的历史数据。
实时数据库中只有各种设备的当前值（状态），而以前的实时数据要存储在历史数据库中，以备日后查询。
为了可以精确获取每个数据采集仪的任何时候状态，历史数据库中要保存所有节点的全部采样数据。
历史数据库系统采用大型商用关系型数据库。
历史数据库系统是整个应用程序的数据层。
它为各种客户提供所需要的历史数据。
历史数据库系统采用双机备用方式。
历史数据服务库系统的功能包括：
采样历史数据的存储；计算各种分析所需的统计数据；记录变位、SOE等随机性数据；记录用户对应用程序的操作的日信息；存储用户权限等安全信息；提供Web发布所需的各种历史数据。
历史数据库系统的数据源由实时数据库系统提供，在实时数据库系统中，已经对数据质量、数据一致性、完整性作了处理，因此由实时数据库系统提供给历史数据库系统的数据均为有效数据。
实时数据库系统负责定时的将有效数据送给历史数据库系统的代理程序，随机数据在产生的时候送给代理程序，代理程序负责将数据写入历史库中。
同时代理程序负责定时对采样数据进行统计、计算并将结果存入数据库中。
历史数据系统示意图
2.5.2.历史数据
由实时数据库提供的采样数据存储在历史数据库中。
这些数据按类别、时间存储在数据库不同的历史表中。
I数据表命名规则
历史数据表名称按照一定的命名规则：
类型名称+时间。
如：
2001年7月10日的模拟量采样数据表应命名为SmpAna20010710，这张表将存储这一天的所有的模拟量采样数据。
以上设计主要基于对采样数据的查询方式，主要是要某一个量在某一段具体时间内的数据。
数据不存放在一个数据表中，可以大减少检索的次数。
当检索一个数据的时候，是先从系统数据表中检索出这张表的位置，然后定位这张表，再检索需要的数据。
而不必从一个大表中反复的检索、查找和定位。
这种检索方式也近似于字典查找的算法理论。
对于计算、统计数据也采用近似的处理方式。
II数据表索引（Index）
数据库的索引是一个B型树的数据结构。
当写入一记录时，数据库会对记录产生一个索引值，并在系统索引表（Sysindexes）中产生一条索引记录。
在检索一条记录时，从树的根节点到树叶的搜索方式进行，从而对有索引的记录加快检索速度。
但同时也降低了写入的速度。
对于采样数据，主要是记录值，因此可以考虑用没索引的表来表示。
III数据压缩存储
采样数据可能是一些不断重复的量。
重复记录会加大存储的空间和记录的行数。
因此可考虑数据变化时才存储，记录一个状态（值），并记录这个状态（值）重复的次数。
也就是：
数值—变化的压缩方式。
具体设计如下例：
如有一个模拟量，前一次的值如果和本次的值相同，则在记录中的次数计数器加1，否则添加一条记录。
2.5.3.统计数据
历史数据的存储方式同样是将数据按类分散在不同的表中，表要具有统一的命名规则。
数据统计是将各种采样数据计算生成所需要的一些统计数据。
数据统计与采样数据记录是同步进行的。
也就是说，当从实时数据库中取得采样数据并写入到采样记录表中的时候，就会触发一系列的统计和计算工作。
有一系列的中间结果产生出来，当在时间上满足要求的时候，就会将这个中间结果记录到相应的统计数据表中。
统计计算工作用ORACLE的触发器（Trigger）来完成，当采样数据更新时，会触发一系列的事件产生，事件驱动一系列的处理程序来处理是否写入数据库，更新统计数据的中间结果等。
这项工作在ORACLE后台为处理，使用大量的存储过程来加以实现。
2.5.4.临时表
临时表具有与普通表完全一样的属性，所不同的是它存储在Tempdb中而不放在当前数据库中，当用户连接并创建使用时它存在，当用户断开后临时表也会自动删除。
全局性临时表（以##开头作为标识）：
会各所有连接到数据库的用户开放，每一个用户均可以访问，只有当所有的用户都断开后，全局性临时表才会自动删除。
临时表的设计主要是为了考虑提高对报表、查询速度的要求。
通过组态的报表或定制的某个查询，是对固定的一些参数进行数据检索，这些量使用的频率最高。
考虑减少在无关的数据堆中检索的次数，因此想把这些用户最关心的数据量的记录放在一个专门的地方。
由于数据源的记录本来已在数据库中存在，而同样的数据在数据库中不应该重复，所以考虑将这样的数据放在临时表中，且为全局性临时表，为所有的数据连接用户开放。
临时表中的记录是最近一个时间段的数据和最近使用过的数据。
处理临时表中记录的算法应是先进先出的原则和最久不使用原则。
新数据将最老的数据并且最久没有使用过的数据覆盖。
临时表中的数据始终保持最新和最新使用过的数据。
这些数据也是用户使用频率最高的数据，这样可以提高报表、查询的检索数据速度。
2.5.5.数据冗余处理
数据冗余采用磁盘阵列的方式来实现。
数据冗余示意图
2.5.6.数据库安全
数据库安全性问题一直是系统安全的关键。
数据库安全性问题应包括两个部分：
（1）数据库数据的安全
它应能确保当数据库系统DownTime时，当数据库数据存储媒体被破坏时以及当数据库用户误操作时，数据库数据信息不至于丢失。
数据安全的解决，主要有系统双机热备份、数据库的备份和恢复等办法，本系统的数据安全，纳入信息中心的系统安全体系，共享一些硬件设施，实现数据的备份等。
（2）用户角色的管理：
这是保护数据库系统安全的重要手段之一。
它通过建立不同的用户组和用户口令验证，可以有效地防止非法的Oracle用户进入数据库系统，造成不必要的麻烦和损坏；另外在Oracle数据库中，可以通过授权来对Oracle用户的操作进行限制，即允许一些用户可以对Oracle服务器进行访问，也就是说对整个数据库具有读写的权利，而大多数用户只能在同组内进行读写或对整个数据库只具有读的权利。
在此，特别强调对SYS和SYSTEM两个特殊账户的保密管理。
为了保护Oracle服务器的安全，应保证$ORACLE_HOME/bin目录下的所有内容的所有权为Oracle用户所有。
为了加强数据库在网络中的安全性，对于远程用户，应使用加密方式通过密码来访问数据库，加强网络上的DBA权限控制，如拒绝远程的DBA访问等。
2.6.性能设计
2.6.1.标准化
符合LDAPv3版本标准，采用基于LDAP标准的目录服务器存储身份数据。
2.6.2.传输安全性
要求系统对用户登录信息进行加密传输，保证数据能在客户端与单点登录服务器之间、WEB代理与单点登录服务器之间进行安全通信，保证数据传输的安全性，采用的加密技术可不可逆。
2.6.3.数据安全性
用户登录票据需要被加密保护，支持扩展SSHA、CRYPT、SHA、RC4等多种密码加密算法，并可以快速扩展用户属性信息，保证用户登录票据不能被篡改。
在统一身份认证系统中，目录服务和认证系统是管理信息系统所有业务应用系统的基础，安全性是一个非常重要的一个考虑，在整个基于管理信息系统集中身份库的基础上，充分利用操作系统Unix/Linux等的认证系统和DirectoryServer目录服务器所提供的PKI技术、CA认证技术、PIN+智能卡等技术来实现整个系统平台的安全性，同时各种认证技术可以灵活选择。
此外，DirectoryServer目录服务器还拥有完善的ACL（ACI）体系，能够充分保障数据的访问安全。
2.6.4.跨平台部署
支持Unix（AIX、HPUnixScoUnix等主流Unix）、Linux、Windows等多种操作系统，实现完全的跨平台部署。
2.6.5.高可靠性
采用合适的保护策略，保证系统的可靠性，提供数据定时、异地冗余备份功能。
在统一身份认证系统中，保障系统具有良好的伸缩性是对学校数字化校园信息系统一个前瞻性的考虑，利用DirectoryServer目录服务器系统提供的集群、复制、分区特性可充分保障系统具有非常好的伸缩性。
2.6.6.系统容错性
由于此平台是整个数字校园工程建设的基础平台，系统具备高度的容错性，保证系统的正常运行。
遇故障具有自动重启功能，保证正常的服务不受影响和少受影响。
2.6.7.可审计性
对用户进行资源访问情况进行记录，方便过程跟踪。
2.6.8.接口开放
开放的认证接口，支持不同开发语言（Java、.net、ASP、PHP、c/c++、COM、Radius等接口）、不同应用服务器平台实现的应用系统的认证集成方式，提供WebService、API等方式。
2.6.9.认证接口规范
支持不同开发语言、不同应用服务器平台实现的应用系统的认证集成方式（Java、.net、ASP、PHP等），包括WebService、API等方式，并开放相应接口。
认证集成包含以下几种模式：
URL单点漫游模式CA认证模式OAuth2.0协议认证RestFulAPI认证SAML2.0协议认证
3.系统设计
3.1.用户目录管理
用户目录管理是为了方便用户访问组织机构内所有的授权资源和服务，简化用户管理，基于LDAP（LightweightDirectoryAccessProtocol轻型目录访问协议）或基于数据库，对组织机构内中所有应用实行统一的用户信息的存储、认证和管理。
统一用户目录管理遵循以下两个基本原则：
1）统一性原则：
实现对目前已知用户类型进行统一管理；对门户的用户体系和各应用系统独立的用户体系进行管理。
2）可扩充性原则：
能够适应对将来扩充子系统的用户进行管理。
3.2.用户身份管理
实现用户信息的集中存储和管理，用户信息规范命名、统一存储，用户ID全局唯一，并提供标准接口，实现不同应用系统的用户身份的同步，支持海量的基于LDAP目录服务器的用户数据存储和管理功能。
3.2.1.角色管理
统一身份认证平台中可以定义用户角色，用户角色直接决定了该用户可以享有哪些服务。
用户和角色之间的关系是不断维护的，每种角色都有各自的权限定义，如果一个用户被赋予一个角色之后，那么这个用户就拥有了那个角色所定义的权限；当这个角色的权限定义更改之后，所有被赋予这个角色的用户也会自动拥有这个角色更改之后的权限。
所有的权限定义都需要针对数量非常有限的角色，而不必针对数目巨大的一般用户，从而显著地减少了系统管理人员对用户访问权限维护的工作量。
可灵活定义角色之间的继承、相容和互斥关系，授权简单、便捷，并可以通过定义角色之间继承、相容、相斥等关系有效控制资源的继承性或阻止资源权限继承性，可以满足各种复杂的需求。
角色管理的功能包括：
角色管理：
新增角色：
增加系统角色；
修改角色：
修改角色属性；
删除角色：
删除系统角色
查询角色：
按照角色属性查询角色或角色组的信息；
查看用户：
查看某个角色下包含的用户
功能授权：
给当前角色授予/取消访问功能模块的权限；
数据授权：
给当前角色授予/取消访问资源的数据范围，主要体现于用户管理、应用管理和二级授权；
分配用户：
可以给角色分配一批用户，赋予这些用户有当前角色所拥有的权限；
分配应用：
给当前角色授予/取消访问应用的权限
3.2.2.用户管理
将所有的用户都挂靠在组织树的某个节点下，便于用户信息的维护。
用户管理主要为系统管理员提供一个统一的用户管理操作界面，通过该模块进行的用户操作，将通过用户同步服务实时同步到各个系统中去，达到统一用户管理的目的。
为满足学校大量用户维护的需求，系统提供批量操作（导入、导出、迁移）功能，数据格式包括EXCEL、DBF、TXT等。
用户基本信息包括登陆账号、登陆密码、姓（拼音）、名（拼音）、姓名（中文）、电子邮箱、性别，办公电话（含分机）、办公传真、家庭电话、手机、所在部门，其它部门、职务、备注等等。
其中除办公传真、家庭电话、手机、其它部门、备注外，其他信息均为必要信息。
用户管理提供的功能有：
新增用户：
主要分成二部分，一类是教工职员类用户的新增，一类是学生类用户的新增。
其中教工职员类用户由注册教职员工的管理员负责注册，学生类用户通过系统自行注册，其资料等由学生自己填写。
修改用户：
修改用户注册时填写的基本信息。
除用户名信息不可修改以外，其他信息均可修改。
删除用户：
删除用户信息，对于该用户赋予其他用户的授权功能具有一并撤销和保留两种选择；
查询用户：
包括用户信息简单查询、模糊查询，查询条件可以是用户的任何属性信息；
用户信息自动同步管理：
提供用户信息自动同步接口，将统一用户信息（用户登录名、用户中文名、密码）以及应用系统用户信息（用户登录名、密码）传送给应用系统，提供统一的用户登录访问机制；
用户冻结、解冻：
在用户有效期内将用户的所有权限暂时失效，解冻则相反．
属性设置：
赋予某用户在某应用系统下的一系列属性；
用户查看：
可查看用户的账号信息（包括账号、是否绑定手机、邮箱、QQ、微信等）、详细信息（涵盖学生、教职工基本信息及详细信息）、所属角色、授权应用、功能权限；
密码初始化：
可按照指定规则、指定用户范围初始化用户密码
启用/停用账号策略：
按照用户范围或选中用户设置账号有效期，过期后便不可访
升级会员 