中小学智慧校园软件解决方案技术白皮书.docx
《中小学智慧校园软件解决方案技术白皮书.docx》由会员分享，可在线阅读，更多相关《中小学智慧校园软件解决方案技术白皮书.docx（43页珍藏版）》请在冰点文库上搜索。
中小学智慧校园软件解决方案技术白皮书
智慧校园软件解决方案
白
皮
书
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服务：
%protocol:
//%host:
%port/amserver/policyservice
（4）系统处理策略验证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）。
服务与策略方案之间对应关系应该是一对一关系。
配置策略、验证策略是通过指定服务来指定策略方案。
一条具体策略规定了一组主体在一组条件下一组访问控制规则。
每条规则中均指明了一个服务、属于该服务资源以及一组动作与值对。
每个策略方案也可以被多条策略使用。
因此，策略与策略方案之间对应关系应该是多对多关系。
由于服务与策略方案之间是一一对应，因此，定义策略方案是在定义服务同时进行。
只有当服务定义之后，才能定义与该服务相关具体策略。
从身份认证平台服务管理角度，服务是一组定义在一个公共名字下通过身份认证平台管理属性集合。
身份认证平台将服务作为一组属性进行管理，而并不关心这些属性具体涵义。
服务属性集合是通过一个XML文件加以定义。
身份认证平台提供了大量平台服务，这些服务本身也是通过系统服务管理功能加以管理，因此，这些平台服务也有对应XML定义文件，并且服务选项也是通过服务属性加以管理。
为了使服务能够针对不同用户、角色或组织等身份实体进行定制和个性化，身份认证平台将服务属性分为以下五种类型。
不同类型属性具有不同作用域、继承性、用途。
类型
作用域
继承性
用途
全局
整个统一授权系统
不可继承
服务全局配置
组织
应用于组织
不可继承
服务组织级配置
动态
应用于角色、用户
可继承
升级会员 