中小学智慧校园软件解决方案技术白皮书

1、智慧校园软件解决方案智慧校园软件解决方案 皮 书 白 目录 1. 总体框架 . 3 2. 技术路线 . 3 2.1.编程语言 . 4 2.2.面向对象的组件技术 . 4 2.3.应用程序的开发与运行结构 . 5 2.4.动态网页生成技术 . 5 3. 信息标准和规范系统 . 5 4. 基础支撑平台 . 7 4.1. 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.1.5. 4.1.6. 4.2. 4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.2.6. 4.2.7. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.3.4. 4.3.5. 4.3.6

2、. 统一身份认证系统 . 7 设计要点. 8 系统框架. 8 统一授权管理. 13 单点登录服务. 20 系统部署说明. 29 平台可靠性和扩展性 . 30 统一信息门户平台 . 30 设计要点. 30 平台框架. 31 门户运行环境. 31 平台主要功能. 32 平台部署及性能说明 . 错误！未定义书签。错误！未定义书签。 平台可靠性和扩展性说明 . 错误！未定义书签。错误！未定义书签。 平台安全性考虑. 错误！未定义书签。错误！未定义书签。 数据中心平台 . 错误！未定义书签。错误！未定义书签。 技术路线. 错误！未定义书签。错误！未定义书签。 设计要点. 错误！未定义书签。错误！未定义书

3、签。 平台框架. 错误！未定义书签。错误！未定义书签。 应用集成与数据集成 . 错误！未定义书签。错误！未定义书签。 数据交换机制. 错误！未定义书签。错误！未定义书签。 平台部署及性能说明 . 错误！未定义书签。错误！未定义书签。 1.1. 总体框架 亿阳信通智慧校园总体框架如图所示： 该框架以“师生”为核心，围绕智慧校园的资源、管理和服务三要素，依托 数据中心及应用支撑平台，重点建设校园资源中心、校园管理中心、校园服 务中心应用系统，形成数字化的教学环境、科研环境和生活环境。 2.2. 技术路线 智慧校园应用系统应采用成熟先进的技术规范，设计上尽量减少各子系 统间的相互依赖性（包括软件对平

4、台、软件对数据、软件对软件、平台对平 台等） ，某个子系统的减少、 增加和变更，不影响其它子系统和整体， 从而最 大限度地保护既有投资，减少系统的维护量和再投入。在应用系统整体化、 模块化和规模化的同时，保证应用系统在技术上、经济上的可持续发展。 亿阳信通智慧校园软件系统遵循如下技术路线： 1、采用“跨平台”的编程语言。 2、采用独立于开发环境的面向对象的组件技术，如 EJBs (Enterprise Java Beans)，整个系统的主要“应用逻辑”由组件构成，系统架构提供了良好 的伸缩性，使系统能够轻易地组合与拆分各功能模块。 3、应用软件平台的开发及运行架构采用三层结构，即 Web 服务

5、器、应用服 务器和数据库服务器，在不影响系统其它部分的情况下，保证了应用服务 器与其它应用有效和无缝的整合，同时支持大规模的并发用户访问。 4、采用模版（Template) 技术生成动态网页，为用户提供基于角色和权 限的内容和数据服务。 架构实现采用 Java 语言和 EJBs 技术，在数据交换上支持 XML，使系统功 能最优化，同时将系统内部的相互依赖性减至最低。 . 编程语言 遵循 J2EE (Java 2 Enterprise Edition)规范 ，采用 Java 语言和服务 器端 Java 技术（包括 EJBs、 Servlet、JNDI、 JDBC 和 RMI 等）开

6、发系统。 Java作为Web应用的事实标准， 其独立于操作系统和服务器的“跨平台性”， 使其“一次编写，到处运行”，是 WEB 软件系统最适合的编程语言。相对于 嵌入 HTML、受限于用户端显示、编程能力有限的脚本语言，Java 能力完整， 可以开发具有强大“业务逻辑”的大型应用系统。 . 面向对象的组件技术 软件编程由依赖于特定单机，到依赖于操作系统，已发展到今天面向对 象的组件技术。面向对象的组件技术是一种完全独立于硬件和操作系统的开 发环境，着重于应用程序“业务对象”的可重复使用组件，利用这些组件， 可以像搭积木一样的建立分布式应用系统。面向对象的组件技术在异构、分 布环境

7、下为不同机器上的应用提供了互操作性，并无缝地集成了多种对象系 统；另一方面， 组件大大加快了软件开发的速度，降低了软件开发和再开发 的成本。 . 应用程序的开发与运行结构 开发及运行结构基于三层架构，即 Web 服务器、应用服务器和数据库服 务器。运用这种架构可以： （1）将“业务逻辑”从 Web 服务器中分出，在应用服务器中用独立和完 整的编程语言而不是“脚本语言”开发应用程序， 同时使系统支持任何 HTML 的显示工具； （2） 应用服务器可以作为数据库访问请求的“缓冲区”， 可以重新安排、 管理数据库访问。通过 Java Servlets 引擎的多线程处理，能够极大地提高

