PDM/PLM系统授权模型研究

作者：北京清软英泰公司 卢亚辉 耿坤瑛

欢迎访问e展厅 展厅 3 PDM/PLM/CAPP展厅 图文档管理系统, CAPP... 1．前言 PDM/PLM系统的安全是靠认证、访问控制、审计、加密等多种技术共同协作来保证的。访问控制技术处于系统安全的中心环节，保证了数据的保密性、完整性和可用性。在企业信息化程度越来越高的今天，PDM/PLM系统中的访问控制技术发挥了越来越重要的作用。访问控制技术和授权模型在很大程度上影响着PDM/PLM系统的可用性、易用性和安全性。 目前已经提出的针对信息系统的访问控制模型有很多种，如：矩阵模型、自主访问控制模型、强制访问控制模型、基于角色的访问控制模型、工作流访问控制模型等，大多数PDM/PLM系统的授权模型往往是上述几种授权模型的综合。 2．主流PDM/PLM系统授权模型的比较 表1给出了几个主流PDM/PLM系统授权模型的比较。下面主要介绍一下这些系统在授权模型方面比较有特色的地方。 2.1 WindChill WindChill采用了Domain（域）的概念，一个Domain是一些不同类型的对象的集合。在每个不同的Domain上可以定义不同的访问控制策略和访问控制权限。 在每个Domain上的访问控制策略是由一系列的访问控制规则组成的。访问规则规定了主体对客体在各种生命周期状态下的访问权限。规则的一般形式为“if then ”。这些规则是可以沿类树从父类向子类蔓延。WindChill采用ACL（访问控制列表）的方式来体现一个对象上的访问控制规则。 2.2 Teamcenter Enterprise Teamcenter Enterprise中的权限控制使用 “基于规则” 的方式，可以通过规则来实现对用户操作权限的控制，控制用户、角色、工作组和部门对一个对象、一类对象或数据仓库的操作权限，并可与电子流程相结合。 Teamcenter Enterprise支持三类规则： 访问控制规则（Message Access Rules） 通知规则（Notification Rules） 数据定位规则（Location Selection Rules） Teamcenter Enterprise中提出了动态用户的概念，一个用户，只有在满足某种属性条件的前提下，才可以具有某些权限。 2.3 Teamcenter Engineering Teamcenter Engineering通过两种方式控制用户对数据文档的访问： 面向对象的访问控制方式 以规则为基础对数据对象实行分类访问控制 其中规则方式是一种粗线条的管理方式，在规则控制的访问（Rule_Based Access）控制中，可根据数据对象当前的状态、类型、所属用户或组三个属性统一确定可存取该数据的人员范围。 Teamcenter Engineering中同样采用了基于角色的访问控制，一个用必须以某种角色登陆，才能获取相应的权限。 Teamcenter Engineering通过存取规则定义表，初始化权限模型，比较容易阅读。 3. PDM/PLM授权需求的多元化 虽然目前对PDM/PLM系统的授权模型的研究和应用有了很大的进展，但是这些模型并不能完全支持客户在实际使用中提出的各种权限需求。这些需求主要表现在下面几个方面： 主体的多元化：权限不仅需要定义到用户和角色上，而且必须支持权限定义在其它类型的主体上。比如，用户可以通过分组形成静态组织，也可以通过动态分组形成项目组，有时需要把权限定义到这些静态组织和项目组上。 权限的多元化：权限根据不同的客体应用，可以分为对象类权限、对象权限、属性权限、部件权限、管理权限、二次分配权限、代理权限等。普通的基于类的授权，已经不能满足实际的应用需求，必须建立对类的实例化对象以及对象属性的权限控制。另外，相对于用户和类来说，实例化对象的数量非常庞大，如何保证访问验证的效率是授权模型在实现过程中最大的难题。 对象在生命周期中的权限变化：同一个用户，对同一个对象，在该对象的不同生命周期，有着不同的权限。如设计员在图纸对象的设计阶段有修改的权限，在该图纸被发布之后，该设计员就只有浏览和读的权限了。这就要求把权限定义到对象的生命周期上。 统一的授权模型框架：随着PDM/PLM系统的发展，PDM/PLM系统中包括的子系统越来越多，比如除了传统的数据管理子系统，很多PDM/PLM系统还集成了工作流子系统，ERP子系统，CAD子系统等。这就要求必须有一个统一的授权框架来支持在PDM/PLM中控制这些子系统中的数据的权限，而不能只由各个子系统的授权模型来控制权限。 权限分级管理：目前大部分PDM/PLM系统的权限管理都由全局的系统管理员角色来担任，该系统管理员负责分配整个系统的权限。由于该系统管理员可以无所不为，实际上系统管理员成了企业安全最大的漏洞。而在实际应用中，由于部门之间往往存在着各种利益冲突，所以在实施数据的管理中，不仅有全局化的数据，而且各个部门会有各自的数据，这就要求管理员的权限必须受到限制，不能随意访问各个部门的私有数据。此外，从实际的运行管理来讲，该系统管理员也无法详细了解各个部门的人员对权限使用的要求，无法更好地设置企业的权限。所以需要建立分级的权限管理员。 规则授权和矩阵授权的结合：基于条件表达式的规则授权有很高的灵活性，但是当规则增多时，系统地效率会大大下降，因为需要逐条对规则判断。另外一个对象可能会出现在多条规则中，所以需要一套复杂的机制来处理规则之间的授权冲突。而基于矩阵的授权因为可以直接利用数据库的查询机制，所以有很高的效率。但是基于矩阵的授权灵活性、扩展性较差。如何把这两种方式结合起来，从而实现灵活高效的授权机制，以适应日益复杂的企业对授权的需求，是对PDM/PLM系统权限模型提出的一个更大挑战。 4. TiPLM的授权模型 清软英泰的产品全生命周期管理系统——TiPLM是基于.Net开发的采用多层体系结构的PLM系统。在TiPLM的底层服务中有专门的安全服务模块，为TiPLM的各个模块和应用程序提供统一的安全服务。权限验证就是这些安全服务中的一个重要组成部分。为了满足企业的实际需求，TiPLM的权限模型在基于角色和基于流程的授权模型的基础上，进行了多方面的扩展。其主要特点体现在下面几个方面。 4.1 统一的授权框架 TiPLM的授权模型的体系框架如图1所示。包括了五个模块和四个接口。授权逻辑模型定义了权限验证的逻辑规则。普通用户使用TiDesk模块完成其工作，TiDesk通过接口1进行用户访问的权限验证。权限管理员使用TiModeler模块通过接口2进行权限的设置。系统定制员使用TiPolicy通过接口3定制企业授权的元模型和插件扩展。通过接口4可以实现针对不同数据库（如Oracle，SQL Server等）的符合逻辑模型的权限验证规则。 4.2 多级蔓延机制 由于PDM/PLM系统中有多种主体和客体类型，比如主体有用户、角色、组织等，客体有类、实例化对象、对象属性等，这些不同的类型有各种依赖和制约关系。所以在实际进行权限验证时，必须综合考虑这些类型之间的关系。TiPLM系统采用了多级蔓延机制来保证权限验证的正确性和易用性。 根据这些不同的蔓延规则，TiPLM系统授权模型内部定义了不同的权限校验接口，实现了灵活的可扩展模式。授权模型对外只提供一个统一的验证接口，应用程序通过该接口，就可以获取到各种主客体蔓延后的权限校验结果，而不必关心各种主客体之间的蔓延关系。 4.3统一的授权机制 随着工作流系统的广泛应用，工作流系统中出现的应用数据越来越多，对于这些数据权限控制的需求也越来越复杂。目前大部分PDM/PLM系统都采用了独立于PDM/PLM的工作流系统，从而对于PDM/PLM中的用户和数据，必须在工作流系统中重新建立一套完整的授权机制，这一方面增加了系统的开发难度，另一方面在实施和运行过程中，增加了管理员的工作量，因为管理员必须同时设置PDM/PLM系统和工作流系统的权限。而且目前大部分的工作流系统的权限控制都无法达到PDM/PLM系统的权限控制的力度。 TiPLM由于采用了统一授权框架，对非流程和流程的数据授权采用了同一套机制，在进行权限验证时，用户可以完全不考虑是否需要通过流程任务来获得权限，底层的逻辑模型可以通过TiPolicy定义的元模型自动判断是否需要进行流程授权验证。管理员通过TiMoldeler可以直接管理对流程的授权。而且，因为只需要设置流程中特定的权限，而将默认权限交由TiPLM系统统一处理，这样大大简化了管理员的工作，又增加了权限验证的力度。 4.4 多级权限管理 TiPLM采用了基于管理角色树的多级授权管理模型来进行权限的管理和分配。如下图所示。采用多级管理角色后，分厂1的设计部权限管理员只能管理该设计部门的人员、角色、组织、工作流、受控对象等权限，而无法管理分厂1的销售部门、制造部门以及分厂2和分厂3的人员、角色、组织、工作流、受控对象等权限。这样的多级授权管理模型，更好地支持了大型企业或集团型企业的实际权限管理的需求，具有很大的灵活性。 5．结束语 企业对PDM/PLM系统授权的各种特定需求，是企业PDM/PLM系统实施过程中经常遇到的问题。如何准确、快捷、有效、及时地满足这些授权需求，是各个PDM/PLM软件厂商都需要考虑的问题。虽然这个问题的影响因素包括很多方面，但是，一个具有支持可定制的、开放的、易扩展的授权模型的系统是至关重要的，也是必须的，否则将无法满足企业日益增长和变化的需求。综上所述，可以看到TiPLM系统可以从多个层面满足企业在PDM/PLM系统实施和应用过程中对授权的不断变化的需求。(end)

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