LDAP目录数据完整性检验设计与实现.ppt

1、LDAP目录数据完整性检验设计与实现,西安交通大学信息与网络中心 韩博 2006年10月19日,2020/7/12,2,内容介绍,一、项目背景 二、技术目标 三、实现思路 四、内容和实现要点 五、未来展望,2020/7/12,3,一、项目背景,1、“211”二期工程校园网子项目建设内容 2、数字化校园数据中心基础设施 3、目录服务管理子系统介绍,2020/7/12,4,1、“211”二期工程校园网子项目,2003年规划 2005年10月开始执行，合作开发 原计算机网络与信息中心西安交通大学校园网“211”二期建设规划建设内容之一 目标：提供校园信息化支撑与服务 以数据中心的高度提出 非一次性建

2、设项目 较长规划：按照5年需求概算 多次建设： “211二期工程”校园网分项完成部分内容， “985”二期工程数字化校园分项完成其他内容。,2020/7/12,5,1、 “211”二期工程校园网子项目,拟按照校园数据中心的目标来建设，其基本结构如下：,2020/7/12,6,2、数字化校园数据中心基础设施,解决当时得问题：整合学校MIS 绝大多数职能部门均独立建设 面向管理和面向服务一体设计 系统功能能解决部门自己的办公问题 部门业务处理已经离不开 使用相对稳定(使用惯性) 技术上存在的问题较多：安全外部连接扩展 改造困难：多为委托开发部分开发过程不规范 已出现需要被整合的需求：特别在数据上和

3、认证上,2020/7/12,7,2、数字化校园数据中心基础设施,目标：打破部门之间信息孤岛 用户统一 数据共享 (统筹)为学校IT服务提供支持 方针：资源统一建设和管理 软件（后期投资少、自主性） 硬件（统筹建设、校内共享） 总体要求：降低学校IT成本，（一定程度上）提高IT水平,2020/7/12,8,统一认证平台,211二期完成的目录服务内容示意图,统一门户,统一认证平台,各类应用系统,统一数据交换平台,网络和软硬件环境,目录管理子系统,认证和授权模型设计,认证网关和代理,SSO与portal集成,服务注册模块,认证平台规范,IPv6/PKI等,已经完成的内容,2020/7/12,9,3、

4、目录服务管理子系统介绍,该子系统的建设目标 实现用户认证信息的统一管理 实现单点登录样例。 实现基于角色的统一授权管理,2020/7/12,10,3、目录服务管理子系统介绍-图,2020/7/12,11,3、目录服务管理子系统介绍,系统的对象,角色,2020/7/12,12,附：统一授权管理的功能模型设计,基于RBAC2000的模型 支持基于角色的授权和访问控制,2020/7/12,13,3、目录服务管理子系统介绍,需要存储到目录的数据 学校的基础数据 用户、资源、角色、应用（表示）、组织机构 关系数据 基本数据之间的关系 例：用户组织机构 资源应用,2020/7/12,14,3、目录服务管理

5、子系统介绍,目录存储关系型数据 通过条目位置区分条目类型 通过条目属性存储参照信息 在条目之间设定其他关系,2020/7/12,15,3、目录服务管理子系统介绍,产生的问题：目录数据的完整性缺乏保障 原因： 目录没有提供表一级的数据定义 目录保障属性的语法正确，并不做语义限制 无法保障用户自定义的条目间约束,2020/7/12,16,二、技术目标,1、保障目录数据的完整性 2、保证目录的性能 3、适应性和灵活性,2020/7/12,17,1、保障目录数据的完整性,关系数据的完整性要求 实体完整性 参照完整性 其他业务规则要求的完整性,2020/7/12,18,1、保障目录数据的完整性,实体完整

6、性 某目录下的条目必须具有某些对象类，可以具有另一些对象类，除此之外，不能再有其他类型的对象类,ou=people目录下的对象类,2020/7/12,19,1、保障目录数据的完整性,参照完整性 条目A如果在某个属性值里引用另外一个条目B的DN，则B条目必须存在 举例：,2020/7/12,20,1、保障目录数据的完整性,其他业务规则要求的完整性 通过RDN关联的条目 例：每个管理员的资源存储在另一个目录下的条目 管理员与这个资源条目之间通过相同的RDN联系起来,2020/7/12,21,2、保证目录的性能,目录系统目标：100万目录对象 性能要求(10万实际用户数据) 测试环境下3秒/万用户并

7、发 测试环境下1s/普通访问 需要保证目录的性能 数据不完整对系统的影响 多应用查询速度 锁定目录等问题 在应用系统中做验证可能要增加大量操作,2020/7/12,22,3、适应性和灵活性,能够适应目录的变化 随着应用变化，目录可能需要变化 能够变动检查策略 不同的环境下需要不同的策略 例：实体完整性不需要每次都检查 参照完整性必须经常检查,2020/7/12,23,三、实现思路,1、可能的方案 2、方案的选择 3、配置需求及策略,2020/7/12,24,1、可能的方案,方案A：在应用系统中添加完整性检查 每次的更新操作都确保完整性 需要事务支持 增加系统响应时间 方案B：在应用系统外执行完

8、整性检查 可周期性执行 可保证系统响应时间 系统在两次检查间隔内可能不一致,2020/7/12,25,2、方案的选择,应用系统内部 仅保证提交的数据完整 应用系统外部 完整性的检查 周期（自动） 临时（手动或条件触发） 不完整数据的更正 自动（简单的删除、添加、修改） 手动（条目的创建）,2020/7/12,26,3、配置需求及策略,检查内容 适应目录的变化 可进行有侧重点的检查 检查周期 发生概率低的不完整性 发生概率高的不完整性 检查策略 更正 记录,2020/7/12,27,3、配置需求及策略,配置方式 XML (举例),2020/7/12,28,四、检查内容和实现要点,1、系统构成 2、配置文件及检查内容 针对实体完整性的配置、检查 针对参照完整性的配置、检查 针对业务规则要求的完整性的配置、检查,2020/7/12,29,1、系统构成,2020/7/12,30,2、配置文件及检查内容,配置目录必须包括的对象类集合 配置目录可以包含的对象类集合 针对对象类及其必选属性进行检查,2020/7/12,31,2、配置文件及检查内容,配置目录必须包括的对象类集合 针对Attribute引用的检验,2020/7/12,32,2、配置文件及检查内容,配置自定义的业务规则 根据配置文件获取检