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

中小学智慧校园软件解决方案技术白皮书v2内容摘要：

执行逻辑，引入应用策略判定接口，对统一授权管理的策略判定接口进行封装，对原始策略判定结果作进一步加工与处理。 统一授权管理支持通过策略 主体 SPI（ 服务提供者接口 ） 、策略条件 SPI、策略推荐 SPI与资源名称 SPI进行扩展。 策略的存贮结构通过 LDAP 中的对象类与属性类型加以定义；策略存贮在目录服务器中。 18 . 策略模型 统一授权管理的策略服务建立在通用、灵活和可扩展的模型上。 正是该策略模型使其能在基础设施层以一种应用无关的方式提供强大的策略服务。 一般而言，作为访问控制规则的策略描述了“谁在何种情况下针对指定服务对何种资源可执行怎样的操作”。 在这里，“谁”是策略的 主体 ；“情况”是策略适用的条件；“服务”是策略的上下文，“资源”与“操作”都是与该服务相关的；“资源”是策略的对象；“执行怎样的操作”可以表示为 一系列“动作”及与之对应的“值”。 基于单点登录系统的策略模型提供了充分的表达能力，允许准确描述如上的通用策略。 统一授权管理的策略 采用 XML来 描述。 为简明起见，在此以半形式化的方式描述策略模型如下： 常规策略 ::= 主体 集 + 条件集 + 规则集 主体 集 ::= {主体 } 条件集 ::= {条件 } 规则集 ::= {规则 } 主体 ::= Access Manager 角色集 | LDAP 组集 | LDAP 角色集 | LDAP 用户集|LDAP 组织集 条件 ::= 认证级别 |认证方式 |客户 IP |时间 规则 ::= 服务 + 资源名称 + 动作类型 值对集 资源名称 ::= 字符串 动作类型 值对集 ::= {动作类型 值对 } 动作类型 值对 ::= 动作类型 + 值 备注： 统一授权管理的策略包括推荐策略与常规策略。 由于推荐策略只是将策略推荐给对等组织或子组织进行判定，而不涉及策略的具体判定，因此此处不对推荐策略进行详细描述。 统一授权管理提供的 主体 插件 SPI、条件插件 SPI 和资源名称插件 SPI允许扩展 主体 、条件与资源名的表达能力，上述描述中 主体 、条件与资源名称只是由系统提供的标准实现。 19 . 策略编程接口 应用系统访问身份认证平台可以使用 Java API 接口，也可以使用XML/HTTP 接口。 如果是远程访问，则 Java API 接口本身也是对 XML/HTTP 接口的一种封装。 远程客户端调用策略验证接口时的处理流程如下： (1) 应用系统调用 Java API 请求策略验证； (2) Java API 根据策略验证请求生成一个 XML 策略验证请求； (3) Java API 将 XML 策略验证 请求 通过 HTTP 协议发送给系统的 Policy 服务： % (4) 系统处理策略验证 XML请求，并创建一个策略决策 XML文档作为应答返回给客户端； (5) 客户端 Java API 接收并解释策略决策 XML 文档； (6) 应用系统通过 Java API 获取策略决策信息。 从上述流程可知，策略验证的结果是以策略决策的形式表现的。 如果 使用XML/HTTP 接口，则策略决策是一个 XML 文档 ； 如果 使用 Java API 接口，则策略决策是一个 Java 对象。 策略决策中包括一组动作决策 ， 动作决策是关于某个具体动作的决策，其中包括： （ 1）动作的值：与该动作相关的决策的值； （ 2） 有效时间（ TTL）：决策值在多久时间内有效； （ 3）建议：该动作决策的描述信息。 动作的值可以是布尔类型的，表示是与否、允许或禁止等两值类型的动作决策；动作的值也可以是复杂类型的，如字符串、数值等，可以用来表示动作的程度、范围等决策概念，诸如邮箱配额、折扣率等。 可能有许多策略适用于一次策略请求，不同的策略可能相互冲突。 比如，用户拥有的角色允许他访问某个 URL，而用户所属的组禁止他访问某个 URL；再比如，用户拥有的一个角色给予他 20M 的邮箱配额，而用户拥有的另一个角色给予他 10M 的邮箱配额。 这种不同策略同时 适用，而且决策值不同的情况称为冲突。 冲突的策略决策必须消解之后才能用于权限控制。 系统是这样消解策20 略决策冲突的： (1) 如果动作值的类型是布尔类型，则所有策略的决策值在执行 AND 操作之后返回，返回的值是单值。 也就是说，只要有一个策略的动作决策是 false，则动作的决策值就为 false； (2) 如果动作值的类型是复杂类型，则所有策略的决策值全部返回给应用系统，由应用系统对决策值进行进一步的冲突消解。 策略的管理包括创建、删除和修改策略。 用户可以通过系统的 WEB控制台界面或命令行界面管理策略。 如果在应用系统中 需要对策略进行管理，可以使用系统的策略管理 API。 . 应用策略的设计 一个应用系统是建立在多种平台服务之上的，并且向用户提供多种用户服务；而一个平台服务也应该为多个应用系统使用。 因此应用系统与服务之间是多对多的关系。 由于服务是应用的组成元素，因此，授权应该是针对服务的资源而不是应用的资源来进行的。 不同的服务具有不同的资源 和 动作类型，因此，不同的服务有不同的策略模板，该 模板 称为策略方案（ Policy Schema）。 服务与策略方案之间的对应关系应该是一对一关系。 配置策略 、 验证策略是通过指定服务来指定策略方案的。 一条具体策略规定了一组主体在一组条件 下 的一组访问控制规则。 每条规则中均指明了一个服务、属于该服务 的 资源以及一组动作与值对。 每个策略方案也可以被多条策略使用。 因此，策略与策略方案之间的对应关系应该是多对多关系。 由于服务与策略方案之间是一一对应的，因此，定义策略方案是在定义服务的同时进行的。 只有当服务定义之后，才能定义与该服务相关的具体策略。 从身份认证平台服务管理的角度，服务是一组定义在一个公共名字下通过身份认证平台管理的属性的集合。 身份认证平台将服务作为一组属性进行管理，而并不关心这些属性的具体涵义。 服务的属性集合是通过一个 XML文件加以定义的。 21 身份认证平台提供了大量的平台服务，这些服务本身也是通过系统的服务管理功能加以管理的，因此，这些平台服务也有对应的 XML定义文件，并且服务的选项也是通过服务的属性加以管理的。 为了使服务能够针对不同的用户、角色或组织等身份实体进行定制和个性化，身份认证平台将服务的属性分为以下五种类型。 不同类型的属性具有不同的作用域、继承性、用途。 类型 作用域 继承性 用途 全局 整个 统一授权系统 不可继承 服务的全局配置 组织 应用于组织 不可继承 服务的组织级配置 动 态 应用于角色、用户 可继承 服务的动态配置，配置给角色的属性自动为所有具有该角色的用户拥有，配置给组织的属性自动为所有该组织下的用户拥有。 策略 N/A N/A 与服务授权相关的配置 用户 只应用于用户 不可继承 服务针对于每个用户的个性化配置。 用户类型的属性只对个别用户有意义。 . 角色与用户组管理 角色是和用户组的概念相似的目录服务器对象管理机制。 一个组有其成员；一个角色也有其成员。 在身份认证平台中，用户角色的权限是通过为其设定 ACI（ Access Control Infromation）来控制的。 访问控制指令可以控制对整个目录、目录子树、目录中特写条目（包括定义配置任务的条目）或特 定 条目属性 信息 的访问 权。 可以设置特定用户、所有属于特定组或角色的用户或所有目录用户的权限。 还可以定义对特定位置（例如 IP 地址或 DNS 名称）的访问权。 与条目属性一样 ， 访问控制指令存储在目录中。 ACI 属性是一种操作性属性 ， 可用 于目录的各个条目，而不管是否为该条目的对象类所定义。 接收到客户端 的 LDAP 请求时，目录服务器使用该属性来允许或拒绝 访问。 如果有特别请求，则在 ldap search 操作中返回 ACI 属性。 在平台中可以定 义特定的角色，并利用 ACI 来控制其访问权限。 这样做可以满足一些特殊需求。 利用组织内创建用户时可以拥有默认角色的机制，可以为不同的组织创建不同的默认角色，这样新建的用户就自然拥有了这些角色所拥有的属性和服务22 以及相应的权限。 组代表了具有相同功能、属性或者兴趣爱好的用户的集合。 一般来说，组没有自己的特权。 组可以定义在组织机构下，也可以定义在别的受管组（ Managed Group）内作为子组。 身份认证平台提供了组的分级管理的能力。 虽然组的成员缺省来自于整个用户树，但是对于权限有限的组管理员来说，当他管理一个预 订组的时候，他只能把他自己能管理的用户添加到新创建的预订组中。 在这里已经部分实现了用户组的分级管理。 在业务系统一级授权上，我们提供了全局权限组用于人员的初始化授权。 这些组按照用户基本身份建立（比如学生组、教职工组），作用域为整个组织树，在人员的初始时可以按照身份加入这些全局组，从而实现人员权限的初始化。 . 权限语义集成 当身份认证平台的策略服务不能满足业务系统授权要求时，我们提供了一种针对业务系统开放的完全自由的权限语义集成机制。 权限语义描述了用户的具体 应用 权限，权限语义的具体描述和解析由业务系统负责。 业务 系统可以通过 API 来获取这些语义，解析后授予用户相应的权限。 . 用户数据采集 功能描述 针对 学校用户管理分散 进行 的特点，提供从权威数据 源 采集用户数据，并实时更新目录服务器中的用户数据，提供：  数据源采集点和采集周期定义  数据源变化跟踪和自动采集 应用模式 建立从公共数据库平台相关的共享数据集采集，在学生和教职工用户数据变更 (包括新增、删除、修改 )后，采集模块自动同步更新统一认证用户数据23 库。 用户数据 通常 分散在不同的应用系统中。 常见的情况是：人事系统管理人事信息；办公系统管理 与 日常工作有关的信息；用户的认证信息 如用户 ID 和密码在各个系统中一般不同，由各个系统 分散 管理；用户的基本属性，如姓名等信息往往在各个系统中都存在。 不同应用系统不但管理不同类型的用户数据，而且也提供不同类型的数据存储与访问方式。 传统的业务系统一般使用关系数据库存放用户数据，如 管理信息 系统； 互联网 应用系统一般使用 LDAP 存放用户数据，如 电子邮件 系统。 不同类型的数据存储方式具有不同的数据存储格式，也提供不同的数据访问接口。 用户数据的分散存储与管理使得共享用户数据成为复杂而低效的任务。 建立统一用户管理 数据库 的目的是为用户信息的管理与使用提供统一的入口。 统一用户管理 数据库 在物理上与其它应用数据源独立，在数据上与其它应用数据源保持同步。 用户管理数据库变更后同步 到 LDAP 目录 数据库。 . 用户数据发布 功能描述 为了保持各业务系统中用户数据的完整性和统一 性 ，向各集成业务系统提供用户身份数据。 应用模式  对目前已有系统提供用户数据更新变更同步  提供用户信息的浏览、排序、查询等管理功能  由于中小学用户数据分散管理，在权威数据源变更后，其他系统都可通过统一用户管理数据库同步数据变更，保持数据 的 完整与一致 . 批量维护工具 功能描述 满足管理员日常维护数据的需要，提供：  导入用户数据和组织数据 24  批量修改和删除人员属性信息  高级查询功能  服务注册 与 注销  在不同的人员容器间移动人员数据 应用模式  教职工用户数据由人事系统 提供 数据访问接口或用户数据表  管理员定期使用该工具完成教职工用户数据导入  在学生毕业转为校友后，管理员通过该工具将毕业生批量转入  系统运行准备阶段，管理员通过该工具完成用户密码 的 批量 初始化 . 个人自助服务 功能描述 为了满足用户个性化设置 并 减轻管理员的 维护工作量 ，平台提供个人密码找回、别名登录功能。 应用模式  该功能开放给所用用户；  用户 遗忘 个性化设置的 密码 后，可 以在门户认证界面上进入密码找回功能， 预设 问题回答正确后，可以自主重置密码；  用户登录后，可以根据自己的习惯设置登录别名，系统自动检查别名是否 重复，别名设置成功后，用户可以通过别名进行登录。 . 权限模型 功能描述 为了适应中小学用户多重身份和组织结构易变的特点，同时最大限度的保证用户认证效率，平台提供扁平的用户权限模型。 应用模式  系统将缺省建立四大类身份：教职工、学生、领导、校友；  各应用系统按需建立自定义的权限组或属性信息，也可复用其他系统25 已经建立的相关权限数据；  权限模型支持分级授权，方便按组织架构、系统 范围、用户属性等特征将权限管理工作逐级分派给多名管理员； 该 功能在实际使用中容易导致管理混乱，一般建议只按照系统范围（如人事系统、学生系统等等）来分级授权。  用户数据采集时，自动根据用户的属性和来源为用户设置相应的身份。 . 认证集成 功能描述 满足学校业务系统多元化特点，提供：  支持基于认证接口、认证代理和 LDAP 认证的多种认证集成模式  支持密码认证  支持与标准的主流 Radius 服务器。