8、系统响应性能和数据库访问效率； （3）应用服务器可以作为与其它应用程序集成的结合点，在不影响系统 其它部分的情况下与其它应用有效、无缝集成。 . 动态网页生成技术 信息发布采用基于模版的动态网页生成技术。用户界面的版面和显示效 果由预先制作的模版实现， 并支持任何标准化的 HTML 工具， 嵌入模版的 Java 程序根据用户的角色和权限提取相应的内容和数据，配合模版自动合成针对 用户的个性化的动态网页。 信息标准和规范系统 信息标准是智慧校园建设的重心， 是学校各信息系统进行数据采集、 处理、 交换、传输的前提，也是构建新应用需要遵循的标准。 亿阳信通按以下原则建设智慧校园的信息

9、标准： 唯一性： 标准采用树形体系结构， 唯一的项、 唯一的路径、 唯一的编码。 规范性：充分参照国家相关最新标准、教育部教育管理信息化标准 、 北京市教委相关标准和各区县教委相关标准。 适用性：标准的制定充分考虑学校的实际情况，以应用为目标。 兼容性：对标准实行版本化的维护管理。高版本兼容低版本。同一个版 本，维护其不同内容的一致性。学校校内标准兼容教育部及其它管理部 门的标准，方便数据上报。 可管理性：系统提供数据标准集、数据代码集、自定义代码集、数据代 码映射等提供 B/S 架构的可视化管理工具，具备初始化、新增、删除、 修改等维护功能，支持分类检索、输出、数据展示等浏览功能。 可扩展性

10、：支持标准的增加和变更，具有维护记录和回溯功能，并且对 应用该标准的业务系统透明。所有历史版本可查询，可比较差异。 管理信息标准的体系结构包括以下几个方面：一组相关数据元的集合， 对数据元属性的规范描述 （又称之为元数据标准化） ， 属性包含了数据项名称、 中文简称、类型、长度、可选性、取值范围等。为了确保数据录入规范、便 于查找和统计，每个管理子集都对应着相应的标准代码，代码分国家标准、 行业标准和学校标准。 系统遵循国家教育管理信息系统互操作规范，能够与北京市教委制定的 小学应用互操作框架（简称 CIF）无缝对接，实现各业务系统间规范的数据 共享。 CIF 实现规范也定义了基于 XML 标

11、准的 CIF 数据模型， 支持小学数据对象 在应用系统间的共享。 “教师”和“学生”是智慧校园系统涉及的两大数据对象，业务数据实 体主要由这两大对象映射产生。通过“教师”对象产生的数据实体主要有教 案、作业、教学成绩、教学计划等一系列和教师教育教学活动相关的数据； 通过“学生”对象产生的数据实体主要有考试成绩、课堂表现、获奖、毕业 去向等一系列和学生学习成长相关的数据。这些数据存储在智慧校园的数据 中心，通过综合统计分析，又产生大量的衍生数据，如教师分布情况、学生 分布情况、考试成绩综合统计分析等，这些数据可以为学校的管理层提供微 观和宏观的决策支持，使领导能够直观的了解各个部门乃至整个学校的

12、运行 状况。具体数据模型框架如下图所示： 基础支撑平台 统一身份认证系统 应用系统如果采用各自独立的身份认证机制，用户就要记忆不同系统中 的账号/密码。为方便师生使用，解决多应用带来的多账号问题，需要建立 统一的身份管理平台， 用户在平台上登录一次就可以访问所有具有权限的应 用。 统一身份认证以 IDM/IM（身份认证管理）为基础提供安全的用户身份管 理功能，并配合 Access Manager 基于代理架构的访问控制，提供 Web 应用 的单点登录和 Web 应用保护。 IDM/IM 都集成了 Directory Server(LDAP)目录 服务器来存储统一身份库信息。统一身份认证实现的功

13、能如下： 1.建立统一的集中身份库统一身份数据中心， 对各应用系统的所有用 户提供集中和统一的管理，同时根据各个业务应用系统的认证方式的不同提 供灵活的认证机制； 2.在集中身份库的基础上， 在满足数字校园管理平台信息系统内部业务流 程规则的前提下，通过身份管理技术实现身份库与各个业务应用系统(门户、 OA、教学、教务等系统)用户身份信息的自动同步处理功能； 3.在集中身份库的基础上，提供单点登录(SSO)功能，用户只需要通过一 次身份认证就可以访问具有权限的所有资源。 集中身份库与门户系统的统一可以为整个平台提供集中的管理、安全机 制，实现整体的统一。 4.1.1.设计要点 支持用户数据的集

14、成，适应中小学用户数据分散管理的现状 支持用户数据存储模式，适应中小学教职工多重身份的现状 支持多种认证方式，确保异构业务系统能够集成，让用户获得完整的 单点登录体验 满足不同用户或系统的认证安全需求 保证身份认证平台的高可靠性和高性能 前三个需求是身份认证平台发挥作用的基础，而随着应用集成的力度和广度 的加大，后两个将是身份认证平台必须妥善处理的问题。 校园应用功能多样、结构复杂，各应用系统的权限管理基本上采用分级授权 的方式。身份认证平台可以采用统一的权限模型，供各应用系统使用，相应 的权限数据既可集中管理也可分布式管理。从实践结果看，集中权限控制的 效益并不明显，建议不强求集中控制，由各

