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

智慧校园软件解决方案白皮书目录1.总体框架32.技术路线42.1.编程语言52.2.面向对象的组件技术52.3.应用程序的开发与运行结构52.4.动态网页生成技术63.信息标准和规范系统64.基础支撑平台84.1.统一身份认证系统84.1.1.设计要点84.1.2.系统框架94.1.3.统一授权管理164.1.4.单点登录服务254.1.5.系统部署说明384.1.6.平台可靠性和扩展性404.2.统一信息门户平台404.2.1.设计要点404.2.2.平台框架414.2.3.门户运行环境414.2.4.平台主要功能424.2.5.平台部署及性能说明454.2.6.平台可靠性和扩展性说明474.2.7.平台安全性考虑474.3.数据中心平台484.3.1.技术路线504.3.2.设计要点504.3.3.平台框架524.3.4.应用集成与数据集成534.3.5.数据交换机制554.3.6.平台部署及性能说明591. 总体框架亿阳信通智慧校园总体框架如图所示：该框架以“师生”为核心，围绕智慧校园的资源、管理和服务三要素，依托数据中心及应用支撑平台，重点建设校园资源中心、校园管理中心、校园服务中心应用系统，形成数字化的教学环境、科研环境和生活环境。2. 技术路线智慧校园应用系统应采用成熟先进的技术规范，设计上尽量减少各子系统间的相互依赖性（包括软件对平台、软件对数据、软件对软件、平台对平台等），某个子系统的减少、增加和变更，不影响其它子系统和整体，从而最大限度地保护既有投资，减少系统的维护量和再投入。在应用系统整体化、模块化和规模化的同时，保证应用系统在技术上、经济上的可持续发展。亿阳信通智慧校园软件系统遵循如下技术路线：1、 采用“跨平台”的编程语言。2、 采用独立于开发环境的面向对象的组件技术，如EJBs (Enterprise Java Beans)，整个系统的主要“应用逻辑”由组件构成，系统架构提供了良好的伸缩性，使系统能够轻易地组合与拆分各功能模块。3、 应用软件平台的开发及运行架构采用三层结构，即 Web服务器、应用服务器和数据库服务器，在不影响系统其它部分的情况下，保证了应用服务器与其它应用有效和无缝的整合，同时支持大规模的并发用户访问。4、 采用模版（Template) 技术生成动态网页，为用户提供基于角色和权限的内容和数据服务。架构实现采用Java语言和EJBs技术，在数据交换上支持XML，使系统功能最优化，同时将系统内部的相互依赖性减至最低。2.1. 编程语言遵循J2EE (Java 2 Enterprise Edition)规范 ，采用Java语言和服务器端Java技术（包括EJBs、 Servlet、JNDI、 JDBC和RMI等）开发系统。Java作为Web应用的事实标准，其独立于操作系统和服务器的“跨平台性”，使其“一次编写，到处运行”，是WEB软件系统最适合的编程语言。相对于嵌入HTML、受限于用户端显示、编程能力有限的脚本语言，Java能力完整，可以开发具有强大“业务逻辑”的大型应用系统。2.2. 面向对象的组件技术软件编程由依赖于特定单机，到依赖于操作系统，已发展到今天面向对象的组件技术。面向对象的组件技术是一种完全独立于硬件和操作系统的开发环境，着重于应用程序“业务对象”的可重复使用组件，利用这些组件，可以像搭积木一样的建立分布式应用系统。面向对象的组件技术在异构、分布环境下为不同机器上的应用提供了互操作性，并无缝地集成了多种对象系统；另一方面， 组件大大加快了软件开发的速度，降低了软件开发和再开发的成本。2.3. 应用程序的开发与运行结构开发及运行结构基于三层架构，即Web服务器、应用服务器和数据库服务器。运用这种架构可以：（1）将“业务逻辑”从Web服务器中分出，在应用服务器中用独立和完整的编程语言而不是“脚本语言”开发应用程序，同时使系统支持任何HTML的显示工具；（2）应用服务器可以作为数据库访问请求的“缓冲区”，可以重新安排、管理数据库访问。通过Java Servlets引擎的多线程处理，能够极大地提高系统响应性能和数据库访问效率；（3）应用服务器可以作为与其它应用程序集成的结合点，在不影响系统其它部分的情况下与其它应用有效、无缝集成。2.4. 动态网页生成技术信息发布采用基于模版的动态网页生成技术。用户界面的版面和显示效果由预先制作的模版实现，并支持任何标准化的HTML工具，嵌入模版的Java程序根据用户的角色和权限提取相应的内容和数据，配合模版自动合成针对用户的个性化的动态网页。3. 信息标准和规范系统信息标准是智慧校园建设的重心，是学校各信息系统进行数据采集、处理、交换、传输的前提，也是构建新应用需要遵循的标准。亿阳信通按以下原则建设智慧校园的信息标准：l 唯一性：标准采用树形体系结构，唯一的项、唯一的路径、唯一的编码。l 规范性：充分参照国家相关最新标准、教育部教育管理信息化标准、北京市教委相关标准和各区县教委相关标准。l 适用性：标准的制定充分考虑学校的实际情况，以应用为目标。l 兼容性：对标准实行版本化的维护管理。高版本兼容低版本。同一个版本，维护其不同内容的一致性。学校校内标准兼容教育部及其它管理部门的标准，方便数据上报。l 可管理性：系统提供数据标准集、数据代码集、自定义代码集、数据代码映射等提供B/S架构的可视化管理工具，具备初始化、新增、删除、修改等维护功能，支持分类检索、输出、数据展示等浏览功能。l 可扩展性：支持标准的增加和变更，具有维护记录和回溯功能，并且对应用该标准的业务系统透明。所有历史版本可查询，可比较差异。管理信息标准的体系结构包括以下几个方面：一组相关数据元的集合，对数据元属性的规范描述（又称之为元数据标准化），属性包含了数据项名称、中文简称、类型、长度、可选性、取值范围等。为了确保数据录入规范、便于查找和统计，每个管理子集都对应着相应的标准代码，代码分国家标准、行业标准和学校标准。 系统遵循国家教育管理信息系统互操作规范，能够与北京市教委制定的小学应用互操作框架（简称CIF）无缝对接，实现各业务系统间规范的数据共享。CIF实现规范也定义了基于XML标准的CIF数据模型，支持小学数据对象在应用系统间的共享。 “教师”和“学生”是智慧校园系统涉及的两大数据对象，业务数据实体主要由这两大对象映射产生。通过“教师”对象产生的数据实体主要有教案、作业、教学成绩、教学计划等一系列和教师教育教学活动相关的数据；通过“学生”对象产生的数据实体主要有考试成绩、课堂表现、获奖、毕业去向等一系列和学生学习成长相关的数据。这些数据存储在智慧校园的数据中心，通过综合统计分析，又产生大量的衍生数据，如教师分布情况、学生分布情况、考试成绩综合统计分析等，这些数据可以为学校的管理层提供微观和宏观的决策支持，使领导能够直观的了解各个部门乃至整个学校的运行状况。具体数据模型框架如下图所示：4. 基础支撑平台4.1. 统一身份认证系统应用系统如果采用各自独立的身份认证机制，用户就要记忆不同系统中的账号/密码。为方便师生使用，解决多应用带来的多账号问题，需要建立统一的身份管理平台，用户在平台上登录一次就可以访问所有具有权限的应用。统一身份认证以IDM/IM（身份认证管理）为基础提供安全的用户身份管理功能，并配合Access Manager 基于代理架构的访问控制，提供Web应用的单点登录和Web应用保护。IDM/IM都集成了Directory Server(LDAP)目录服务器来存储统一身份库信息。统一身份认证实现的功能如下：1.建立统一的集中身份库统一身份数据中心，对各应用系统的所有用户提供集中和统一的管理，同时根据各个业务应用系统的认证方式的不同提供灵活的认证机制；2.在集中身份库的基础上，在满足数字校园管理平台信息系统内部业务流程规则的前提下，通过身份管理技术实现身份库与各个业务应用系统(门户、OA、教学、教务等系统)用户身份信息的自动同步处理功能；3.在集中身份库的基础上，提供单点登录(SSO)功能，用户只需要通过一次身份认证就可以访问具有权限的所有资源。集中身份库与门户系统的统一可以为整个平台提供集中的管理、安全机制，实现整体的统一。..1. 设计要点l 支持用户数据的集成，适应中小学用户数据分散管理的现状l 支持用户数据存储模式，适应中小学教职工多重身份的现状l 支持多种认证方式，确保异构业务系统能够集成，让用户获得完整的单点登录体验l 满足不同用户或系统的认证安全需求l 保证身份认证平台的高可靠性和高性能前三个需求是身份认证平台发挥作用的基础，而随着应用集成的力度和广度的加大，后两个将是身份认证平台必须妥善处理的问题。校园应用功能多样、结构复杂，各应用系统的权限管理基本上采用分级授权的方式。身份认证平台可以采用统一的权限模型，供各应用系统使用，相应的权限数据既可集中管理也可分布式管理。从实践结果看，集中权限控制的效益并不明显，建议不强求集中控制，由各应用系统设计开发时按需选择。4.1.2. 系统框架身份认证平台主要包括以下三方面功能：l LDAP目录服务，支持海量用户数据的存储和管理l 高性能SSO(单点登录)身份认证服务l 开放的认证集成方式，支持不同开发语言和不同应用服务器平台的业务系统. 统一身份管理架构学校的各种应用系统通常都有自己独立的用户管理、用户认证和授权机制，导致系统间互不兼容；学校的组织机构也不断变化，用户来源日趋复杂，角色多样化和角色变化等问题不断出现。各方因素交织在一起形成了一个庞大的矩阵，为统一的身份管理带来了困难。如图：针对上述问题，建立一个统一的，基于业界标准（如LDAP，XML，Web Service，J2EE等）的，灵活、开放、可扩展性的身份管理框架是最终的解决方案。一个好的身份管理解决方案将复杂的身份管理问题变得简单、实用。身份认证平台核心结构如下图所示：身份认证平台管理用户在各个应用系统中的用户信息的对应关系，并根据这一关系管理用户在各个应用系统中的生命周期，如添加、删除、修改等。身份认证平台的身份同步工具可以自动发现某个应用系统中用户信息的变化并通过一定规则，保持和其它应用中的用户信息同步。身份认证平台的核心包括用户信息创建和中止的审批流程，该流程由管理员预先定义，可以修改。当用户帐户的申请被批准后，用户帐户将根据预先定义的规则在中央主目录服务器中创建，并通过资源适配器在各个该用户可以使用的应用系统中产生帐户信息。用户帐号的中止也是同样原理。身份认证平台具有口令管理功能，支持口令策略管理和口令历史记录，支持用户身份审计和用户帐户风险分析，支持用户身份管理系统运行的监测、评估。. 用户数据模型身份认证平台中的数据模型包括：1.用户帐号：学生、教职员工、合作伙伴、供应商等帐户信息；2.资源：身份认证平台所管理的身份数据源和应用系统，如学生数据中心、教职工数据中心、电子邮件、一卡通、综合网络管理系统以及上网认证系统、VPN系统等，以及其它基于用户属性更改的应用；3.资源组：按一定顺序组织的资源，身份认证平台将根据这一顺序在应用系统中创建和删除用户信息；4.组织：管理一组用户、资源和其它对象的逻辑容器；5.角色：用户的工作角色，代表其职能性质，据此在资源中设置用户的属性；6.管理帐户：具有管理员权限，可以进行分级管理；7.能力：拥有哪些权限，如口令管理员只能管理用户的口令。下图为数据模型图：身份认证平台：1. 管理用户访问一个或多个资源的权限；2. 管理用户在这些资源上的帐户数据；3. 赋予用户一个或多个角色，设置用户访问各种资源的权限；4. 管理组织，决定用户帐户由谁和怎样被管理。用户数据是动态的，依赖于用户的角色、资源和资源组。根据角色（可以是多角色）赋予的资源的数量和类型，需要不同的信息表示，也决定着创建用户时的信息数量。身份认证平台有虚拟用户的概念，主要作用是映射用户到多个资源，可以将一个用户在多个应用系统中的全部帐户信息作为一个实体来管理。. 用户数据管理身份认证系统需要提供多样化的用户数据管理方案。用户数据采集可以根据学校现状，采用以下方式：1、集成管理着权威用户数据的业务系统，依赖该系统进行用户数据管理2、通过数据集成平台双向同步用户数据3、通过身份认证平台的用户管理程序管理用户数据. 身份数据集成统一身份认证系统集成用户身份数据的过程，是通过数据交换平台从学校的各个业务系统中自动抽取用户身份数据，并加以归纳和整理，最终充实用户身份信息库。. 自动发现和动态同步身份认证平台可以自动发现所管理资源中用户信息的更改，并根据规则将其同步到其它资源中去。. 帐号和口令管理身份认证平台提供了统一的WEB管理界面，可以方便地管理帐号和口令。帐号管理功能包括：1. 用户自注册功能：用户使用公共的帐号/口令登录系统，然后自行注册一个账号/口令。2. 帐号新建功能：外来人员如需临时帐号，可以由管理员手工生成访问身份，这个访问身份通常是帐号/口令，也可通过多因子认证或数字证书实现。这些临时帐号需要有效期限制，在“临时”的这段时间内有效，过期则失效；对于可转为正式帐号的“临时帐号”，可自动转换。3. 帐号注销功能：在一定条件下，实现用户帐号的注销。用户帐号注销后，所有的用户权限失效。4. 帐号冻结功能：暂时中止用户的访问权限，在用户需要开通时可以重新恢复，这样用户可以继续使用原来的帐号。口令管理包括：1. 自助式口令重置和同步2. 通过Web浏览器或者IVR（Interactive Voice Response，交互语音应答系统）系统来实现3. 自动口令策略执行4. 口令历史信息存储5. 口令过期通知等等。为满足用户个性化设置的需求，减轻管理员密码维护的压力，平台提供个人密码找回和别名登录功能，并开放给所有用户。个人密码遗忘后，用户可以在门户认证界面上使用密码找回功能，问题回答正确后，可以重新设置密码；用户登录后，可以根据自己的习惯设置登录别名，系统自动检查别名是否重复，别名设置成功后，用户可以使用别名进行登录。. 分级管理平台提供扁平的用户权限模型，提供分级管理功能。应用模式l 系统缺省建立四大类身份：领导、教职工、学生、校友；l 各应用系统按需建立自己的权限组或属性信息，也可复用其它系统已经建立的权限数据；l 权限模型支持分级授权，支持按组织架构、系统范围、用户属性等将权限管理工作分派给多名管理员；由于本功能在实际使用中容易导致管理混乱，一般建议只按照系统范围（如人事系统、学生系统等）来分级授权。l 用户数据采集时，自动根据用户的属性和来源为其设置相应的身份。. 批量维护工具满足管理员日常数据维护的需要，提供：l 批量导入用户数据、组织数据l 批量修改和删除人员属性信息l 高级查询功能l 系统服务的注册和注销l 在不同的人员容器间移动人员数据应用模式：l 教职工用户数据通过人事系统数据访问接口或用户数据表导入；l 管理员定期使用该工具完成教职工用户数据的导入；l 学生毕业转为校友后，管理员通过该工具将毕业生批量转入；l 系统运行准备阶段，管理员通过该工具完成批量用户密码初始化。. 与典型应用系统的集成身份认证平台的资源适配器采用服务器端的J2EE适配器，部署在身份认证服务端，即J2EE应用服务器上，然后根据所管资源的通讯协议和资源互通。对于大部分应用系统，无须在资源（即应用）一方安装任何代理。这样既对应用系统无影响，又避免了维护代理的工作。.1. 与LDAP目录服务器的集成身份认证平台和LDAP目录服务器的集成，如Sun Java System Directory Server是通过JNDI资源适配器完成的，在资源方无须代理。.2. 与采用LDAP目录服务的应用系统集成同上。身份认证平台通过其LDAP目录服务资源适配器和这些应用系统集成。.3. 与关系型数据库应用系统的集成如果应用系统的用户数据存储在关系型数据库中，应用系统和统一身份认证系统集成后，统一身份认证平台替代了应用系统的身份认证功能，该数据库中的用户信息将主要用于应用系统自身的授权和策略管理。身份认证平台主要集成关系型数据库中的用户信息表、权限信息表以及用户/权限对应关系表等，在身份认证平台上建立针对应用的数据库资源，并制定相应的用户信息映射和同步关系，通过该资源将相应用户信息创建到数据库中。身份认证平台和关系型数据库的集成是通过身份认证平台提供的JDBC（Java Data Base Connectivity，Java数据库连接）资源适配器完成的，并在资源方无须安装任何代理。.4. 资源适配器的开发身份认证平台为创建定制化的资源适配器提供了工具和文档支持。开发工具包包括：1. 指南性文档资料：功能定义、README文件等2. Javadoc：提供身份认证平台的API信息3. Jar文件：用于编译、连接4. 样本源代码等。4.1.3. 统一授权管理策略与权限管理模块是多用户应用系统不可或缺的。通常，策略与权限管理模块以应用专有的方式实现，系统的策略模型、策略存贮结构与访问控制逻辑与应用的业务逻辑之间耦合紧密。这种方式的缺点是显而易见的：由于策略模块与应用逻辑之间的紧耦合使得策略模块很难进行扩展与维护；策略模块的设计与编码需要很大的工作量，而且很难在不同的应用系统之间共享与重用。为了克服专有方式的缺点，统一用户管理与认证平台在基础设施层提供了增强的策略服务，提供标准、通用、灵活和可扩展的策略模型，支持策略的定义、存贮、配置与判定，并与用户管理和服务管理紧密集成。. 统一授权平台的架构统一授权平台的架构如下图所示。图中以灰色表示的组件是应用相关的部分，需要进行定制设计与开发；其余组件均由统一授权平台提供。总体而言，策略与权限管理模块的架构基于PDP/PEP模型。PDP代表策略判定点(Policy Decision Point)，是策略的提供者；PEP代表策略执行点(Policy Enforcement Point)，是策略的使用者。该架构中，统一授权管理提供PDP服务，包括策略的定义、存贮、配置与判定，这些服务通过策略判定API与策略管理API向外部应用提供；PEP是应用中根据策略判定结果执行应用逻辑的部分。PDP与PEP之间可以通过Java/C+ API或XML/HTTP通信。由于统一授权管理提供的策略判定结果是原始结果，为了进一步简化应用中的策略执行逻辑，引入应用策略判定接口，对统一授权管理的策略判定接口进行封装，对原始策略判定结果作进一步加工与处理。统一授权管理支持通过策略主体SPI（服务提供者接口）、策略条件SPI、策略推荐SPI与资源名称SPI进行扩展。策略的存贮结构通过LDAP中的对象类与属性类型加以定义；策略存贮在目录服务器中。. 策略模型统一授权管理的策略服务建立在通用、灵活和可扩展的模型上。正是该策略模型使其能在基础设施层以一种应用无关的方式提供强大的策略服务。一般而言，作为访问控制规则的策略描述了“谁在何种情况下针对指定服务对何种资源可执行怎样的操作”。在这里，“谁”是策略的主体；“情况”是策略适用的条件；“服务”是策略的上下文，“资源”与“操作”都是与该服务相关的；“资源”是策略的对象；“执行怎样的操作”可以表示为一系列“动作”及与之对应的“值”。基于单点登录系统的策略模型提供了充分的表达能力，允许准确描述如上的通用策略。统一授权管理的策略采用XML来描述。为简明起见，在此以半形式化的方式描述策略模型如下：常规策略 := 主体集 + 条件集 + 规则集主体集 := 主体条件集 := 条件 规则集 := 规则主体 := Access Manager 角色集| LDAP 组集| LDAP角色集| LDAP用户集|LDAP组织集条件 := 认证级别|认证方式|客户IP |时间规则 := 服务 + 资源名称 + 动作类型-值对集资源名称 := 字符串动作类型-值对集 := 动作类型-值对动作类型-值对 := 动作类型 + 值备注：1、统一授权管理的策略包括推荐策略与常规策略。由于推荐策略只是将策略推荐给对等组织或子组织进行判定，而不涉及策略的具体判定，因此此处不对推荐策略进行详细描述。2、统一授权管理提供的主体插件SPI、条件插件SPI和资源名称插件SPI允许扩展主体、条件与资源名的表达能力，上述描述中主体、条件与资源名称只是由系统提供的标准实现。. 策略编程接口应用系统访问身份认证平台可以使用Java API接口，也可以使用XML/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 API接收并解释策略决策XML文档；(6)应用系统通过Java API获取策略决策信息。从上述流程可知，策略验证的结果是以策略决策的形式表现的。如果使用XML/HTTP接口，则策略决策是一个XML文档；如果使用Java API接口，则策略决策是一个Java对象。策略决策中包括一组动作决策，动作决策是关于某个具体动作的决策，其中包括：（1）动作的值：与该动作相关的决策的值；（2）有效时间（TTL）：决策值在多久时间内有效；（3）建议：该动作决策的描述信息。动作的值可以是布尔类型的，表示是与否、允许或禁止等两值类型的动作决策；动作的值也可以是复杂类型的，如字符串、数值等，可以用来表示动作的程度、范围等决策概念，诸如邮箱配额、折扣率等。可能有许多策略适用于一次策略请求，不同的策略可能相互冲突。比如，用户拥有的角色允许他访问某个URL，而用户所属的组禁止他访问某个URL；再比如，用户拥有的一个角色给予他20M的邮箱配额，而用户拥有的另一个角色给予他10M的邮箱配额。这种不同策略同时适用，而且决策值不同的情况称为冲突。冲突的策略决策必须消解之后才能用于权限控制。系统是这样消解策略决策冲突的：(1)如果动作值的类型是布尔类型，则所有策略的决策值在执行AND操作之后返回，返回的值是单值。也就是说，只要有一个策略的动作决策是false，则动作的决策值就为false；(2)如果动作值的类型是复杂类型，则所有策略的决策值全部返回给应用系统，由应用系统对决策值进行进一步的冲突消解。策略的管理包括创建、删除和修改策略。用户可以通过系统的WEB控制台界面或命令行界面管理策略。如果在应用系统中需要对策略进行管理，可以使用系统的策略管理API。. 应用策略的设计一个应用系统是建立在多种平台服务之上的，并且向用户提供多种用户服务；而一个平台服务也应该为多个应用系统使用。因此应用系统与服务之间是多对多的关系。由于服务是应用的组成元素，因此，授权应该是针对服务的资源而不是应用的资源来进行的。不同的服务具有不同的资源和动作类型，因此，不同的服务有不同的策略模板，该模板称为策略方案（Policy Schema）。服务与策略方案之间的对应关系应该是一对一关系。配置策略、验证策略是通过指定服务来指定策略方案的。一条具体策略规定了一组主体在一组条件下的一组访问控制规则。每条规则中均指明了一个服务、属于该服务的资源以及一组动作与值对。每个策略方案也可以被多条策略使用。因此，策略与策略方案之间的对应关系应该是多对多关系。由于服务与策略方案之间是一一对应的，因此，定义策略方案是在定义服务的同时进行的。只有当服务定义之后，才能定义与该服务相关的具体策略。从身份认证平台服务管理的角度，服务是一组定义在一个公共名字下通过身份认证平台管理的属性的集合。身份认证平台将服务作为一组属性进行管理，而并不关心这些属性的具体涵义。服务的属性集合是通过一个XML文件加以定义的。身份认证平台提供了大量的平台服务，这些服务本身也是通过系统的服务管理功能加以管理的，因此，这些平台服务也有对应的XML定义文件，并且服务的选项也是通过服务的属性加以管理的。为了使服务能够针对不同的用户、角色或组织等身份实体进行定制和个性化，身份认证平台将服务的属性分为以下五种类型。不同类型的属性具有不同的作用域、继承性、用途。类型作用域继承性用途全局整个统一授权系统不可继承服务的全局配置组织应用于组织不可继承服务的组织级配置动态应用于角色、用户可继承服务的动态配置，配置给角色的属性自动为所有具有该角色的用户拥有，配置给组织的属性自动为所有该组织下的用户拥有。策略N/AN/A与服务授权相关的配置用户只应用于用户不可继承服务针对于每个用户的个性化配置。用户类型的属性只对个别用户有意义。. 角色与用户组管理角色是和用户组的概念相似的目录服务器对象管理机制。一个组有其成员；一个角色也有其成员。在身份认证平台中，用户角色的权限是通过为其设定ACI（Access Control Infromation）来控制的。访问控制指令可以控制对整个目录、目录子树、目录中特写条目（包括定义配置任务的条目）或特定条目属性信息的访问权。可以设置特定用户、所有属于特定组或角色的用户或所有目录用户的权限。还可以定义对特定位置（例如IP地址或DNS名称）的访问权。与条目属性一样，访问控制指令存储在目录中。ACI属性是一种操作性属性，可用于目录的各个条目，而不管是否为该条目的对象类所定义。接收到客户端的LDAP请求时，目录服务器使用该属性来允许或拒绝访问。如果有特别请求，则在ldap search操作中返回ACI属性。在平台中可以定义特定的角色，并利用ACI来控制其访问权限。这样做可以满足一些特殊需求。利用组织内创建用户时可以拥有默认角色的机制，可以为不同的组织创建不同的默认角色，这样新建的用户就自然拥有了这些角色所拥有的属性和服务以及相应的权限。组代表了具有相同功能、属性或者兴趣爱好的用户的集合。一般来说，组没有自己的特权。组可以定义在组织机构下，也可以定义在别的受管组（Managed Group）内作为子组。身份认证平台提供了组的分级管理的能力。虽然组的成员缺省来自于整个用户树，但是对于权限有限的组管理员来说，当他管理一个预订组的时候，他只能把他自己能管理的用户添加到新创建的预订组中。在这里已经部分实现了用户组的分级管理。在业务系统一级授权上，我们提供了全局权限组用于人员的初始化授权。这些组按照用户基本身份建立（比如学生组、教职工组），作用域为整个组织树，在人员的初始时可以按照身份加入这些全局组，从而实现人员权限的初始化。. 权限语义集成当身份认证平台的策略服务不能满足业务系统授权要求时，我们提供了一种针对业务系统开放的完全自由的权限语义集成机制。权限语义描述了用户的具体应用权限，权限语义的具体描述和解析由业务系统负责。业务系统可以通过API来获取这些语义，解析后授予用户相应的权限。. 用户数据采集功能描述针对学校用户管理分散进行的特点，提供从权威数据源采集用户数据，并实时更新目录服务器中的用户数据，提供：l 数据源采集点和采集周期定义l 数据源变化跟踪和自动采集应用模式建立从公共数据库平台相关的共享数据集采集，在学生和教职工用户数据变更(包括新增、删除、修改)后，采集模块自动同步更新统一认证用户数据库。用户数据通常分散在不同的应用系统中。常见的情况是：人事系统管理人事信息；办公系统管理与日常工作有关的信息；用户的认证信息如用户ID和密码在各个系统中一般不同，由各个系统分散管理；用户的基本属性，如姓名等信息往往在各个系统中都存在。不同应用系统不但管理不同类型的用户数据，而且也提供不同类型的数据存储与访问方式。传统的业务系统一般使用关系数据库存放用户数据，如管理信息系统；互联网应用系统一般使用LDAP存放用户数据，如电子邮件系统。不同类型的数据存储方式具有不同的数据存储格式，也提供不同的数据访问接口。用户数据的分散存储与管理使得共享用户数据成为复杂而低效的任务。建立统一用户管理数据库的目的是为用户信息的管理与使用提供统一的入口。统一用户管理数据库在物理上与其它应用数据源独立，在数据上与其它应用数据源保持同步。用户管理数据库变更后同步到LDAP目录数据库。. 用户数据发布功能描述为了保持各业务系统中用户数据的完整性和统一性，向各集成业务系统提供用户身份数据。应用模式l 对目前已有系统提供用户数据更新变更同步l 提供用户信息的浏览、排序、查询等管理功能l 由于中小学用户数据分散管理，在权威数据源变更后，其他系统都可通过统一用户管理数据库同步数据变更，保持数据的完整与一致. 批量维护工具功能描述满足管理员日常维护数据的需要，提供：l 导入用户数据和组织数据l 批量修改和删除人员属性信息l 高级查询功能l 服务注册与注销l 在不同的人员容器间移动人员数据应用模式l 教职工用户数据由人事系统提供数据访问接口或用户数据表l 管理员定期使用该工具完成教职工用户数据导入l 在学生毕业转为校友后，管理员通过该工具将毕业生批量转入l 系统运行准备阶段，管理员通过该工具完成用户密码的批量初始化0. 个人自助服务功能描述为了满足用户个性化设置并减轻管理员的维护工作量，平台提供个人密码找回、别名登录功能。应用模式l 该功能开放给所用用户；l 用户遗忘个性化设置的密码后，可以在门户认证界面上进入密码找回功能，预设问题回答正确后，可以自主重置密码；l 用户登录后，可以根据自己的习惯设置登录别名，系统自动检查别名是否重复，别名设置成功后，用户可以通过别名进行登录。1. 权限模型功能描述为了适应中小学用户多重身份和组织结构易变的特点，同时最大限度的保证用户认证效率，平台提供扁平的用户权限模型。应用模式l 系统将缺省建立四大类身份：教职工、学生、领导、校友；l 各应用系统按需建立自定义的权限组或属性信息，也可复用其他系统已经建立的相关权限数据；l 权限模型支持分级授权，方便按组织架构、系统范围、用户属性等特征将权限管理工作逐级分派给多名管理员；该功能在实际使用中容易导致管理混乱，一般建议只按照系统范围（如人事系统、学生系统等等）来分级授权。l 用户数据采集时，自动根据用户的属性和来源为用户设置相应的身份。2. 认证集成功能描述满足学校业务系统多元化特点，提供：l 支持基于认证接口、认证代理和LDAP认证的多种认证集成模式l 支持密码认证l 支持与标准的主流Radius服务器集成l 预留CA认证扩展接口l 预留SmartCard、JavaCard认证扩展接口l 预留与网络接入认证设备用户认证模块的集成接口，实现与网络接入认证设备的认证集成应用模式l 业务系统全部采用基于认证接口的认证集成方式；l 用户统一采用基于密码认证的登录方式。4.1.4. 单点登录服务单点登录（Single Sign On，SSO）通常定义为指用户只需经过一次认证就可以访问所有拥有访问权限的应用系统。单点登录能够提高用户的工作效率，减少身份认证过程中的人为错误，也减轻了用户在密码管理上的负担，从而使系统更安全、更易用。身份认证平台提供了单点登录解决方案，用户只需通过系统的认证，并且具有足够的权限，就可以访问所有由身份认证平台管理的应用系统。统一认证服务是单点登录支持的基础，没有统一认证，就没有真正的单点登录。校园网通常运行多个应用系统，为学校领导、各部门及教生提供多种服务，这样就带来了一个突出的问题，用户面对多个系统时要记忆、输入帐号/口令等信息，不仅烦琐，而且容易丢失口令，一旦口令泄漏会造成不可估量的损失。单点登录系统的建设目标是要解决各应用系统用户名和口令不统一的问题，期望提供一套方便、安全的口令认证方法，让用户只要一个用户名和口令就可以使用网络上他有权使用的所有业务系统。. 设计要点单点登录系统设计的要点如下：l 遵循LA（Liberty Alliance，联合互信）的ID-FF V1.2规范。l 支持SAML（Security Assertion Markup Language）安全性断言标记语言规范。l 支持多种多级登录认证机制，如用户/密码、动态口令等。l 支持系统的认证过程支持加密的认证方式。l 系统支持基于用户UID和密码的身份认证。l 提供用户密码加密功能，支持SSHA、CRYPT、SHA等加密算法。l 通过TLS（Transport Layer Security，传输层安全协议）或SSL（Secure Sockets Layer，安全套接层协议）为信息传输提供保密性和完整性保护。l 支持X.509协议，可以对数字证书、公共密钥、数字签名进行存储和管理。l 支持跨域的单点登录功能。. 系统原理与体系结构单点登录系统的根本原理是保持用户的会话（session）状态。用户经过一次认证就可建立单点登录会话，每个单点登录会话对应于一个令牌（token），用户访问应用系统时向应用系统传递单点登录令牌，应用系统能够根据令牌识别用户的认证状态，从而使一次认证能够被多个应用系统认可，避免了重复认证。我们采用Sun Java System Access Manager（简称AM）作为单点登录的底层技术平台。根据上述原理，AM对单点登录提供SDK级别的支持，其中包括单点登录令牌的创建与验证。以WEB应用的单点登录为例：用户通过AM的认证页面进行认证，认证通过之后，平台为该用户创建一个单点登录令牌，并将该令牌的ID通过cookie返回至用户浏览器；当用户访问WEB应用系统时，单点登录令牌ID自动通过cookie传递至WEB应用系统，WEB应用系统可以通过单点登录令牌ID还原单点登录令牌，并向Access Manager验证单点登录令牌是否有效。如果有效，则应用系统可以从单点登录令牌获取用户身份信息，而不再需要用户进行再次认证。对于C/S结构的应用，单点登录过程是类似的，只是单点登录令牌ID的传递方式不同。上述单点登录SDK的体系结构如下图所示：如前所述，单点登录是通过单点登录会话实现的，通过单点登录会话保持用户在整个平台的认证状态。在对用户进行身份验证之前，AM的会话服务先产生令牌，令牌包含一个随机生成的会话标志并且会作为这次会话的最终标志。令牌一旦生成，AM会将它插入一个Cookie，并且颁发给用户的浏览器。与此同时，AM会根据用户所使用的验证方式，提示不同的登录界面，验证方式可预先为组织、角色或单个用户进行配置。当用户接收到登录界面时，同时也获得一个会话令牌，用户会键入用户名和密码，登录资料被提交给适当的验证服务器(如LDAP、RADIUS等)，一旦用户通过了身份验证，AM会从cookie中提取用户的令牌，并且将其状态设置为有效的，接着将用户重新定向到所要访问的URL。单点登录会话具有如下图所示的生命周期：如图所示，单点登录会话的初始状态是无效，表示单点登录会话虽然已经创建并被分配给用户，但用户尚未通过有效认证。无效的单点登录会话也通过一个单点登录会话令牌身份，并存储在用户浏览器的cookie中。当用户认证成功之后，单点登录会话变为有效状态。该单点登录会话仍以同一个单点登录会话令牌身份，用户浏览器中的cookie不变，只是服务器维护的会话状态变为有效。单点登录会话可以因为以下原因而销毁：1. 客户端空闲时间达到最大空闲时间；2. 会话时间达到最大会话有效时间；3. 由于用户登出而显式销毁会话；会话销毁之后，客户端cookie中保存的单点登录会话令牌身份仍然存在，只是与该令牌相关的会话信息已经在AM中删除。上述单点登录会话的生命期由AM进行管理，会话的生命期特性可以通过配置选项进行定制。在AM中，与单点登录会话相关的属性是通过“会话”服务（session service）进行管理的，这些可配置属性均为动态类型的属性，可以针对组织、角色和服务配置，并可被继承。会话的可配置属性如下表所示：单点登录会话属性说明最长会话时间（分钟）单点登录会话有效的最长时间，超过该时间，用户必须重新登录创建新的单点登录会话。最长空闲时间（分钟）当用户没有任何动作时，单点登录会话有效的最长时间，超过该时间，则会话失效，用户必须重新登录创建新的单点登录会话。最长高速缓存时间（分钟）单点登录会话信息在客户端高速缓存中保存的最长时间，超过该时间，则客户端必须访问服务器以刷新缓存中的会话信息。通过AM的Web控制台可以管理单点登录会话。在Web控制台的“当前会话”页面显示了当前所有有效的单点登录会话的状态，管理员能够有选择性地终止单点登录会话。. 认证方式设计单点登录系统采用认证方式与登录方式分层的设计，可平滑扩展多种登录方式，如用户名口令、证书、智能卡等，支持多级登录认证机制。为防止暴力破解，提供附加图像码的方式增加安全性。.1. 用户认证方式认证方式单点登录系统提供了多种内置的登录方式。1、LDAP认证方式单点登录系统提供的缺省认证方式。使用LDAP认证方式，用户名与口令存储在指定的LDAP目录中。当一个用户登录时，提供的用户名与口令若与该LDAP目录中指定子树中某一个用户记录的用户名与口令相同，则认证成功，登录者具有LDAP目录中该用户记录对应的身份。2、自注册认证方式允许用户在认证时选择“新建用户”，并输入用户名与口令，建立自已的用户帐号。随后就可以像LDAP认证方式一样使用用户名与口令登录系统。自注册用户的资料也存放在LDAP中，但可以为自注册用户指定不同于用户的存放位置。3、数字证书认证方式使用X509v3数字证书，只要客户端可以提供X509v3数字证书，系统允许其登录。可以配置用户的个人数字证书必须和目录服务器中存储的证书相同，并与证书回收列表（CRL）比较以确保个人证书是有效的。4、RADIUS认证方式系统利用外部的拨号认证系统作为本身的认证机制，如果用户通过了外部拨号认证系统的认证，系统则认为此用户认证通过。5、UNIX认证系统利用所安装UNIX环境的认证系统作为本身的认证机制，如果用户通过了UNIX认证系统的认证，系统则认为此用户认证通过。6、Microsoft Windows 域认证系统使用Windows 域认证系统作为本身的认证机制，如果用户通过了它的认证，则认为此用户认证通过。7、SafeWord认证系统可使用Secure Computing的SafeWord或SafeWord Premier认证服务器。单点登录系统作为SafeWord服务器的客户端，SafeWord服务器可以安装在单点登录系统的同一台机器上，也可以安装在另外的系统中。8、RSA SecureID认证9、多因子认证除了上述内置的认证方式之外，平台也提供了服务提供者接口来开发定制的认证方式。认证方式个性化不同的认证方式具有不同的安全性、易用性和部署成本，因此，针对不同的用户群与不同的应用范围需要对认证方式进行个性化。在单点登录系统中，可以根据角色、用户、服务指定不同的认证方式，也可以在认证时直接指定认证模块。对于不同组织、角色和服务，可以配置个性化的认证选项。认证选项按照不同的认证方式通过单点登录系统的服务加以组织。单点登录系统为每种内置的认证方式定义了一个服务，并定义了一个核心认证服务，用于组织所有认证方式的公有属性。以下分述核心认证服务与支持的配置选项以及常用认证服务的配置选项。核心认证服务支持的配置选项分为全局选项与组织选项。全局选项在整个单点登录系统范围内适用，组织选项在组织级别进行配置，只对一个组织有效。.2. 用户认证界面用户认证界面是单点登录系统与最终用户的接口，它负责向用户显示登录表单，搜集用户认证信息，并传回服务器端；服务器端通过调用平台的认证API进行认证，并为通过认证的用户创建单点登录系统的单点登录会话。单点登录系统提供了基于WEB的用户认证界面，该用户认证界面是由单点登录系统动态生成的，提供了平台中所有认证模块的用户界面。单点登录系统的用户认证界面是基于JATO（J2EE Assisted Take-Off）WEB应用框架创建的，它通过JSP和XML为用户提供图形化界面的交互方式。对用户认证界面的常见客户化工作包括对认证界面上的文字信息和图片进行客户化，以及对用户认证界面进行本地化。认证界面是基于一组JSP模板和XML文件动态生成的。JSP模板定义了认证页面的布局，XML文件是认证模块的配置资源文件。缺省JSP模板和XML文件均位于位于IS_Root/SUNWam/web-apps/services/config/auth/default目录下。这些文件均可修改，使得不同的组织、子组织、地区、服务/应用、客户端类型具有不同的认证界面。. 认证接口设计单点登录系统提供了公共的认证服务架构，对外提供多种认证接