PLM中工作流的访问控制模型

作者：廖旭 张力

欢迎访问e展厅 展厅 3 PDM/PLM/CAPP展厅 图文档管理系统, CAPP... 引言 产品生命周期管理(Product Lifecycle Management, PLM)系统贯穿于产品的整个生命周期，涉及产品的开发、生产、打包和分配等各种流程，在执行业务流程时，各种文档和数据在流程中传播，如何确保这些信息的安全就变得十分重要。 访问控制是保证 信息安全 的一种主要手段，目前应用最广泛的访问控制模式是基于角色的访问控制。1996年，文献3提出了一系列的模型，形成了RBAC96标准，RBAC被引人工作流管理系统领域后，由于并不能很好地适应工作流环境，很多研究人员都提出了各自的改进方案;文献[4]提出用PetriNets来表示授权模型，强调了角色和任务两个概念;文献[5]总结了工作流管理系统中的各种约束和规范，并进一步提出了相应的语言算法来描述和验证。 PLM系统的访问控制一般偏向传统的文档管理和用户管理，采用基于角色的访问控制。这种授权模式基本上是静态的，用户在登陆了系统后就被赋予了固定的权限，该权限在其退出系统之前都不会改变。但这种模式不能满足工作流管理系统中动态授权的要求。在流程中，权限和上下文相关联，在不同的上下文中，同一个角色的权限可能不同。 本文在 PLM系统原有的 RBAC基础上，引人基于流程实例的对象组。通过用对象组管理在流程中使用的数据对象，不仅可以实现工作流中的动态授权，还可以增加授权的灵活性，细化授权粒度。下面将讨论在 PLM 系统中，工作流管理系统的特殊访问控制需求，并以笔者开发的TiPLM系统为例，讨论如何实现它的访问控制机制。 1PLM系统中工作流管理系统的访问控制需求 PLM系统需要管理整个企业的各种信息和数据，包括员工信息、生产信息和产品信息等。而产品信息又包括文档、图纸、零件、工艺以及它们之间的各种关联。这些信息只有参与到流程中，才能完全达到PLM在企业信息化中的目的。流程是为了完成某个目的而相互连接的活动或任务的集合，流程中的数据对象将伴随流程在企业各部门之间流动。这样，一方面加快了信息的流通，另一方面也引人了新的安全需求。本文将主要从 3个方面讨论 PLM中工作流的访问控制。 (1)共同授权由于集成或内嵌于 PLM 系统，工作流管理系统需要和 PLM 系统共同完成授权。PLM系统在文档管理等方面已经很成熟了，它可以很好地控制每个用户对不同类型数据的权限，还能区分文档、图表等对象所处的状态。例如，如果对象处于检人状态，就没有修改、删除等权限，而对象只有处于定版状态才能进行升版操作。如果完全摒弃PLM系统原有的授权体系，由工作流管理系统单独授权，将会极大地增加系统复杂度。因此，PLM系统分担工作流管理系统部分授权，两者协同工作完成授权，才是最好的办法。 (2)动态授权 随着流程运行到不同的任务节点，流程参与者所拥有的权限是变化的。以一个典型的流程为例，如图 1所示。图中是一个审批流程模板，包括 4个任务节点和 1个路由节点。1个用户拥有"设计员"这个角色，但其在执行"设计图编制"和"工艺图编制"这两个任务时，能访问的对象应该不一样。而某个用户在 PLM 系统中也许不具备访问"设计图纸"的权限，但是如果被分配执行"审核"这个任务，就有权限访问设计图纸，而且是只能在开始执行这个任务时赋予访问权限，任务结束后就不再具备访问权限了。由此可以看出，流程中的授权是动态的，即使同一角色，在不同的流程中拥有的权限也是不同的，甚至在同一流程的不同活动节点，拥有的权限也可能不一样。 (3)最小授权指授予用户的权限恰好能够完成这个任务。例如，在该流程中，"审核"节点的执行人只需要访问设计图和工艺图，而且由于只是审核图纸，执行人也不能拥有"修改"和"删除"等权限。如果给客户授予了过大的权限，就会造成权限的泄漏;如果权限过小，则用户无法成功完成任务，造成流程的死锁。因此，最小授权是指用户恰好能完成任务的最小权限。 2 PLM系统中工作流管理系统的访问控制模型 2.1 PLM系统的访问控制 PLM系统采用的是基于角色的访问控制模式，对它的描述如下U为所有的用户集合，u为一个具体的用户。R为所有的角色集合，r为一个具体的角色。O为所有对象的集合，o为一个具体的对象，在PLM系统中，对象指系统管理的各种数据，如数量庞大的文档以及他们之间复杂的关系。C为所有类的集合。c为一个具体的类。PLM系统管理的对象虽然很多，但是他们可以按照类别来划分，如分成组织、产品、文档和图表等不同大类;而这些大类又可以继续划分成更小的子类，如"产品"又可以继续划分成定制件、自制件等。P为所有权限的集合，p为某一项权限。 2.2 基于流程实例的对象组 以图1的流程为例，可以通过工作流管理系统(WorkflowManagement System, WfMS )中的流程定义工具把它构建成一个流程模板。当需要进行审批任务时，再把这个流程模板实例化，成为具体运行的一个业务流程实例。每次要审批的对象是不一样的，而且在审批过程中，需要用到的对象也是不一样的。由于同一流程模板对应的流程实例在运行时用到的对象可能会不相同，无法在定义流程模板时将权限授予具体的对象。但是实际上，每个任务节点需要访问的类是可以知道的，如"设计图编制"只需要访问"图纸"类的对象即可知道。所以，在每个活动中只能定义某一类的对象所能授予的权限，这样，授权的粒度就会不够，如 "图纸"类包含了各种图纸对象，在任务"工艺图编制"中需要访问"图纸"类中的工艺图纸，却不能访问设计图纸，因此如果允许用户在执行"工艺图编制"时访问"图纸"类，则所给的权限过大，如果不允许访问"图纸"类，又无法完成这个任务，造成流程的死锁。为了更进一步地进行权限控制，本文引人基于流程实例的对象组这个概念。 对象组是一个用来存放流程中用到对象(如文档和图纸等)的暂时容器(container),需要注意的是，对象的管理者还是 PLM系统，对象组中添加的只是对象引用。每个对象组只能属于一个流程，而一个流程内可以定义多个对象组。真正直接和对象组相关联的是流程中的任务节点，可以定义每个任务节点允许使用这个流程中的哪几个对象组。一个对象组允许在多个活动节点被使用，一个对象组只在它属于的流程实例内有效，不同流程实例的对象组完全没有关系。因此，对于不同流程实例，对象组相当于一个局部变量，但是在流程实例的内部，一个对象组又将贯穿于各个任务节点，每一次往这个对象组里添加删除对象，都将影响到下次对这个对象组的使用，这时对象组又相当于一个全局变量。 每个对象组内的对象可以按照类别授权。同一务节点的不同对象组可以有不同的权限，同一对象组在和它关联的不同任务节点也可以有不同的权限。这样，一个任务节点需要使用的对象，即使属于同一个类，如果他们属于不同的对象组，权限也可以不同。通过对象组，可以进一步精细授权的粒度。 以上文中的场景为例，可以在流程中定义两个对象组，命名为"工艺图对象组"(dgo)和"设计图对象组"dg2)，分别容纳流程中属于"工艺图纸"和"设计图纸"这两个类的对象。定义任务节点"设计图编制"(t1)和对象组dg1关联，任务节点"工艺图编制"(t2)和对象组 dg1,dg2关联。在任务节点 t1中，由于dg1中容纳的是"设计图纸"对象，定义任务t2的执行人允许对dg1中的对象进行创建、浏览、修改和删除，而任务节点t:中，工业图纸编制人员需要参考设计图纸，但不能对其进行修改，所以定义任务t2的执行人允许对dg1中的对象拥有浏览的权限，对dg2中的对象拥有创建、浏览、修改和删除等权限。这样既保证了流程的执行，又避免了权限泄漏。 2.3 流程中的访问控制 笔者在PLM系统原有的RBAC模型上加人和流程相关的信息，使之适用于工作流管理系统。下面对该访问控制模型进行定义:R,U,C,P分别表示角色、用户、类和权限;T为所有任务的集合，t为一个具体的任务;DG为所有对象组的集体，dg为一个具体的对象组。 人员组织管理和对象管理由PLM 系统负责所以用户和角色的赋值关系为URA. 在流程中，授权可以表示成一个五元组:grant=(t,roleset(t),c,p,scope)。其中，t ∈ T表示一个任务，roleset(t)={r|(task,r)∈RTA}∈Role表示允许执行 t的最小角色集合;c∈Class表示一类对象;p ∈Privilege表示一种权限;Scope表示授权的适用范围，有process,task和datagroup3个取值，分别表示这个授权的适用范围是整个流程、一个任务或者一个对象组。这个五元组表示任务 t的执行人在执行这个任务时，对 c类对象拥有权限p，它的有效范围是整个流程、任务本身或者这个任务使用的某个对象组。 在该模型中，授权存在偏序关系:gp>ge>gd其中gp,gt和gd分别表示scope为process,task和datagroup的权限。因为gp适用于整个流程，所以如果这个流程中某个活动节点或者对象组未被授权，gp会自动继承给他们;但如果活动节点或者对象组已经授权了，则 gp就不会继承给他们了。同理，gt适用于活动以及活动中允许使用的对象组，所以如果活动关联的某个对象组未被授权，gt会自动继承给这个对象组。该模型的结构如图 2所示。 以图1的流程为例，假设已经对流程建立了"工艺图对象组"(dg1)和"设计图对象组"(dg2)两个对象组，并将它们分别与"工艺图编制"和"设计图编制"这两个活动节点关联。当用户在执行"设计图编制"(t1)时，对"设计图对象组"中的一个对象"设计图1"进行"检出"操作，对应的权限检验为:①通过对象和类从属关系 OCB确定对象"设计图 1"所属于的类为"图纸"(c1)o②查找是否存在{ti，u，c1，checkout,datagroup}。如果存在，则允许进行操作并停止权限检验;如果不存在，则查找是否存在{t,u,c1，checkout，task)。③如果存在{t,,u,c,checkout,task)，则允许进行操作并停止权限检验;如果不存在，则查找是否存在{t,u,c,checkout,process},④ 如 果 存 在 {t, u,c, checkout,process}，则允许进行操作;如果不存在，则禁止用户进行"检出"操作。 3 访问控制模型中的实体关系 图3是工作流管理系统中和授权相关的主要实体的统一建模语言(UnitedModelingLanguage,UML)图，大致可以分成两个部分:①负责流程的运行，包括流程定义(processdefinition)、活动定义(activitydefinition)、流程实例(processinstance),活动实例(activityinstance)和活动参与者(participant)等。流程定义是对企业业务流程进行抽象建立的模型，一个流程定义可以实例化(instance)成多个流程实例，流程实例才是企业中运行的具体流程，而每个活动是这个流程中要做的事情。② 负责流程中的权限控制，中枢是访问控制规则(accesscontrolrule)，负责联系权限的主体(subject)和客体。(object)。授权的主体是流程中的参与者(participant)，包括整个流程的监控人和每个活动实例的执行人，授权的客体是有 PLM 系统管理的各种数据对象(object)。流程实例、活动实例和对象组向访问控制规则提供上下文相关的信息。 4 实现 本文的访问控制模型已在 TiPLM 系统上实现。该系统是国家 863计划支持的项目，已在厦门金龙的多家大型企业成功实施，图4是系统的结构图，主要包括和授权相关的模块。 从图4中可以看出，工作流管理系统的授权并不是完全独立的，它需要参考 PLM 系统的人员组织管理模块和文档对象模块。由PLM系统管理用户和文档，这是考虑到 PLM 系统本身就擅长管理数量庞大的文档以及它们之间复杂的关系，而PLM的用户管理也完全适用于工作流中的用户管理。PLM系统中的文档和用户，通过映射关系变成工作流中的实体，参与工作流的运行和授权。一个对流程的用户请求将提交工作流引处理，工作流引擎中的授权模块通过访问控制规则基确定用户请求是否有效，如果有效则生成任务实体进程。 5 结束语 本文分析了现有 PLM 系统授权的优点和缺点，针对工作流系统授权的一些特殊要求，结合PLM系统原有的RBAC机制，引入基于流程实例的对象组，很好地解决了这些需求。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (5/3/2008)