15、应用系统设计开发时按需选择。 4.1.2.系统框架 身份认证平台主要包括以下三方面功能： LDAP 目录服务，支持海量用户数据的存储和管理 高性能 SSO(单点登录)身份认证服务 开放的认证集成方式，支持不同开发语言和不同应用服务器平台的业 务系统 . 统一身份管理架构 学校的各种应用系统通常都有自己独立的用户管理、用户认证和授权 机制，导致系统间互不兼容；学校的组织机构也不断变化，用户来源日趋 复杂，角色多样化和角色变化等问题不断出现。 各方因素交织在一起形成 了一个庞大的矩阵，为统一的身份管理带来了困难。如图： 针对上述问题， 建立一个统一的， 基于业界标准 （如 LDAP，

16、 XML， Web Service， J2EE 等）的，灵活、开放、可扩展性的身份管理框架是最终的解决方案。一 个好的身份管理解决方案将复杂的身份管理问题变得简单、实用。身份认证 平台核心结构如下图所示： 身份认证平台管理用户在各个应用系统中的用户信息的对应关系，并根据这 一关系管理用户在各个应用系统中的生命周期，如添加、删除、修改等。身 份认证平台的身份同步工具可以自动发现某个应用系统中用户信息的变化并 通过一定规则，保持和其它应用中的用户信息同步。 身份认证平台的核心包括用户信息创建和中止的审批流程，该流程由管理员 预先定义，可以修改。 当用户帐户的申请被批准后，用户帐户将根据预先定义的规

17、则在中央主目录 服务器中创建，并通过资源适配器在各个该用户可以使用的应用系统中产生 帐户信息。用户帐号的中止也是同样原理。 身份认证平台具有口令管理功能，支持口令策略管理和口令历史记录，支持 用户身份审计和用户帐户风险分析，支持用户身份管理系统运行的监测、评 估。 . 用户数据模型 身份认证平台中的数据模型包括： 1. 用户帐号：学生、教职员工、合作伙伴、供应商等帐户信息； 2. 资源：身份认证平台所管理的身份数据源和应用系统，如学生数据中心、 教职工数据中心、电子邮件、一卡通、综合网络管理系统以及上网认证系统、 VPN 系统等，以及其它基于用户属性更改的应用； 3. 资源组：按

18、一定顺序组织的资源，身份认证平台将根据这一顺序在应用系 统中创建和删除用户信息； 4. 组织：管理一组用户、资源和其它对象的逻辑容器； 5. 角色： 用户的工作角色， 代表其职能性质， 据此在资源中设置用户的属性； 6. 管理帐户：具有管理员权限，可以进行分级管理； 7. 能力：拥有哪些权限，如口令管理员只能管理用户的口令。 下图为数据模型图： 身份认证平台： 1. 管理用户访问一个或多个资源的权限； 2. 管理用户在这些资源上的帐户数据； 3. 赋予用户一个或多个角色，设置用户访问各种资源的权限； 4. 管理组织，决定用户帐户由谁和怎样被管理。 用户数据是动态的，依赖于用户的角色、资源和资源

19、组。根据角色（可以是 多角色）赋予的资源的数量和类型，需要不同的信息表示，也决定着创建用 户时的信息数量。 身份认证平台有虚拟用户的概念，主要作用是映射用户到多个资源，可以将 一个用户在多个应用系统中的全部帐户信息作为一个实体来管理。 . 用户数据管理 身份认证系统需要提供多样化的用户数据管理方案。用户数据采集可以根据 学校现状，采用以下方式： 1、集成管理着权威用户数据的业务系统，依赖该系统进行用户数据管理 2、通过数据集成平台双向同步用户数据 3、通过身份认证平台的用户管理程序管理用户数据 . 身份数据集成 统一身份认证系统集成用户身份数据的过程，是通过数据交换

20、平台从学校的 各个业务系统中自动抽取用户身份数据，并加以归纳和整理，最终充实用户 身份信息库。 . 自动发现和动态同步 身份认证平台可以自动发现所管理资源中用户信息的更改，并根据规则将其 同步到其它资源中去。 . 帐号和口令管理 身份认证平台提供了统一的 WEB 管理界面，可以方便地管理帐号和口令。帐 号管理功能包括： 1. 用户自注册功能：用户使用公共的帐号/口令登录系统，然后自行注册一 个账号/口令。 2. 帐号新建功能： 外来人员如需临时帐号， 可以由管理员手工生成访问身份， 这个访问身份通常是帐号/口令，也可通过多因子认证或数字证书实现。 这些临时帐号需要有

21、效期限制，在“临时”的这段时间内有效，过期则失 效；对于可转为正式帐号的“临时帐号”，可自动转换。 3. 帐号注销功能：在一定条件下，实现用户帐号的注销。用户帐号注销后， 所有的用户权限失效。 4. 帐号冻结功能：暂时中止用户的访问权限，在用户需要开通时可以重新恢 复，这样用户可以继续使用原来的帐号。 口令管理包括： 1. 自助式口令重置和同步 2. 通过 Web 浏览器或者 IVR（Interactive Voice Response，交互语音应答 系统）系统来实现 3. 自动口令策略执行 4. 口令历史信息存储 5. 口令过期通知等等。 为满足用户个性化设置的需求，减轻管理员密码维护的压力

