CoGIS功能性安全设计.docVIP

CoGIS功能性安全设计 　　摘要：本文分析了基于任务组管理的CoGIS功能安全设计的优缺点，提出在数据传输中采用XML命令消息封装安全权限，并通过协同客户端解析实现的方案。 　　关键词：CoGIS 功能性安全 XML 　　 　　Abstract: This paper has analyzed the advantages and disadvantages of CoGIS functional safety design based on task management, and proposed using XML command message encapsulating security permissions in data transmission and through cooperative client to analyze the completed scheme. 　　Keywords: CoGIS, functional safety, XML 　　中图分类号：S611文献标识码：A 文章编号： 　　 　　0 引言 　　CoGIS定义为：“一组或多组异地的用户，借助计算机及其网络技术，基于地理信息共同协调与合作来完成一项任务”。 [1] 在虚拟的协同工作环境中，感知的是地理信息行为，共享的是地理信息数据。因此，CoGIS对于应用安全的要求要远远高于其他GIS系统。 　　通常，应用安全分为系统级安全、程序资源访问控制级安全、功能性安全、数据域安全。其颗粒度依次由粗到细。本文仅从功能性安全进行论述。 　　1基于任务组管理的安全设计 　　在任务组管理的CoGIS工作中，协同用户依据任务划分被加入到一个任务组中，每个任务组就是一个资源的集合，主要包括协同用户、任务、子任务、共享数据表、规则集、版本等。[2]也就是说，在同一个任务组中，参与协同的用户具有相同的权利和义务，所有的地理信息行为和数据对于组用户来说都是透明的。采用角色访问控制模型即可实现协同GIS中的功能性安全。 　　协同GIS中的角色可分为三类：协同用户、组管理员和系统管理员。协同用户是协同事务的具体执行者，归属于某一个或多个用户组，其享有对协同工作环境的一般性操作功能，如协同编辑、协同查询和协同空间分析等；工作组管理员负责对协同工作组进行管理，为不同的工作组赋予操作某一个或多个协同事务的权限；系统管理员则实现了用户与角色的增删改查功能。 　　用户、角色、功能三者之间的关系如下图所示： 　　 　　 　　图1 协同用户、角色、功能之间的关系 　　Figure 1 relationship between cooperative user, role and function 　　 　　这种方案易于理解，所有功能权限在系统入口时都已经进行控制，实现相对容易。其缺点是扩展性不强，一旦协同用户的功能权限需要变更，需要组管理员进行权限配置，或者任务组内部需要实现部分用户的权限控制，则需要系统管理员建立新的用户组。 　　CoGIS的基础是通信，如果能在传输对象中封装功能权限信息，待协同客户端收到后，在协同事务流程中进行逻辑验证，既可满足功能的安全性要求，又可提高系统的协同感知能力。 　　2基于XML命令消息的安全设计 　　目前，协同GIS传输对象的设计大多采用了XML的方式[3][4]，其元素主要包括SendInfo和GISInfo。我们可以对其进行修改，加入关于功能性安全的元素。修改后的元素为三个，其一为事务类型ObjectType，指协同客户端所能支持的地理信息行为，如设置当前地图显示范围、缓冲查询、空间分析等；其二为安全信息SecurityInfo，用于功能权限的设置或验证；其三为协同对象CooperativeObject，与事务类型对应，描述了协同事务中需要操作的数据信息。如地图范围的左上角、右下角坐标，标绘符号的线型、颜色等属性。本文中重点论述安全信息的设计。 　　安全信息的元素如下表所示： 　　表1 安全信息的元素分析 　　 　　 　　 Password为功能权限的验证码，协同客户端进行解析时，可以判断本地客户端是否存在相同的密码，如果相同则可以进行该事务操作，否则拒绝。密码为空则不进行验证。 　　 SrcUserInfo中的元素为发送者的信息，某些协同事务操作仅发起方才能完成，如协同标绘时，发起方标绘了一个符号，其他协同用户是不能对其进行编辑的。此时，协同客户端可以进行验证。如果本地客户端的用户信息与发起方一致，才能操作。否则拒绝。 　　 DestUserInfo为接收者的信息，通常接收者属于一个任务组或者机构。发送者可以通过系统指定本次协同事务的接收者，可以是一人，也可以是多人。当