中小学智慧校园软件解决方案技术白皮书.docx
《中小学智慧校园软件解决方案技术白皮书.docx》由会员分享，可在线阅读，更多相关《中小学智慧校园软件解决方案技术白皮书.docx（62页珍藏版）》请在冰点文库上搜索。
中小学智慧校园软件解决方案技术白皮书
智慧校园软件解决方案
白
皮
书
1.总体框架
亿阳信通智慧校园总体框架如图所示：
该框架以“师生”为核心，围绕智慧校园的资源、管理和服务三要素，依托数据中心及应用支撑平台，重点建设校园资源中心、校园管理中心、校园服务中心应用系统，形成数字化的教学环境、科研环境和生活环境。
2.技术路线
智慧校园应用系统应采用成熟先进的技术规范，设计上尽量减少各子系统间的相互依赖性（包括软件对平台、软件对数据、软件对软件、平台对平台等），某个子系统的减少、增加和变更，不影响其它子系统和整体，从而最大限度地保护既有投资，减少系统的维护量和再投入。
在应用系统整体化、模块化和规模化的同时，保证应用系统在技术上、经济上的可持续发展。
亿阳信通智慧校园软件系统遵循如下技术路线：
1、采用“跨平台”的编程语言。
2、采用独立于开发环境的面向对象的组件技术，如EJBs（EnterpriseJavaBeans），整个系统的主要“应用逻辑”由组件构成，系统架构提供了良好的伸缩性，使系统能够轻易地组合与拆分各功能模块。
3、应用软件平台的开发及运行架构采用三层结构，即Web服务器、应用服务器和数据库服务器，在不影响系统其它部分的情况下，保证了应用服务器与其它应用有效和无缝的整合，同时支持大规模的并发用户访问。
4、采用模版（Template）技术生成动态网页，为用户提供基于角色和权限的内容和数据服务。
架构实现采用Java语言和EJBs技术，在数据交换上支持XML，使系统功能最优化，同时将系统内部的相互依赖性减至最低。
2.1.编程语言
遵循J2EE（Java2EnterpriseEdition）规范，采用Java语言和服务器端Java技术（包括EJBs、Servlet、JNDI、JDBC和RMI等）开发系统。
Java作为Web应用的事实标准，其独立于操作系统和服务器的“跨平台性”，使其“一次编写，到处运行”，是WEB软件系统最适合的编程语言。
相对于嵌入HTML、受限于用户端显示、编程能力有限的脚本语言，Java能力完整，可以开发具有强大“业务逻辑”的大型应用系统。
2.2.面向对象的组件技术
软件编程由依赖于特定单机，到依赖于操作系统，已发展到今天面向对象的组件技术。
面向对象的组件技术是一种完全独立于硬件和操作系统的开发环境，着重于应用程序“业务对象”的可重复使用组件，利用这些组件，可以像搭积木一样的建立分布式应用系统。
面向对象的组件技术在异构、分布环境下为不同机器上的应用提供了互操作性，并无缝地集成了多种对象系统；另一方面，组件大大加快了软件开发的速度，降低了软件开发和再开发的成本。
2.3.应用程序的开发与运行结构
开发及运行结构基于三层架构，即Web服务器、应用服务器和数据库服务器。
运用这种架构可以：
（1）将“业务逻辑”从Web服务器中分出，在应用服务器中用独立和完整的编程语言而不是“脚本语言”开发应用程序，同时使系统支持任何HTML的显示工具；
（2）应用服务器可以作为数据库访问请求的“缓冲区”，可以重新安排、管理数据库访问。
通过JavaServlets引擎的多线程处理，能够极大地提高系统响应性能和数据库访问效率；
（3）应用服务器可以作为与其它应用程序集成的结合点，在不影响系统其它部分的情况下与其它应用有效、无缝集成。
2.4.动态网页生成技术
信息发布采用基于模版的动态网页生成技术。
用户界面的版面和显示效果由预先制作的模版实现，并支持任何标准化的HTML工具，嵌入模版的Java程序根据用户的角色和权限提取相应的内容和数据，配合模版自动合成针对用户的个性化的动态网页。
3.信息标准和规范系统
信息标准是智慧校园建设的重心，是学校各信息系统进行数据采集、处理、交换、传输的前提，也是构建新应用需要遵循的标准。
亿阳信通按以下原则建设智慧校园的信息标准：
●唯一性：
标准采用树形体系结构，唯一的项、唯一的路径、唯一的编码。
●规范性：
充分参照国家相关最新标准、教育部《教育管理信息化标准》、北京市教委相关标准和各区县教委相关标准。
●适用性：
标准的制定充分考虑学校的实际情况，以应用为目标。
●兼容性：
对标准实行版本化的维护管理。
高版本兼容低版本。
同一个版本，维护其不同内容的一致性。
学校校内标准兼容教育部及其它管理部门的标准，方便数据上报。
●可管理性：
系统提供数据标准集、数据代码集、自定义代码集、数据代码映射等提供B/S架构的可视化管理工具，具备初始化、新增、删除、修改等维护功能，支持分类检索、输出、数据展示等浏览功能。
●可扩展性：
支持标准的增加和变更，具有维护记录和回溯功能，并且对应用该标准的业务系统透明。
所有历史版本可查询，可比较差异。
管理信息标准的体系结构包括以下几个方面：
一组相关数据元的集合，对数据元属性的规范描述（又称之为元数据标准化），属性包含了数据项名称、中文简称、类型、长度、可选性、取值范围等。
为了确保数据录入规范、便于查找和统计，每个管理子集都对应着相应的标准代码，代码分国家标准、行业标准和学校标准。
系统遵循国家教育管理信息系统互操作规范，能够与北京市教委制定的小学应用互操作框架（简称CIF）无缝对接，实现各业务系统间规范的数据共享。
CIF实现规范也定义了基于XML标准的CIF数据模型，支持小学数据对象在应用系统间的共享。
“教师”和“学生”是智慧校园系统涉及的两大数据对象，业务数据实体主要由这两大对象映射产生。
通过“教师”对象产生的数据实体主要有教案、作业、教学成绩、教学计划等一系列和教师教育教学活动相关的数据；通过“学生”对象产生的数据实体主要有考试成绩、课堂表现、获奖、毕业去向等一系列和学生学习成长相关的数据。
这些数据存储在智慧校园的数据中心，通过综合统计分析，又产生大量的衍生数据，如教师分布情况、学生分布情况、考试成绩综合统计分析等，这些数据可以为学校的管理层提供微观和宏观的决策支持，使领导能够直观的了解各个部门乃至整个学校的运行状况。
具体数据模型框架如下图所示：
4.基础支撑平台
4.1.统一身份认证系统
应用系统如果采用各自独立的身份认证机制，用户就要记忆不同系统中的账号/密码。
为方便师生使用，解决多应用带来的多账号问题，需要建立统一的身份管理平台，用户在平台上登录一次就可以访问所有具有权限的应用。
统一身份认证以IDM/IM（身份认证管理）为基础提供安全的用户身份管理功能，并配合AccessManager基于代理架构的访问控制，提供Web应用的单点登录和Web应用保护。
IDM/IM都集成了DirectoryServer（LDAP）目录服务器来存储统一身份库信息。
统一身份认证实现的功能如下：
1.建立统一的集中身份库——统一身份数据中心，对各应用系统的所有用户提供集中和统一的管理，同时根据各个业务应用系统的认证方式的不同提供灵活的认证机制；
2.在集中身份库的基础上，在满足数字校园管理平台信息系统内部业务流程规则的前提下，通过身份管理技术实现身份库与各个业务应用系统（门户、OA、教学、教务等系统）用户身份信息的自动同步处理功能；
3.在集中身份库的基础上，提供单点登录（SSO）功能，用户只需要通过一次身份认证就可以访问具有权限的所有资源。
集中身份库与门户系统的统一可以为整个平台提供集中的管理、安全机制，实现整体的统一。
1.
2.
3.
4.
4.1.
4.1.1.设计要点
●支持用户数据的集成，适应中小学用户数据分散管理的现状
●支持用户数据存储模式，适应中小学教职工多重身份的现状
●支持多种认证方式，确保异构业务系统能够集成，让用户获得完整的单点登录体验
●满足不同用户或系统的认证安全需求
●保证身份认证平台的高可靠性和高性能
前三个需求是身份认证平台发挥作用的基础，而随着应用集成的力度和广度的加大，后两个将是身份认证平台必须妥善处理的问题。
校园应用功能多样、结构复杂，各应用系统的权限管理基本上采用分级授权的方式。
身份认证平台可以采用统一的权限模型，供各应用系统使用，相应的权限数据既可集中管理也可分布式管理。
从实践结果看，集中权限控制的效益并不明显，建议不强求集中控制，由各应用系统设计开发时按需选择。
4.1.2.系统框架
身份认证平台主要包括以下三方面功能：
●LDAP目录服务，支持海量用户数据的存储和管理
●高性能SSO（单点登录）身份认证服务
●开放的认证集成方式，支持不同开发语言和不同应用服务器平台的业务系统
4.1.2.1.统一身份管理架构
学校的各种应用系统通常都有自己独立的用户管理、用户认证和授权机制，导致系统间互不兼容；学校的组织机构也不断变化，用户来源日趋复杂，角色多样化和角色变化等问题不断出现。
各方因素交织在一起形成了一个庞大的矩阵，为统一的身份管理带来了困难。
如图：
针对上述问题，建立一个统一的，基于业界标准（如LDAP，XML，WebService，J2EE等）的，灵活、开放、可扩展性的身份管理框架是最终的解决方案。
一个好的身份管理解决方案将复杂的身份管理问题变得简单、实用。
身份认证平台核心结构如下图所示：
身份认证平台管理用户在各个应用系统中的用户信息的对应关系，并根据这一关系管理用户在各个应用系统中的生命周期，如添加、删除、修改等。
身份认证平台的身份同步工具可以自动发现某个应用系统中用户信息的变化并通过一定规则，保持和其它应用中的用户信息同步。
身份认证平台的核心包括用户信息创建和中止的审批流程，该流程由管理员预先定义，可以修改。
当用户帐户的申请被批准后，用户帐户将根据预先定义的规则在中央主目录服务器中创建，并通过资源适配器在各个该用户可以使用的应用系统中产生帐户信息。
用户帐号的中止也是同样原理。
身份认证平台具有口令管理功能，支持口令策略管理和口令历史记录，支持用户身份审计和用户帐户风险分析，支持用户身份管理系统运行的监测、评估。
4.1.2.2.用户数据模型
身份认证平台中的数据模型包括：
1.用户帐号：
学生、教职员工、合作伙伴、供应商等帐户信息；
2.资源：
身份认证平台所管理的身份数据源和应用系统，如学生数据中心、教职工数据中心、电子邮件、一卡通、综合网络管理系统以及上网认证系统、VPN系统等，以及其它基于用户属性更改的应用；
3.资源组：
按一定顺序组织的资源，身份认证平台将根据这一顺序在应用系统中创建和删除用户信息；
4.组织：
管理一组用户、资源和其它对象的逻辑容器；
5.角色：
用户的工作角色，代表其职能性质，据此在资源中设置用户的属性；
6.管理帐户：
具有管理员权限，可以进行分级管理；
7.能力：
拥有哪些权限，如口令管理员只能管理用户的口令。
下图为数据模型图：
身份认证平台：
1.管理用户访问一个或多个资源的权限；
2.管理用户在这些资源上的帐户数据；
3.赋予用户一个或多个角色，设置用户访问各种资源的权限；
4.管理组织，决定用户帐户由谁和怎样被管理。
用户数据是动态的，依赖于用户的角色、资源和资源组。
根据角色（可以是多角色）赋予的资源的数量和类型，需要不同的信息表示，也决定着创建用户时的信息数量。
身份认证平台有虚拟用户的概念，主要作用是映射用户到多个资源，可以将一个用户在多个应用系统中的全部帐户信息作为一个实体来管理。
4.1.2.3.用户数据管理
身份认证系统需要提供多样化的用户数据管理方案。
用户数据采集可以根据学校现状，采用以下方式：
1、集成管理着权威用户数据的业务系统，依赖该系统进行用户数据管理
2、通过数据集成平台双向同步用户数据
3、通过身份认证平台的用户管理程序管理用户数据
4.1.2.4.身份数据集成
统一身份认证系统集成用户身份数据的过程，是通过数据交换平台从学校的各个业务系统中自动抽取用户身份数据，并加以归纳和整理，最终充实用户身份信息库。
4.1.2.5.自动发现和动态同步
身份认证平台可以自动发现所管理资源中用户信息的更改，并根据规则将其同步到其它资源中去。
4.1.2.6.帐号和口令管理
身份认证平台提供了统一的WEB管理界面，可以方便地管理帐号和口令。
帐号管理功能包括：
1.用户自注册功能：
用户使用公共的帐号/口令登录系统，然后自行注册一个账号/口令。
2.帐号新建功能：
外来人员如需临时帐号，可以由管理员手工生成访问身份，这个访问身份通常是帐号/口令，也可通过多因子认证或数字证书实现。
这些临时帐号需要有效期限制，在“临时”的这段时间内有效，过期则失效；对于可转为正式帐号的“临时帐号”，可自动转换。
3.帐号注销功能：
在一定条件下，实现用户帐号的注销。
用户帐号注销后，所有的用户权限失效。
4.帐号冻结功能：
暂时中止用户的访问权限，在用户需要开通时可以重新恢复，这样用户可以继续使用原来的帐号。
口令管理包括：
1.自助式口令重置和同步
2.通过Web浏览器或者IVR（InteractiveVoiceResponse，交互语音应答系统）系统来实现
3.自动口令策略执行
4.口令历史信息存储
5.口令过期通知等等。
为满足用户个性化设置的需求，减轻管理员密码维护的压力，平台提供个人密码找回和别名登录功能，并开放给所有用户。
个人密码遗忘后，用户可以在门户认证界面上使用密码找回功能，问题回答正确后，可以重新设置密码；
用户登录后，可以根据自己的习惯设置登录别名，系统自动检查别名是否重复，别名设置成功后，用户可以使用别名进行登录。
4.1.2.7.分级管理
平台提供扁平的用户权限模型，提供分级管理功能。
应用模式
●系统缺省建立四大类身份：
领导、教职工、学生、校友；
●各应用系统按需建立自己的权限组或属性信息，也可复用其它系统已经建立的权限数据；
●权限模型支持分级授权，支持按组织架构、系统范围、用户属性等将权限管理工作分派给多名管理员；由于本功能在实际使用中容易导致管理混乱，一般建议只按照系统范围（如人事系统、学生系统等）来分级授权。
●用户数据采集时，自动根据用户的属性和来源为其设置相应的身份。
4.1.2.8.批量维护工具
满足管理员日常数据维护的需要，提供：
●批量导入用户数据、组织数据
●批量修改和删除人员属性信息
●高级查询功能
●系统服务的注册和注销
●在不同的人员容器间移动人员数据
应用模式：
●教职工用户数据通过人事系统数据访问接口或用户数据表导入；
●管理员定期使用该工具完成教职工用户数据的导入；
●学生毕业转为校友后，管理员通过该工具将毕业生批量转入；
●系统运行准备阶段，管理员通过该工具完成批量用户密码初始化。
4.1.2.9.与典型应用系统的集成
身份认证平台的资源适配器采用服务器端的J2EE适配器，部署在身份认证服务端，即J2EE应用服务器上，然后根据所管资源的通讯协议和资源互通。
对于大部分应用系统，无须在资源（即应用）一方安装任何代理。
这样既对应用系统无影响，又避免了维护代理的工作。
4.1.2.9.1.与LDAP目录服务器的集成
身份认证平台和LDAP目录服务器的集成，如SunJavaSystemDirectoryServer是通过JNDI资源适配器完成的，在资源方无须代理。
4.1.2.9.2.与采用LDAP目录服务的应用系统集成
同上。
身份认证平台通过其LDAP目录服务资源适配器和这些应用系统集成。
4.1.2.9.3.与关系型数据库应用系统的集成
如果应用系统的用户数据存储在关系型数据库中，应用系统和统一身份认证系统集成后，统一身份认证平台替代了应用系统的身份认证功能，该数据库中的用户信息将主要用于应用系统自身的授权和策略管理。
身份认证平台主要集成关系型数据库中的用户信息表、权限信息表以及用户/权限对应关系表等，在身份认证平台上建立针对应用的数据库资源，并制定相应的用户信息映射和同步关系，通过该资源将相应用户信息创建到数据库中。
身份认证平台和关系型数据库的集成是通过身份认证平台提供的JDBC（JavaDataBaseConnectivity，Java数据库连接）资源适配器完成的，并在资源方无须安装任何代理。
4.1.2.9.4.资源适配器的开发
身份认证平台为创建定制化的资源适配器提供了工具和文档支持。
开发工具包包括：
1.指南性文档资料：
功能定义、README文件等
2.Javadoc：
提供身份认证平台的API信息
3.Jar文件：
用于编译、连接
4.样本源代码等。
4.1.3.统一授权管理
策略与权限管理模块是多用户应用系统不可或缺的。
通常，策略与权限管理模块以应用专有的方式实现，系统的策略模型、策略存贮结构与访问控制逻辑与应用的业务逻辑之间耦合紧密。
这种方式的缺点是显而易见的：
由于策略模块与应用逻辑之间的紧耦合使得策略模块很难进行扩展与维护；策略模块的设计与编码需要很大的工作量，而且很难在不同的应用系统之间共享与重用。
为了克服专有方式的缺点，统一用户管理与认证平台在基础设施层提供了增强的策略服务，提供标准、通用、灵活和可扩展的策略模型，支持策略的定义、存贮、配置与判定，并与用户管理和服务管理紧密集成。
4.1.3.1.统一授权平台的架构
统一授权平台的架构如下图所示。
图中以灰色表示的组件是应用相关的部分，需要进行定制设计与开发；其余组件均由统一授权平台提供。
总体而言，策略与权限管理模块的架构基于PDP/PEP模型。
PDP代表策略判定点（PolicyDecisionPoint），是策略的提供者；PEP代表策略执行点（PolicyEnforcementPoint），是策略的使用者。
该架构中，统一授权管理提供PDP服务，包括策略的定义、存贮、配置与判定，这些服务通过策略判定API与策略管理API向外部应用提供；PEP是应用中根据策略判定结果执行应用逻辑的部分。
PDP与PEP之间可以通过Java/C++API或XML/HTTP通信。
由于统一授权管理提供的策略判定结果是原始结果，为了进一步简化应用中的策略执行逻辑，引入应用策略判定接口，对统一授权管理的策略判定接口进行封装，对原始策略判定结果作进一步加工与处理。
统一授权管理支持通过策略主体SPI（服务提供者接口）、策略条件SPI、策略推荐SPI与资源名称SPI进行扩展。
策略的存贮结构通过LDAP中的对象类与属性类型加以定义；策略存贮在目录服务器中。
4.1.3.2.策略模型
统一授权管理的策略服务建立在通用、灵活和可扩展的模型上。
正是该策略模型使其能在基础设施层以一种应用无关的方式提供强大的策略服务。
一般而言，作为访问控制规则的策略描述了“谁在何种情况下针对指定服务对何种资源可执行怎样的操作”。
在这里，“谁”是策略的主体；“情况”是策略适用的条件；“服务”是策略的上下文，“资源”与“操作”都是与该服务相关的；“资源”是策略的对象；“执行怎样的操作”可以表示为一系列“动作”及与之对应的“值”。
基于单点登录系统的策略模型提供了充分的表达能力，允许准确描述如上的通用策略。
统一授权管理的策略采用XML来描述。
为简明起见，在此以半形式化的方式描述策略模型如下：
常规策略:
:
=主体集+条件集+规则集
主体集:
:
={主体}
条件集:
:
={条件}
规则集:
:
={规则}
主体:
:
=AccessManager角色集|LDAP组集|LDAP角色集|LDAP用户集|LDAP组织集
条件:
:
=认证级别|认证方式|客户IP|时间
规则:
:
=服务+资源名称+动作类型-值对集
资源名称:
:
=字符串
动作类型-值对集:
:
={动作类型-值对}
动作类型-值对:
:
=动作类型+值
备注：
1、统一授权管理的策略包括推荐策略与常规策略。
由于推荐策略只是将策略推荐给对等组织或子组织进行判定，而不涉及策略的具体判定，因此此处不对推荐策略进行详细描述。
2、统一授权管理提供的主体插件SPI、条件插件SPI和资源名称插件SPI允许扩展主体、条件与资源名的表达能力，上述描述中主体、条件与资源名称只是由系统提供的标准实现。
4.1.3.3.策略编程接口
应用系统访问身份认证平台可以使用JavaAPI接口，也可以使用XML/HTTP接口。
如果是远程访问，则JavaAPI接口本身也是对XML/HTTP接口的一种封装。
远程客户端调用策略验证接口时的处理流程如下：
（1）应用系统调用JavaAPI请求策略验证；
（2）JavaAPI根据策略验证请求生成一个XML策略验证请求；
（3）JavaAPI将XML策略验证请求通过HTTP协议发送给系统的Policy服务：
%系统处理策略验证XML请求，并创建一个策略决策XML文档作为应答返回给客户端；
（5）客户端JavaAPI接收并解释策略决策XML文档；
（6）应用系统通过JavaAPI获取策略决策信息。
从上述流程可知，策略验证的结果是以策略决策的形式表现的。
如果使用XML/HTTP接口，则策略决策是一个XML文档；如果使用JavaAPI接口，则策略决策是一个Java对象。
策略决策中包括一组动作决策，动作决策是关于某个具体动作的决策，其中包括：
（1）动作的值：
与该动作相关的决策的值；
（2）有效时间（TTL）：
决策值在多久时间内有效；
（3）建议：
该动作决策的描述信息。
动作的值可以是布尔类型的，表示是与否、允许或禁止等两值类型的动作决策；动作的值也可以是复杂类型的，如字符串、数值等，可以用来表示动作的程度、范围等决策概念，诸如邮箱配额、折扣率等。
可能有许多策略适用于一次策略请求，不同的策略可能相互冲突。
比如，用户拥有的角色允许他访问某个URL，而用户所属的组禁止他访问某个URL；再比如，用户拥有的一个角色给予他20M的邮箱配额，而用户拥有的另一个角色给予他10M的邮箱配额。
这种不同策略同时适用，而且决策值不同的情况称为冲突。
冲突的策略决策必须消解之后才能用于权限控制。
系统是这样消解策略决策冲突的：
（1）如果动作值的类型是布尔类型，则所有策略的决策值在执行AND操作之后返回，返回的值是单值。
也就是说，只要有一个策略的动作决策是false，则动作的决策值就为false；
（2）如果动作值的类型是复杂类型，则所有策略的决策值全部返回给应用系统，由应用系统对决策值进行进一步的冲突消解。
策略的管理包括创建、删除和修改策略。
用户可以通过系统的WEB控制台界面或命令行界面管理策略。
如果在应用系统中需要对策略进行管理，可以使用系统的策略管理API。
4.1.3.4.应用策略的设计
一个应用系统是建立在多种平台服务之上的，并且向用户提供多种用户服务；而一个平台服务也应该为多个应用系统使用。
因此应用系统与服务之间是多对多的关系。
由于服务是应用的组成元素，因此，授权应该是针对服务的资源而不是应用的资源来进行的。
不同的服务具有不同的资源和动作类型，因此，不同的服务有不同的策略模板，该模板称为策略方案（PolicySchema）。
服务与策略方案之间的对应关系应该是一对一关系。
配置策略、验证策略是通过指定服务来指定策略方案的。
一条具体策略规定了一组主体在一组条件下的一组访问控制规则。
每条规则中均指明了一个服务、属于该服务的资源以及一组动作与值对。
每个策略方案也可以被多条策略使用。
因此，策略与策略方案之间的对应关系应该是多对多关系。
由于服务与策略方案之间是一一对应的，因此，定义策略方案是在定义服务的同时进行的。
只有当服务定义之后，才能定义与该服务相关的具体策
升级会员 