22、，平台提供个人 密码找回和别名登录功能，并开放给所有用户。 个人密码遗忘后，用户可以在门户认证界面上使用密码找回功能，问题回答 正确后，可以重新设置密码； 用户登录后，可以根据自己的习惯设置登录别名，系统自动检查别名是否重 复，别名设置成功后，用户可以使用别名进行登录。 . 分级管理 平台提供扁平的用户权限模型，提供分级管理功能。 应用模式 系统缺省建立四大类身份：领导、教职工、学生、校友； 各应用系统按需建立自己的权限组或属性信息，也可复用其它系统已 经建立的权限数据； 权限模型支持分级授权，支持按组织架构、系统范围、用户属性等将 权限管理工作分派给多名管理员；由于本功能在实际

23、使用中容易导致 管理混乱，一般建议只按照系统范围（如人事系统、学生系统等）来 分级授权。 用户数据采集时，自动根据用户的属性和来源为其设置相应的身份。 . 批量维护工具 满足管理员日常数据维护的需要，提供： 批量导入用户数据、组织数据 批量修改和删除人员属性信息 高级查询功能 系统服务的注册和注销 在不同的人员容器间移动人员数据 应用模式： 教职工用户数据通过人事系统数据访问接口或用户数据表导入； 管理员定期使用该工具完成教职工用户数据的导入； 学生毕业转为校友后，管理员通过该工具将毕业生批量转入； 系统运行准备阶段，管理员通过该工具完成批量用户密码初始化。 . 与

24、典型应用系统的集成 身份认证平台的资源适配器采用服务器端的 J2EE 适配器， 部署在身份认证服 务端，即 J2EE 应用服务器上，然后根据所管资源的通讯协议和资源互通。对 于大部分应用系统，无须在资源（即应用）一方安装任何代理。这样既对应 用系统无影响，又避免了维护代理的工作。 .1. 与 LDAP 目录服务器的集成 身份认证平台和 LDAP 目录服务器的集成，如 Sun Java System Directory Server 是通过 JNDI 资源适配器完成的，在资源方无须代理。 .2. 与采用 LDAP 目录服务的应用系统集成 同上。身份认证平台通过其 LD

25、AP 目录服务资源适配器和这些应用系统集成。 .3. 与关系型数据库应用系统的集成 如果应用系统的用户数据存储在关系型数据库中，应用系统和统一身份认证 系统集成后，统一身份认证平台替代了应用系统的身份认证功能，该数据库 中的用户信息将主要用于应用系统自身的授权和策略管理。 身份认证平台主要集成关系型数据库中的用户信息表、 权限信息表以及用户/ 权限对应关系表等，在身份认证平台上建立针对应用的数据库资源，并制定 相应的用户信息映射和同步关系，通过该资源将相应用户信息创建到数据库 中。身份认证平台和关系型数据库的集成是通过身份认证平台提供的JDBC （Java Data Base C

26、onnectivity，Java 数据库连接）资源适配器完成的， 并在资源方无须安装任何代理。 .4. 资源适配器的开发 身份认证平台为创建定制化的资源适配器提供了工具和文档支持。 开发工具包包括： 1. 指南性文档资料：功能定义、README 文件等 2. Javadoc：提供身份认证平台的 API 信息 3. Jar 文件：用于编译、连接 4. 样本源代码等。 4.1.3.统一授权管理 策略与权限管理模块是多用户应用系统不可或缺的。通常，策略与权限管理 模块以应用专有的方式实现，系统的策略模型、策略存贮结构与访问控制逻 辑与应用的业务逻辑之间耦合紧密。这种方式的缺点是显而易见

27、的：由于策 略模块与应用逻辑之间的紧耦合使得策略模块很难进行扩展与维护；策略模 块的设计与编码需要很大的工作量，而且很难在不同的应用系统之间共享与 重用。 为了克服专有方式的缺点，统一用户管理与认证平台在基础设施层提供了增 强的策略服务，提供标准、通用、灵活和可扩展的策略模型，支持策略的定 义、存贮、配置与判定，并与用户管理和服务管理紧密集成。 . 统一授权平台的架构 统一授权平台的架构如下图所示。 图中以灰色表示的组件是应用相关的部分， 需要进行定制设计与开发；其余组件均由统一授权平台提供。 总体而言，策略与权限管理模块的架构基于 PDP/PEP 模型。PDP 代表策略判 定点

28、(Policy Decision Point) ，是策略的提供者； PEP 代表策略执行点 (Policy Enforcement Point)，是策略的使用者。该架构中，统一授权管理 提供 PDP 服务，包括策略的定义、存贮、配置与判定，这些服务通过策略判 定 API 与策略管理 API 向外部应用提供；PEP 是应用中根据策略判定结果执 行应用逻辑的部分。PDP 与 PEP 之间可以通过 Java/C+ API 或 XML/HTTP 通 信。 由于统一授权管理提供的策略判定结果是原始结果，为了进一步简化应用中 的策略执行逻辑，引入应用策略判定接口，对统一授权管理的策略判定接口 进行封装，对

29、原始策略判定结果作进一步加工与处理。 统一授权管理支持通过策略主体 SPI（服务提供者接口） 、策略条件 SPI、策 略推荐 SPI 与资源名称 SPI 进行扩展。 策略的存贮结构通过 LDAP 中的对象类 与属性类型加以定义；策略存贮在目录服务器中。 . 策略模型 统一授权管理的策略服务建立在通用、灵活和可扩展的模型上。正是该策略 模型使其能在基础设施层以一种应用无关的方式提供强大的策略服务。一般 而言，作为访问控制规则的策略描述了“谁在何种情况下针对指定服务对何 种资源可执行怎样的操作”。在这里，“谁”是策略的主体；“情况”是策 略适用的条件；“服务”是策略的上下文，“资源”

