引言

產品生命周期管理(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機制，引入基于流程實例的對象組，很好地解決了這些需求。