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系统授权模型内部定义了不同的权限校验接口，实现了灵活的可扩展模式。授权模型对外只提供一个统一的验证接口，应用程序通过该接口，就可以获取到各种主客体蔓延后的权限校验结果，而不必关心各种主客体之间的蔓延关系。