30、与“操作”都是与该服 务相关的；“资源”是策略的对象；“执行怎样的操作”可以表示为一系列 “动作”及与之对应的“值”。基于单点登录系统的策略模型提供了充分的 表达能力，允许准确描述如上的通用策略。 统一授权管理的策略采用 XML 来描述。为简明起见，在此以半形式化的方式 描述策略模型如下： 常规策略 := 主体集 + 条件集 + 规则集 主体集 := 主体 条件集 := 条件 规则集 := 规则 主体 := Access Manager 角色集| LDAP 组集| LDAP 角色集| LDAP 用户集 |LDAP 组织集 条件 := 认证级别|认证方式|客户 IP |时间 规则 := 服务 +

31、 资源名称 + 动作类型-值对集 资源名称 := 字符串 动作类型-值对集 := 动作类型-值对 动作类型-值对 := 动作类型 + 值 备注： 1、 统一授权管理的策略包括推荐策略与常规策略。 由于推荐策略只是将策略 推荐给对等组织或子组织进行判定，而不涉及策略的具体判定，因此此处不 对推荐策略进行详细描述。 2、统一授权管理提供的主体插件SPI、条件插件SPI 和资源名称插件 SPI 允 许扩展主体、条件与资源名的表达能力，上述描述中主体、条件与资源名称 只是由系统提供的标准实现。 . 策略编程接口 应用系统访问身份认证平台可以使用 Java API 接口，也可以使用 XML

32、/HTTP 接口。如果是远程访问，则 Java API 接口本身也是对 XML/HTTP 接口的一种 封装。 远程客户端调用策略验证接口时的处理流程如下： (1)应用系统调用 Java API 请求策略验证； (2)Java API 根据策略验证请求生成一个 XML 策略验证请求； (3)Java API 将 XML 策略验证请求通过 HTTP 协议发送给系统的 Policy 服 务：%protocol:/%host:%port/amserver/policyservice (4)系统处理策略验证 XML 请求，并创建一个策略决策 XML 文档作为应答 返回给客户端； (5)客户端 Java

33、API 接收并解释策略决策 XML 文档； (6)应用系统通过 Java API 获取策略决策信息。 从上述流程可知，策略验证的结果是以策略决策的形式表现的。如果使用 XML/HTTP 接口，则策略决策是一个 XML 文档；如果使用 Java API 接口，则 策略决策是一个 Java 对象。 策略决策中包括一组动作决策，动作决策是关于某个具体动作的决策，其中 包括： （1）动作的值：与该动作相关的决策的值； （2）有效时间（TTL） ：决策值在多久时间内有效； （3）建议：该动作决策的描述信息。 动作的值可以是布尔类型的，表示是与否、允许或禁止等两值类型的动作决 策；动作的值也可以是复杂类型

34、的，如字符串、数值等，可以用来表示动作 的程度、范围等决策概念，诸如邮箱配额、折扣率等。 可能有许多策略适用于一次策略请求，不同的策略可能相互冲突。比如，用 户拥有的角色允许他访问某个 URL， 而用户所属的组禁止他访问某个 URL； 再 比如，用户拥有的一个角色给予他 20M 的邮箱配额，而用户拥有的另一个角 色给予他 10M 的邮箱配额。这种不同策略同时适用，而且决策值不同的情况 称为冲突。冲突的策略决策必须消解之后才能用于权限控制。系统是这样消 解策略决策冲突的： (1)如果动作值的类型是布尔类型，则所有策略的决策值在执行 AND 操作 之后返回， 返回的值是单值。 也就是说， 只要有一

35、个策略的动作决策是 false， 则动作的决策值就为 false； (2)如果动作值的类型是复杂类型，则所有策略的决策值全部返回给应用 系统，由应用系统对决策值进行进一步的冲突消解。 策略的管理包括创建、删除和修改策略。用户可以通过系统的 WEB 控制台界 面或命令行界面管理策略。如果在应用系统中需要对策略进行管理，可以使 用系统的策略管理 API。 . 应用策略的设计 一个应用系统是建立在多种平台服务之上的， 并且向用户提供多种用户服务； 而一个平台服务也应该为多个应用系统使用。因此应用系统与服务之间是多 对多的关系。 由于服务是应用的组成元素，因此，授权应该是针对服务的资源而

36、不是应用 的资源来进行的。不同的服务具有不同的资源和动作类型，因此，不同的服 务有不同的策略模板，该模板称为策略方案（Policy Schema） 。服务与策略 方案之间的对应关系应该是一对一关系。配置策略、验证策略是通过指定服 务来指定策略方案的。 一条具体策略规定了一组主体在一组条件下的一组访问控制规则。每条规则 中均指明了一个服务、属于该服务的资源以及一组动作与值对。每个策略方 案也可以被多条策略使用。因此，策略与策略方案之间的对应关系应该是多 对多关系。 由于服务与策略方案之间是一一对应的，因此，定义策略方案是在定义服务 的同时进行的。只有当服务定义之后，才能定义与该服务相关的具体策略

37、。 从身份认证平台服务管理的角度，服务是一组定义在一个公共名字下通过身 份认证平台管理的属性的集合。 身份认证平台将服务作为一组属性进行管理， 而并不关心这些属性的具体涵义。服务的属性集合是通过一个 XML 文件加以 定义的。 身份认证平台提供了大量的平台服务，这些服务本身也是通过系统的服务管 理功能加以管理的，因此，这些平台服务也有对应的 XML 定义文件，并且服 务的选项也是通过服务的属性加以管理的。 为了使服务能够针对不同的用户、 角色或组织等身份实体进行定制和个性化， 身份认证平台将服务的属性分为以下五种类型。不同类型的属性具有不同的 作用域、继承性、用途。 类型作用域 全局 整个统一

38、授权 系统 组织 应用于组织 继承性用途 不 可 继 服务的全局配置 承 不 可 继 服务的组织级配置 承 动态 应用于角色、可继承服务的动态配置， 配置给角色的 用户属性自动为所有具有该角色的 用户拥有， 配置给组织的属性自 动为所有该组织下的用户拥有。 策略 N/AN/A与服务授权相关的配置 用户 只应用于用户不 可 继 服务针对于每个用户的个性化 承配置。 用户类型的属性只对个别 用户有意义。 . 角色与用户组管理 角色是和用户组的概念相似的目录服务器对象管理机制。一个组有其成员； 一个角色也有其成员。 在身份认证平台中，用户角色的权限是通过为其设定 ACI（Access

39、Control Infromation）来控制的。访问控制指令可以控制对整个目录、目录子树、目 录中特写条目（包括定义配置任务的条目）或特定条目属性信息的访问权。 可以设置特定用户、所有属于特定组或角色的用户或所有目录用户的权限。 还可以定义对特定位置（例如 IP 地址或 DNS 名称）的访问权。 与条目属性一样，访问控制指令存储在目录中。 ACI 属性是一种操作性属性， 可用于目录的各个条目，而不管是否为该条目的对象类所定义。接收到客户 端的 LDAP 请求时， 目录服务器使用该属性来允许或拒绝访问。 如果有特别请 求，则在 ldap search 操作中返回 ACI 属性。 在平台中可以定

40、义特定的角色，并利用 ACI 来控制其访问权限。这样做可以 满足一些特殊需求。 利用组织内创建用户时可以拥有默认角色的机制，可以为不同的组织创建不 同的默认角色，这样新建的用户就自然拥有了这些角色所拥有的属性和服务 以及相应的权限。 组代表了具有相同功能、属性或者兴趣爱好的用户的集合。一般来说，组没 有自己的特权。 组可以定义在组织机构下， 也可以定义在别的受管组 （Managed Group）内作为子组。 身份认证平台提供了组的分级管理的能力。虽然组的成员缺省来自于整个用 户树，但是对于权限有限的组管理员来说，当他管理一个预订组的时候，他 只能把他自己能管理的用户添加到新创建的预订组中。在这

41、里已经部分实现 了用户组的分级管理。 在业务系统一级授权上，我们提供了全局权限组用于人员的初始化授权。这 些组按照用户基本身份建立 （比如学生组、 教职工组） ， 作用域为整个组织树， 在人员的初始时可以按照身份加入这些全局组， 从而实现人员权限的初始化。 . 权限语义集成 当身份认证平台的策略服务不能满足业务系统授权要求时，我们提供了一种 针对业务系统开放的完全自由的权限语义集成机制。权限语义描述了用户的 具体应用权限，权限语义的具体描述和解析由业务系统负责。业务系统可以 通过 API 来获取这些语义，解析后授予用户相应的权限。 . 用户数据采集 功能描述 针对学

42、校用户管理分散进行的特点，提供从权威数据源采集用户数据，并实 时更新目录服务器中的用户数据，提供： 数据源采集点和采集周期定义 数据源变化跟踪和自动采集 应用模式 建立从公共数据库平台相关的共享数据集采集，在学生和教职工用户数据变 更(包括新增、删除、修改)后，采集模块自动同步更新统一认证用户数据库。 用户数据通常分散在不同的应用系统中。常见的情况是：人事系统管理人事 信息； 办公系统管理与日常工作有关的信息； 用户的认证信息如用户 ID 和密 码在各个系统中一般不同，由各个系统分散管理；用户的基本属性，如姓名 等信息往往在各个系统中都存在。不同应用系统不但管理不同类型的用户数 据，而且也提供

43、不同类型的数据存储与访问方式。传统的业务系统一般使用 关系数据库存放用户数据，如管理信息系统；互联网应用系统一般使用LDAP 存放用户数据，如电子邮件系统。不同类型的数据存储方式具有不同的数据 存储格式，也提供不同的数据访问接口。用户数据的分散存储与管理使得共 享用户数据成为复杂而低效的任务。 建立统一用户管理数据库的目的是为用户信息的管理与使用提供统一的入 口。统一用户管理数据库在物理上与其它应用数据源独立，在数据上与其它 应用数据源保持同步。用户管理数据库变更后同步到 LDAP 目录数据库。 . 用户数据发布 功能描述 为了保持各业务系统中用户数据的完整性和统一性，向各集成业

44、务系统提供 用户身份数据。 应用模式 对目前已有系统提供用户数据更新变更同步 提供用户信息的浏览、排序、查询等管理功能 由于中小学用户数据分散管理，在权威数据源变更后，其他系统都可 通过统一用户管理数据库同步数据变更，保持数据的完整与一致 . 批量维护工具 功能描述 满足管理员日常维护数据的需要，提供： 导入用户数据和组织数据 批量修改和删除人员属性信息 高级查询功能 服务注册与注销 在不同的人员容器间移动人员数据 应用模式 教职工用户数据由人事系统提供数据访问接口或用户数据表 管理员定期使用该工具完成教职工用户数据导入 在学生毕业转为校友后，管理员通过该工具将毕业生批量转入 系

45、统运行准备阶段，管理员通过该工具完成用户密码的批量初始化 0.个人自助服务 功能描述 为了满足用户个性化设置并减轻管理员的维护工作量，平台提供个人密码找 回、别名登录功能。 应用模式 该功能开放给所用用户； 用户遗忘个性化设置的密码后，可以在门户认证界面上进入密码找回 功能，预设问题回答正确后，可以自主重置密码； 用户登录后，可以根据自己的习惯设置登录别名，系统自动检查别名 是否重复，别名设置成功后，用户可以通过别名进行登录。 1.权限模型 功能描述 为了适应中小学用户多重身份和组织结构易变的特点，同时最大限度的保证 用户认证效率，平台提供扁平的用户权限模型。 应用

46、模式 系统将缺省建立四大类身份：教职工、学生、领导、校友； 各应用系统按需建立自定义的权限组或属性信息，也可复用其他系统 已经建立的相关权限数据； 权限模型支持分级授权，方便按组织架构、系统范围、用户属性等特 征将权限管理工作逐级分派给多名管理员；该功能在实际使用中容易 导致管理混乱，一般建议只按照系统范围（如人事系统、学生系统等 等）来分级授权。 用户数据采集时， 自动根据用户的属性和来源为用户设置相应的身份。 2.认证集成 功能描述 满足学校业务系统多元化特点，提供： 支持基于认证接口、认证代理和 LDAP 认证的多种认证集成模式 支持密码认证 支持与标准的主流 Radius

47、 服务器集成 预留 CA 认证扩展接口 预留 SmartCard、JavaCard 认证扩展接口 预留与网络接入认证设备用户认证模块的集成接口，实现与网络接入 认证设备的认证集成 应用模式 业务系统全部采用基于认证接口的认证集成方式； 用户统一采用基于密码认证的登录方式。 4.1.4.单点登录服务 单点登录（Single Sign On，SSO）通常定义为指用户只需经过一次认证就可 以访问所有拥有访问权限的应用系统。单点登录能够提高用户的工作效率， 减少身份认证过程中的人为错误，也减轻了用户在密码管理上的负担，从而 使系统更安全、更易用。身份认证平台提供了单点登录解决方案，用户只需 通过系统的

48、认证，并且具有足够的权限，就可以访问所有由身份认证平台管 理的应用系统。统一认证服务是单点登录支持的基础，没有统一认证，就没 有真正的单点登录。 校园网通常运行多个应用系统，为学校领导、各部门及教生提供多种服务， 这样就带来了一个突出的问题， 用户面对多个系统时要记忆、 输入帐号/口令 等信息，不仅烦琐，而且容易丢失口令，一旦口令泄漏会造成不可估量的损 失。 单点登录系统的建设目标是要解决各应用系统用户名和口令不统一的问题， 期望提供一套方便、安全的口令认证方法，让用户只要一个用户名和口令就 可以使用网络上他有权使用的所有业务系统。 . 设计要点 单点登录系统设计的要点如下： 遵

49、循 LA（Liberty Alliance，联合互信）的 ID-FF V1.2 规范。 支持 SAML（Security Assertion Markup Language ）安全性断言标记 语言规范。 支持多种多级登录认证机制，如用户/密码、动态口令等。 支持系统的认证过程支持加密的认证方式。 系统支持基于用户 UID 和密码的身份认证。 提供用户密码加密功能，支持 SSHA、CRYPT、SHA 等加密算法。 通过 TLS （Transport Layer Security， 传输层安全协议） 或 SSL （Secure Sockets Layer，安全套接层协议）为信息传输提供保密性和完整

50、性保 护。 支持 X.509 协议，可以对数字证书、公共密钥、数字签名进行存储和 管理。 支持跨域的单点登录功能。 . 系统原理与体系结构 单点登录系统的根本原理是保持用户的会话（session）状态。用户经过一次 认证就可建立单点登录会话，每个单点登录会话对应于一个令牌（token） ， 用户访问应用系统时向应用系统传递单点登录令牌，应用系统能够根据令牌 识别用户的认证状态，从而使一次认证能够被多个应用系统认可，避免了重 复认证。 我们采用 Sun Java System AccessManager（简称 AM）作为单点登录的底层 技术平台。 根据上述原理，AM 对单点登录提供

51、 SDK 级别的支持，其中包括单点登录令牌 的创建与验证。 以 WEB 应用的单点登录为例： 用户通过 AM 的认证页面进行认 证，认证通过之后，平台为该用户创建一个单点登录令牌，并将该令牌的ID 通过 cookie 返回至用户浏览器； 当用户访问 WEB 应用系统时， 单点登录令牌 ID 自动通过 cookie 传递至 WEB 应用系统， WEB 应用系统可以通过单点登录令 牌 ID 还原单点登录令牌， 并向 Access Manager 验证单点登录令牌是否有效。 如果有效，则应用系统可以从单点登录令牌获取用户身份信息，而不再需要 用户进行再次认证。对于 C/S 结构的应用，单点登录过程是

52、类似的，只是单 点登录令牌 ID 的传递方式不同。 上述单点登录 SDK 的体系结构如下图所示： 如前所述，单点登录是通过单点登录会话实现的，通过单点登录会话保持用 户在整个平台的认证状态。 在对用户进行身份验证之前，AM 的会话服务先产生令牌，令牌包含一个随机 生成的会话标志并且会作为这次会话的最终标志。令牌一旦生成， AM 会将它 插入一个 Cookie，并且颁发给用户的浏览器。与此同时，AM 会根据用户所使 用的验证方式，提示不同的登录界面，验证方式可预先为组织、角色或单个 用户进行配置。当用户接收到登录界面时，同时也获得一个会话令牌，用户 会键入用户名和密码， 登录资料被提交给适当的验

53、证服务器(如 LDAP、 RADIUS 等)，一旦用户通过了身份验证，AM 会从 cookie 中提取用户的令牌，并且将 其状态设置为有效的，接着将用户重新定向到所要访问的 URL。 单点登录会话具有如下图所示的生命周期： 如图所示，单点登录会话的初始状态是无效，表示单点登录会话虽然已经创 建并被分配给用户，但用户尚未通过有效认证。无效的单点登录会话也通过 一个单点登录会话令牌身份， 并存储在用户浏览器的 cookie 中。 当用户认证 成功之后，单点登录会话变为有效状态。该单点登录会话仍以同一个单点登 录会话令牌身份， 用户浏览器中的 cookie 不变， 只是服务器维护的会话状态 变为有效

54、。单点登录会话可以因为以下原因而销毁： 1. 客户端空闲时间达到最大空闲时间； 2. 会话时间达到最大会话有效时间； 3. 由于用户登出而显式销毁会话； 会话销毁之后， 客户端 cookie 中保存的单点登录会话令牌身份仍然存在， 只 是与该令牌相关的会话信息已经在 AM 中删除。 上述单点登录会话的生命期由 AM 进行管理， 会话的生命期特性可以通过配置 选项进行定制。在 AM 中，与单点登录会话相关的属性是通过“会话”服务 （session service）进行管理的，这些可配置属性均为动态类型的属性，可 以针对组织、角色和服务配置，并可被继承。会话的可配置属性如下表所示： 单点登录会话属

55、性 说明 最长会话时间（分 单点登录会话有效的最长时间，超过该时 钟）间，用户必须重新登录创建新的单点登录会 话。 最长空闲时间（分 当用户没有任何动作时，单点登录会话有效 钟）的最长时间，超过该时间，则会话失效，用 户必须重新登录创建新的单点登录会话。 最长高速缓存时间 单点登录会话信息在客户端高速缓存中保 （分钟）存的最长时间，超过该时间，则客户端必须 访问服务器以刷新缓存中的会话信息。 通过 AM 的 Web 控制台可以管理单点登录会话。 在 Web 控制台的“当前会话” 页面显示了当前所有有效的单点登录会话的状态，管理员能够有选择性地终 止单点登录会话。 . 认证方式设计

56、 单点登录系统采用认证方式与登录方式分层的设计，可平滑扩展多种登录方 式，如用户名口令、证书、智能卡等，支持多级登录认证机制。 为防止暴力破解，提供附加图像码的方式增加安全性。 .1. 用户认证方式 认证方式 单点登录系统提供了多种内置的登录方式。 1、LDAP 认证方式 单点登录系统提供的缺省认证方式。 使用 LDAP 认证方式， 用户名与口令存储 在指定的 LDAP 目录中。 当一个用户登录时， 提供的用户名与口令若与该 LDAP 目录中指定子树中某一个用户记录的用户名与口令相同，则认证成功，登录 者具有 LDAP 目录中该用户记录对应的身份。 2、自注册认证方式 允许用户在

57、认证时选择“新建用户”，并输入用户名与口令，建立自已的用 户帐号。 随后就可以像 LDAP 认证方式一样使用用户名与口令登录系统。 自注 册用户的资料也存放在 LDAP 中， 但可以为自注册用户指定不同于用户的存放 位置。 3、数字证书认证方式 使用 X509v3 数字证书，只要客户端可以提供 X509v3 数字证书，系统允许其 登录。可以配置用户的个人数字证书必须和目录服务器中存储的证书相同， 并与证书回收列表（CRL）比较以确保个人证书是有效的。 4、RADIUS 认证方式 系统利用外部的拨号认证系统作为本身的认证机制，如果用户通过了外部拨 号认证系统的认证，系统则认为此用户认证通过。 5、UNIX 认证 系统利用所安装 UNIX 环境的认证系统作为本身的认证机制， 如果用户通过了 UNIX 认证系统的认证，系统则认为此用户认证通过。 6、Microsoft Windows 域认证 系统使用 Windows 域认证系统作为本身的认证机制， 如果用户通过了它的认 证，则认为此用户认证通过。 7、SafeW