以角色為基礎的存取控制於跨組織工作流程之 研究
研究生:簡其弘 指導教授:吳美玉 博士
中華大學 資訊管理學系
摘要
由於市場環境的迅速發展,企業的流程和價值鏈逐漸朝向網路化、跨組織方 向的發展,在跨組織的工作流程環境中,分派角色給使用者及選擇角色進入工作 流程的機制,已不能僅考量組織內部工作流程的規範。因此,本研究的主要目的 是延伸以角色為基礎的存取控制機制運用到組織內部工作流程的特性,並在水平 式跨組織工作流程環境中的使用者、角色及工作之間加上更嚴謹的限制條件,讓 使用者在虛擬角色集合中,選擇一個適當的角色進入跨組織工作流程內執行工 作,使企業能在進行跨組織工作流程時,有更深一層的保護,讓整個工作流程更 具公平性及安全性。
關鍵詞:跨組織工作流程、工作流程、以角色為基礎的存取控制、水平式跨組織 工作流程
Research on Role-based Access Control for Inter-Organizational Workflow
Student:Ci-Hong Jian Advisor:Dr. Mei-Yu Wu
Department of Information Management, Chung-Hua University
Abstract
Due to rapid development of marketing environment, the process and value chain of enterprises become networked and inter-organizational oriented. In inter-organizational workflow environment, the user-role assignment mechanism should not merely intra-organizational workflow. Therefore, the main propose of this research is to extend the characteristics of role-based access control on intra-organizational workflow, and appends more strict constraint to users, roles and activities of horizontal inter-organizational workflow. Besides, this research makes sure that a user chooses an appropriate role from virtual role set to execute activity in inter-organizational workflow. Enterprises will have enhanced protection, more equitable and securable in inter-organizational workflow.
Keywords: Inter-Organizational Workflow, Workflow, Role-Based Access Control, Horizontal Inter-Organizational Workflow
致謝
兩年的碩士班學業終於完成,在中華的求學過程中,獲得許多良師益友的教 誨及相互提攜,能夠順利完成學業首先要感謝我的父母親,讓我在沒有壓力之下 完成學業,感謝他們為我的付出以及長久的支持,感謝支持我的家人。
這本論文得以完成,首要感謝指導教授吳美玉老師在課業及論文的耐心指導 與鼓勵,並感謝口試委員王偉德老師、郭明煌老師與葉慈章老師在百忙之餘,對 於論文給予許多的指正與建議。
再者,要感謝實驗室的同學們:智翔、宗澤、家維、堯保與文鈴,在我撰寫 論文的這段時間所給我的支援及建議,並讓我在實驗室的生活更加精彩而有趣。
最後,我要將本研究獻給所有關心我的朋友,並且致上心中最深的謝意,謝 謝你們。
目錄
摘要... I Abstract ... II 致謝...III 目錄...IV 圖目錄...VI 表目錄...VIII
第一章 緒論...1
1.1 研究背景與動機 ...1
1.2 研究目的 ...2
1.3 研究流程 ...2
1.4 論文架構 ...5
第二章 文獻探討...6
2.1 以角色為基礎的存取控制模型 ...6
2.1.1 模型架構 ...6
2.1.2 安全原則 ...8
2.2 工作流程 ...9
2.2.1 定義 ...10
2.2.2 組成元素 ...10
2.2.3 參考模型 ...14
2.2.4 工作流程管理系統 ...15
2.3 策略聯盟 ...16
2.3.1 定義 ...17
2.3.2 策略聯盟之型態 ...18
2.4 跨組織工作流程 ...20
2.4.1 流程架構 ...20
2.4.2 存取控制機制於跨組織工作流程 ...22
2.5 小結 ...24
第三章 以角色為基礎的存取控制於跨組織工作流程...26
3.1 工作流程分析 ...26
3.1.1 使用者 ...27
3.1.2 虛擬角色 ...29
3.1.3 使用者取得虛擬角色階段之限制條件 ...30
3.1.4 工作 ...31
3.1.5 使用者取得虛擬角色執行工作階段之限制條件 ...33
3.2 工作流程架構 ...34
3.3 工作流程架構範例 ...36
第四章 系統實作與展示...39
4.1 系統環境 ...39
4.2 系統架構 ...40
4.3 系統流程與展示 ...41
4.3.1 使用者登入 ...43
4.3.2 選擇工作流程 ...43
4.3.3 選擇虛擬角色 ...44
4.3.4 選擇執行工作 ...45
4.3.5 完成工作 ...46
4.4 應用實例 ...47
4.4.1 實例簡介 ...47
4.4.2 合法角色 ...50
4.4.3 角色分數 ...52
4.5 小結 ...53
第五章 結論與未來研究...55
5.1 結論 ...55
5.2 未來研究 ...56
參考文獻...58
圖目錄
圖 1.1 研究流程圖...4
圖 2.1 以角色為基礎的存取控制...8
圖 2.2 角色階層範例圖...8
圖 2.3 工作之結構與轉變狀況圖...11
圖 2.4 AND-Split工作連結 ...12
圖 2.5 AND-Join工作連結 ...12
圖 2.6 OR-Split工作連結 ...13
圖 2.7 OR-Join工作連結 ...13
圖 2.8 Iteration工作連結 ...13
圖 2.9 工作流程參考模型...15
圖 2.10 一般化工作流程管理系統產品架構...16
圖 2.11 跨組織工作流程架構圖...21
圖 2.12 存取控制機制於跨組織工作流程架構圖...24
圖 3.1 研究架構圖...35
圖 3.2 研究架構範例圖...38
圖 4.1 系統架構圖...40
圖 4.2 系統流程圖...42
圖 4.3 使用者登入畫面...43
圖 4.4 使用者選擇工作流程畫面...44
圖 4.5 使用者選擇虛擬角色畫面...45
圖 4.6 使用者選擇執行工作畫面...46
圖 4.7 使用者完成工作畫面...47
圖 4.8 應用實例-工作流程示意圖 ...49
圖 4.9 應用實例-虛擬角色結構圖 ...50
圖 4.10 應用實例-使用者選擇執行工作 ...51
圖 4.11 應用實例-使用者虛擬角色非合法角色 ...51
圖 4.12 應用實例-使用者完成工作 ...52 圖 4.13 應用實例-原始角色分數未滿足虛擬角色分數 ...53 圖 4.14 應用實例-原始角色分數滿足虛擬角色分數 ...53
表目錄
表 2.1 策略聯盟定義彙整表...17
表 2.2 策略聯盟型態彙整表...18
表 2.3 適合國內企業採行之策略聯盟型態彙整表...20
表 3.1 中小企業認定標準表...27
表 3.2 跨組織工作流程原始角色分數結構範例表...28
表 3.3 工作執行紀錄表...32
表 3.4 研究架構範例-虛擬角色資料表 ...36
表 3.5 研究架構範例-工作資料表 ...36
表 3.6 研究架構範例-使用者資料表 ...37
表 3.7 研究架構範例-原始角色資料表 ...37
表 3.8 研究架構範例-工作執行紀錄資料表 ...37
表 4.1 雛型系統軟硬體彙整表...39
表 4.2 應用實例-使用者資料表 ...48
表 4.3 應用實例-原始角色資料表 ...48
表 4.4 應用實例-工作流程資料表 ...48
表 4.5 應用實例-虛擬角色資料表 ...49
表 4.6 應用實例-工作執行紀錄資料表 ...50
第一章 緒論
由於市場經營環境的快速變動及全球化的競爭趨勢,大部份的企業在競爭的 環境下會建立策略聯盟關係來達成合作的目標,但在建立合作關係的同時,由於 所涉及的範圍極大,包含許多的使用者及資源,且彼此企業的規模、組織結構並 非完全相同,各企業對於企業內部職務、角色所定義之權限亦非完全相同,如何 確保企業在跨組織的工作流程環境中有適當的角色分派、授權管理,使其兼顧公 平性與安全性,便是本研究之主旨。本章將說明研究之背景與動機、目的,並簡 單說明之後各個章節所闡述的內容。
1.1 研究背景與動機
由於經營環境的快速變動及全球化的競爭趨勢,導致市場環境更加難以預測 與掌握,企業為了求生存,除了善用本身的能力與資源外,許多企業紛紛尋求合 作的夥伴,建立聯盟關係以達成跨組織合作的目標。
合作關係雖然可以使企業得到利益與綜效,但在建立合作關係的同時,亦應 考慮到合作關係所帶來的問題,由於彼此企業的規模、組織結構並非完全相同,
且各企業對於企業內部職務、角色所定義之權限亦非完全相同,如何確保企業在 跨組織的工作流程環境中有適當的角色分派、授權管理,使其兼顧公平性與安全 性,便是本研究的動機。
由Ferraiolo與Kuhn兩位學者所提出的以角色為基礎的存取控制(Role-Based Access Control, RBAC)概念[23],說明以角色為基礎的存取控制為一種非隨意性 的存取控制(Non-Discretionary Access Control)。在以角色為基礎的存取控制模 式,一個使用者可以擁有數個角色,一個角色也可以由數個使用者所擁有,而權 限的指派並非一一分派給使用者,而是分派給角色。如此減少了不少管理上的麻 煩,在組織或人事變動的時候,也能夠更方便的更改存取控制規則[5]。
目前已有許多研究將以角色為基礎的存取控制機制,運用到組織內部的工作 流程環境中[13][14][15][28][31][38],但是,在跨組織的工作流程環境中,分派角 色給使用者及選擇角色執行工作的機制,已不能僅考量組織內部工作流程的規 範,如兩個分別在兩企業內擔任專案經理職務之使用者,由於兩企業對專案經理 職務的定義、所擁有的權限並非完全相同,當兩企業在進行跨組織的工作流程 時,若僅因職務名稱相同而決定所擁有之權限亦相同,如此一來,則可能發生其 中一企業專案經理職務之使用者權限提升或下降的情況,若沒有適當的控管,不 但容易產生安全上的問題,也有失兩企業間的公平性。
1.2 研究目的
本研究的主要目的是延伸以角色為基礎的存取控制機制運用到組織內部工 作流程的特性[16][39],加上以角色為基礎的存取控制模型之概念,並在跨組織 工作流程內的使用者、角色及工作之間加上更嚴謹的限制條件(Constraint),透 過限制條件的約束,使企業在進行跨組織的合作時有更深一層的保護,讓整個跨 組織工作流程在公平的環境下進行,亦更具公平性及安全性。
而本研究也會針對所提出之跨組織工作流程架構,設計一跨組織工作流程管 理雛型系統,搭配現今企業情境的應用實例,以驗證此架構之可行性。
1.3 研究流程
本研究首先闡述問題背景、研究動機與目的,在確定研究主題為「以角色為 基礎的存取控制於跨組織工作流程之研究」後,依據相關文獻的蒐集與分析,進 一步確立研究範圍;其次是延伸以角色為基礎的存取控制機制運用到組織內部工 作流程的特性,加上以角色為基礎的存取控制模型之概念,並在跨組織工作流程 內的使用者、角色及工作之間加上更嚴謹的限制條件,建構一跨組織工作流程架
構。最後實作一跨組織工作流程管理雛型系統及展示,並提出結論及未來研究。
本研究在文獻資料之蒐集與探討上主要區分下列幾部份,包括:
1. 以角色為基礎的存取控制模型 2. 工作流程
3. 策略聯盟
4. 跨組織工作流程
根據文獻資料的分析與整理,可作為本論文研究架構之理論基礎。在系統實 作部份使用 ASP 與 VBScript 來開發雛型系統;而資料儲存的部份則使用 Access 資料庫技術,將重點著眼於跨組織工作流程內之使用者、角色及工作間的限制條 件規則,並期望能把整個跨組織工作流程架構建構完成。本論文之研究流程如圖 1.1 所示。
研究背景與動機
研究目的
文獻探討
圖 1.1 研究流程圖 以角色為基礎的
存取控制 工作流程
跨組織工作流程
以角色為基礎的存取控制 於
跨組織工作流程
系統實作與展示
應用實例
結論與未來方向 策略聯盟
更嚴謹的 限制條件
1.4 論文架構
本研究提出了一個跨組織工作流程的架構,在本論文中會詳細的說明設計的 概念架構及過程,以及如何解決企業在跨組織工作流程中面臨之公平性與安全性 的問題,最後本研究會建置一個跨組織工作流程管理之雛型系統,配合實例說明 架構的運行方式,達成架構之可行性,最後提出結論及未來研究。
在第二章裡將探討與本研究相關的四個研究領域,分別是以角色為基礎的存 取控制模型、工作流程、策略聯盟及跨組織工作流程,以這些理論為概念基礎,
延伸出跨組織工作流程的架構。
第三章為本研究之重點,主要說明整個跨組織工作流程之架構,對架構下的 各元素定義屬性,並定義出各元素間的限制條件規則,使其架構兼顧公平性與安 全性。
第四章為本研究所提出之雛型系統介紹,包含系統環境與架構,並做畫面展 示及流程說明,根據跨組織工作流程管理系統中的實例,來說明本研究所提出之 概念。
第五章為本研究之結論與未來研究,說明本研究架構特性與結果,並延伸此 特性到垂直式之跨組織工作流程,加入其他的概念,使整個跨組織工作流程在進 行時,有更深一層的保護,為本研究之未來研究。
第二章 文獻探討
本章將探討與本研究相關的四個研究領域,分別是以角色為基礎的存取控制 模型、工作流程、策略聯盟及跨組織工作流程,第一節探討以角色為基礎的存取 控制模型,包含模型架構及安全原則,第二節探討工作流程,包含工作流程定義、
組成元素、參考模型及工作流程管理系統,第三節探討策略聯盟,包含策略聯盟 定義及型態,第四節探討跨組織工作流程,包含跨組織工作流程之架構及存取控 制機制於跨組織工作流程,並於最後進行綜合討論。
2.1 以角色為基礎的存取控制模型
以角色為基礎的存取控制(Role-Based Access Control, RBAC)於 1992 年由 Ferraiolo與Kuhn等學者首次提出以角色為主的存取控制概念[23],之後又經過 Sandhu等學者加以改進並正式提出以角色為基礎的存取控制模型[35],並由美國 國家標準技術局(National Institute of Standards and Technology, NIST)組職加以 收編、整理之後訂定標準[36]。以角色為基礎的存取控制主要是利用使用者、角 色與權限的三層關係來管理組織內部人員存取權限的模式,組織依照組織規則將 權限分派到所定義的角色下,再將角色分派給使用者,而非傳統的主體與受體之 授權模式[41],當使用者通過身份驗證後,取得一個適當的角色,即可擁有該角 色所能執行的權限。此外,本節將介紹以角色為基礎的存取控制模型架構及安全 原則。
2.1.1 模型架構
在以角色為基礎的存取控制模型中,使用者皆被分派到適當的角色,而對資 源的存取權限則是經由所屬的角色來決定,以角色為基礎的存取控制模型之基本
架構包含四個主要元素,分別是使用者、角色、權限及會期。四個主要元素說明 如下[22][23][32][34]:
1. 使用者(User):與系統互動的人或程式。
2. 角色(Role):通常為組織內部人員的職務,且會被授予適當的權限,以供 使用者對應。
3. 權限(Permission):對於物件的權利,包含存取方式、操作行為…等。
4. 會期(Session):使用者對應到可擔任的角色集合之過程,一個使用者可以 使用多個會期以擔任多個角色,但仍需受到限制條件的約束。
限制條件(Constraint)是限制「使用者、角色」和「角色、權限」之間所 被禁止的相對關係,如互斥角色、使用者數量、前提角色…等。詳細說明如下 [19][35]:
1. 互斥角色(Mutually Exclusive Roles):在特殊情況下,限制某些相衝突的角 色無法同時分派給同一使用者,如在一個進貨流程中,採購人員與驗收人員 的角色不能同時分派給同一使用者,避免產生弊端,因此該將這兩個角色定 義為互斥角色。
2. 使用者數量(Cardinality):限制角色分派給使用者的數量,特別是一些具有 特殊權限之角色,如專案經理、系統管理員…等。
3. 前提角色(Prerequisite Roles):使用者必須先具有某一個角色,才能成為另 一個角色,如要擔任系統分析師的角色,先要具有程式設計師的角色。
如圖 2.1 所示,使用者、角色、權限之間含有兩種關係,分別是使用者指派 與權限指派[24][35]:
1. 使用者指派(User Assignment):使用者和角色之間有多對多的指派關係,
也就是使用者能具有多個角色,而角色也能被指派給多個使用者。
2. 權限指派(Permission Assignment):角色和權限之間有多對多的指派關係,
也就是角色能具有多個權限,而權限也能被指派給多個角色。
圖 2.1 以角色為基礎的存取控制[24]
角色與角色之間可以是階層式的關係,也就是角色階層(Role Hierarchy)
[35],上層的角色能繼承下層角色的權限,如此一來,便可以省略許多重覆的權 限分派動作,以減少維護上的負擔。如圖 2.2 所示,測試工程師與程式設計師皆 能繼承專案成員的權限,而專案經理不僅能繼承測試工程師與程式設計師的權 限,更能透過角色階層的關係繼承專案成員的權限。
圖 2.2 角色階層範例圖
.1.2 安全原則
以角色為基礎的存取控制模型包含了三種安全原則,分別是最少權限、權責 區分及資料抽象化,詳細說明如下
2
[21][35]:
專案經理
測試工程師 程式設計師
專案成員
使用者指派 權限指派
物件
使用者 角色 操作
權限
會期
1. 最少權限(Least privilege):太多的授權不但對實際運用沒有幫助,且會造成 系統管理者的負擔,此外,太多的授權也可能因使用者有意或無意的操作,
而危及系統的安全。所以提供角色操作時剛好足夠的權限即可,不需過度提 供其並不需要的權限。
2. 權責區分(Separation of duties):主要在於避免權責相衝突的兩個角色,操作 同一資料所造成實務上的弊端。
3. 資料抽象化(Data abstraction):將實際的資料隱藏於操作中,使用者以日常 職務分類來取代電腦的低階操作,有助於提供給系統管理者或使用者正確的 語意,不致於因誤解而產生錯誤的授權,並能有效保持整體資料的一致性。
上述的三種安全原則中,以權責區分最為重要。權責區分主要是防止性質相 互衝突的角色由同一使用者來擔任,而權責區分又可分為靜態權責區分與動態權 責區分,詳細說明如下[5][26][35]:
1. 靜態權責區分(Static Separation of Duties):又稱為強互斥(Strong exclusion), 是指一個使用者不可擁有兩個互相衝突的角色,以避免利益衝突。如準備支 票的角色與核准支票的角色不能由同一使用者擔任。
2. 動 態 權 責 區 分 ( Dynamic Separation of Duties ): 又 稱 為 弱 互 斥 ( Weak exclusion),是指一個使用者可以擁有兩個相衝突的角色,但是不能同時啟動 擔任這些角色,必需選擇其中一角色來擔任。
2.2 工作流程
工作流程可以加速企業內部工作之自動化,在流程執行的過程中,流程參與 者根據各個工作項目中事先定義之程序規則執行工作,使此流程能順利完成。此 外,本節將介紹工作流程定義、組成元素、參考模型及工作流程管理系統。
2.2.1 定義
工作流程的觀念源自於企業流程—「公司內部參與者根據為達成公司整體或 特定目標所定義的規則,而與公司內外部參與者合作,建立一執行文件、資訊或 工作之價值產生過程」[8][42]。不過工作流程則偏向於牽涉資訊傳遞或可將工作 執行結果資訊化的相關活動,且可透過資訊科技協助進行流程自動化,並得以追 蹤與控制之企業流程[12]。
在工作流程管理聯盟(Workflow Management Coalition, WfMC)中將工作流 程定義為「將部分或全部工作程序自動化,且文件、資訊或工作由一個參與者傳 遞到另一個參與者執行的過程中,尚須遵守某些程序上之規則」[43]。其中工作 程序之自動化是在流程程序定義階段中設定,程序的制訂包含一系列的活動、規 則以及用以管理工作流程之相關控制資料[43]。
由上述的工作流程定義可知,企業為了達成整體或某特定目標,將全部工作 程序自動化,且在工作流程執行的過程中,參與者尚須遵守程序上之規則,而流 程自動化、規則…等相關資訊皆是在流程程序定義階段中設定。因此,工作流程 在企業內扮演著相當重要的角色,不僅能加速企業內部工作之執行,亦能替企業 獲取最大的商業利益。
2.2.2 組成元素
工作流程包含工作、工作連結與組織資源三項基本元素,彼此息息相關,各 項元素分述如下[12][17][25][44]:
1. 工作(Activity)
工作是組成工作流程不可或缺的主要元素之一,用以記錄相關資訊或控制流 程,依功能可以區分為一般型工作、路由型工作、迴圈型工作及子流程工作四種 不同類型之工作,其結構與轉變狀況如圖 2.3 所示,四種不同類型之工作詳細說
明如下:
一般型工作(Generic Activity):主要功能在紀錄工作的相關資訊,如:
工作說明、參與人員或角色以及可以使用的資源,也可紀錄工作的限制 資訊。
路由型工作(Route Activity):此工作不會紀錄工作的資訊,而是以判 斷條件決定接下來將執行的工作,因此不會變更工作流程與應用程式的 內容與資料。
迴圈型工作(Loop Activity):此工作主要在控制迴圈的反覆執行與儲存 迴圈的停止條件,此外,透過迴圈的工作連結可以連結至迴圈主體,即 迴圈中將執行的一連串工作。
子流程工作(Subflow Activity):子流程為主流程外部所執行的流程,
且可分為同步執行與非同步執行。其中同步執行是當子流程開始執行 時,此工作會暫停執行動作,直到子流程執行完畢才恢復執行;而非同 步執行則是當子流程開始執行時,此工作仍會繼續執行。
圖 2.3 工作之結構與轉變狀況圖[44]
2. 工作連結
工作連結為紀錄前、後工作的從屬關係,也可以加入處理工作流向的控制單 元,以處理前、後關係複雜的流程。特殊連結的型態可以區分為AND-Split、
AND-Join、OR-Split、OR-Join與Iteration等五類[43],其中矩形方塊表示工作流 程中的工作,箭頭符號代表流程進行方向,圓形符號表示控制流程的邏輯連結,
工作的五類特殊連結型態分別說明如下:
AND-Split:將單一工作執行緒切割成兩個或多個獨立而且可以平行處 理的工作執行緒。
工作 2
圖 2.4 AND-Split 工作連結
AND-Join:表示兩個或多個工作執行緒皆完成後,匯集合併成單一工 作執行緒。
圖 2.5 AND-Join 工作連結
OR-Split:將單一工作執行緒切割成兩個或多個工作執行緒,且可以選 擇任一工作執行緒執行。
工作 1 工作 3
AND-Split
工作 4
工作 1
AND-Join
工作 2 工作 4
工作 3
OR-Split
工作 2
工作 1
圖 2.6 OR-Split 工作連結
OR-Join:當前方兩個或多個工作執行緒其中之一完成後,即可繼續執 行後方單一工作執行緒。
圖 2.7 OR-Join 工作連結
Iteration:當一工作遭遇特定狀況或條件時,具有重複執行工作的能力,
圖 2.8 Iteration 工作連結
. 組織資源
工作流程的基本元素之一,組織資源不僅包含需要執行工作的參 與者
直到滿足所有限制狀況或條件才可繼續執行。
3
組織資源為
,亦需要工作相關的資訊和設備等資源來輔助工作之進行。詳細的參與者、
資訊及設備之說明如下:
工作 3
工作 4
OR-Join
工作 1工作 2 工作 4
工作 3
Iteractive activity loop
工作 1 工作 2 工作 3
參與者:一般使用者或特定角色,如:系統管理員、專案經理、某一部
或檔案…等。
.2.3 參考模型
由工作流程管理聯盟提出的「工作流程參考模型」[42],包含了五項一致性 的標
2.9 所示,工作流程參考模型是以工作流程引擎為核心,分別透過五個 介面
s)溝通,主要用以分析、
戶端應用程式(Workflow Client Applications)溝通,
工作能
(Workflow Enactment Services)溝通,如本
& Monitor Tools)溝通,用以追 門或單位…等,主要任務是執行工作或監督工作進度。
資訊:在工作流程中所需使用到的程式、工作資訊、文件 設備:輔助處理工作流程中之工作的機器或設備。
2
準與溝通介面,雖然各個工作流程系統之發展環境與應用技術不儘相同,但 在標準的資源共用、資料交換與流程運作規則下,仍然可以使工作流程系統正常 運作。
如圖
連結到五個構成元件,以擴充工作流程的功能與服務,並透過工作流程應用 程式介面(Workflow API, WAPI)和資料格式轉換(Interchange Formats)與這些 元件溝通[12]。五個介面與其構成元件說明如下[42]:
1. Interface 1:與流程定義工具(Process Definition Tool 建構與描述工作流程。
2. Interface 2:與工作流程客
告知使用者工作相關資訊,亦可啟用相關的應用程式工具或資料。
3. Interface 3:與被呼叫之應用程式(Invoked Applications)溝通,輔助 順利進行。
4. Interface 4:與其他工作流程服務
身系統之子流程或其他跨系統之工作流程。
5. Interface 5:與管理監控工具(Administration
蹤瞭解目前工作狀況,並可達到控制、管理與分析等目的。
圖 2.9 工作流程參考模型[42]
.2.4 工作流程管理系統
工作流程管理系統(Workflow Management System, WfMS)是透過軟體以定
義、建立與管理工作流程執行的系統 。而
工作流程引擎除了可以將流程程序的定義轉譯以符合系統需求外,也可以透過它 與其他工作流程參與者互動,如果有需要,也可以使用相關的資訊技術工具或應
用程式 。
此外 工作流程管理系統還提供工作管理與監控的功能,讓使用者可以重新 設定或繼續擴充工作內容 。如圖 所示,工作流程管理聯盟也針對此系統 提出標準化的應用程式基本架構,可供企業或開發者參考。
2
,可在一個或多個工作流程引擎上執行
[43]
,
[12] 2.10
圖 2.10 一般化工作流程管理系統產品架構[43]
2.3 策略聯盟
策略聯盟是在闡述組織與組織之間為了達成目的而產生之策略合作關係,不 僅可以替企業提升在市場上的競爭優勢,也可以與合作的企業共同分攤成本,進 行技術、資源與知識的互補,形成雙贏的局面。此外,本節將介紹策略聯盟定義 及型態。
2.3.1 定義
組織間合作的種類與方式繁多,各專家學者對於各種合作關係亦賦予不同的 專有名詞且加以定義,舉凡「聯盟」、「合作」、「策略合夥」、「產業合作」、「企業 間合作關係」…等,大都表示相同的概念,且均與「策略聯盟」具有極為相近的 意義,均在闡述組織與組織之間為了達成目的而產生之策略合作關係。
各專家學者對於合作關係所使用的名詞有所差異,對「策略聯盟」之定義亦 有不同的解釋。早期學者認為策略聯盟只是一種臨時組織,當聯盟目的達成後,
聯盟即宣告結束,為一種短期合約關係[10];而後來的學者認為策略聯盟乃是連 結各公司企業活動的一種正式、長期但非合併之聯盟[33];國內學者則認為策略 聯盟是指兩家或兩家以上的獨立公司,基於其短、中或長程策略的互惠原則下,
簽訂合同,以不同的形態和關聯性相互合作,提升雙方競爭能力,而各家公司仍 維持其獨立法律個體的企業合作過程[7]。本研究將國內外學者提出之策略聯盟 定義加以彙整,如表 2.1 所示。
表 2.1 策略聯盟定義彙整表
年代 學者 策略聯盟定義
1986 Porter & Fuller[33] 連結各公司企業活動的一種正式、長期但非合併 之聯盟。
1990 Lewis[30] 企業間基於相互需要與分攤風險之考量,經由合 作以達成共同目標。
1992 Takac & Singh[40] 聯盟成員合作以達成某一專案協定之管理,此專 案設計以達成某一策略性目標。
2001 Griffin & Pustay[27] 兩 家 或 兩 家 以 上 的 企 業 為 了 彼 此 利 益 相 互 合 作,策略聯盟夥伴交換、分享專業技術、行銷專 長及管理能力。
1992 陳金帶、袁建中[7] 策略聯盟是指兩家或兩家以上的獨立公司,基於 其短、中或長程策略的互惠原則下,簽訂合同,
以不同的形態和關聯性相互合作,提升雙方競爭 能力,而各家公司仍維持其獨立法律個體的企業
合作過程。
1996 吳青松[2] 策略聯盟為產業競爭者間非市場導向之公司交 易,亦即聯合各公司活動的一種正式、長期但非 合併之合作關係。包括聯合生產、產能互換、聯 合行銷、技術互換、合資以及間接投資。
2000 黃崇哲[3] 廠商間透過合作關係,互補資源,以互利互惠的 原則達成廠商的策略目標。
由國內外學者對於策略聯盟的描述,可大致歸類出下列三項共同要素:
1. 存在於兩個或兩個以上組織相互合作的關係。
2. 基於共同的策略目標。
3. 具有正式契約的關係。
2.3.2 策略聯盟之型態
策略聯盟型態的分類猶如策略聯盟定義一樣,根據各專家學者的認知與見解 不同而有所差異,策略聯盟型態的分類隨著分類基礎不同而有所區分,如「目 的」、「合作方向」、「地理位置」、「企業價值鏈」、「企業規模」…等[11]。本研究 將國內外學者提出之策略聯盟型態加以彙整,如表 2.2 所示。
表 2.2 策略聯盟型態彙整表
年代 學者 分類基礎 策略聯盟型態
價值活動 1. 技術發展聯盟。
2. 作業與後勤聯盟。
3. 行銷、銷售及服務聯 盟。
4. 多重活動聯盟。
1986 Porter & Fuller[33]
地理位置 1. 單國聯盟。
2. 多國聯盟。
聯盟方式 1. X 聯盟:聯盟內企業分 別執行不同的價值鏈活 動;一強一弱,功能分 功。
2. Y 聯盟:在企業所擁有 相同或相似的價值鏈活 動內聯盟;實力伯仲,
同時從事同一功能。
策略網路 1. 附加值鏈網路。
2. 技術分享網路。
3. 發展網路。
1990 Lewis[30]
契約 1. 交易聯盟。
2. 協調活動聯盟。
3. 共享活動聯盟。
4. 多重活動聯盟。
1992 Takac & Singh[40] 聯盟目的 1. 共同行銷合夥。
2. 產業內合夥。
3. 消費者及供應商合夥。
4. 資訊技術提供者合夥。
2001 Griffin & Pustay[27] 企業策略聯盟之範圍 1. 全面式聯盟。
2. 功能型聯盟。
1991 蔡正陽、許政郎[9] 企業價值鏈 1. 研究發展聯盟。
2. 生產及後勤聯盟。
3. 行銷及售後服務聯盟。
4. 財務聯盟。
5. 人事聯盟。
6. 資訊聯盟。
7. 多重活動聯盟。
1996 司徒達賢[1] 合作方向與企業規模 1. 垂直式聯盟。
2. 水平式聯盟。
3. 不對稱式聯盟。
由於各專家學者對於策略聯盟型態之分類基礎有所差異,導致產生許多不同 的策略聯盟型態。國內學者提出適合國內企業採行之策略聯盟型態,歸類出「垂 直型策略聯盟」、「水平型策略聯盟」、「綜合型策略聯盟」及「專案型策略聯盟」
四種策略聯盟型態並加以定義[6],經本研究彙整於表 2.3。
表 2.3 適合國內企業採行之策略聯盟型態彙整表[6]
策略聯盟型態 定義
垂直型策略聯盟 係指聯盟內容參與成員分別從事其核心作業,透過相互合作 之方式完成整體之商業行為,並結合各參與成員之資源,以 創造更高的附加價值。
水平型策略聯盟 整合各企業相似之功能,以有效地運用資源,擴大經濟規模,
使各參與成員能因此一策略聯盟提升在市場之競爭地位。
綜合型策略聯盟 此一策略聯盟型態可能包含垂直及水平之聯盟方式,並可能 橫跨數個產業及數個國家。
專案型策略聯盟 各企業因某一特殊商機、產品或事件,進行短期之策略聯盟。
2.4 跨組織工作流程
跨組織工作流程為組織與組織之間為了達成特定目的而產生的工作流程,不 僅能提高組織間合作的效率,更能加速整體工作之進行。此外,本節將介紹跨組 織工作流程之架構及存取控制機制於跨組織工作流程。
2.4.1 流程架構
學者Chebbi與Tata對於跨組織的工作流程提出了支援組織之間合作的三種需 求,分別為彈性支援、重視隱私概念及維護已建立的工作流程與工作流程管理系 統[18][20],分述如下:
1. 彈性支援(Flexibility support):在許多合作伙伴的環境下,合作伙伴常態的 加入或離開一個跨組織的合作,必須有一解決方法來調節此彈性。
2. 重視隱私概念(Privacy respect principle):為了維護組織互動與資料交換,
跨組織的合作需有一個可靠的工作流程可視層級,並且需將組織間的可視層 級降到最低。
3. 維護已建立的工作流程與工作流程管理系統(Established workflow and WfMS preservation):為了使合作的組織能整合彼此不同的工作流程,而必
須允許組織使用原本已建立的工作流程,當已建立的工作流程或系統發生改 變時,則必須浪費更多的成本與時間,因此需有一方法能完整整合已建立的 工作流程。
圖 2.11 為學者 Chebbi 與 Tata 所提出之跨組織工作流程架構,允許分散的合 作伙伴能適時的加入跨組織工作流程,並簡化了合作組織間的溝通,使跨組織工 作流程能呼叫外部的應用程式和允許外部應用程式對跨組織工作流程喚起並管 理,此架構重視隱私概念,將組織間的可視層級降到所需的最低程度,並完整整 合已建立的工作流程。
圖 2.11 跨組織工作流程架構圖[18]
此架構包含「組織」、「封裝器」及「契約機構」三個元件,彼此相互連接 [18][20],詳細說明如下:
1. 組織(Organization):內部皆有各自的工作流程管理系統,包含企業流程與 相關資料。
2. 封裝器(Wrappers):為每個工作流程的代理者和轉接者,透過中介軟體連 接工作流程和契約機構。
3. 契約機構(Contracting Authority):扮演了監視和控制跨組織工作流程的角 色,包含了註冊、合作方針、本地資料庫及控制器,詳細說明如下:
註冊(Registry):提供企業搜尋合作伙伴和宣傳本身的能力,使企業能 得到對彼此有幫助的合作伙伴資訊,並且能分享企業語意資訊和企業流 程資源。
合作方針(Cooperation Policies):描述各個合作伙伴所扮演的角色及責 任,並定義合作伙伴的介面,包含工作及其執行順序,亦定義了工作流 程互動上的限制條件。
本地資料庫(Local Database):儲存在跨組織工作流程執行階段所產生 之本地及短暫資訊,如工作流程和合作執行狀態。
控制器(Controller):根據已建立之合作方針來管理各組織工作流程間 的互動。
2.4.2 存取控制機制於跨組織工作流程
由於跨組織工作流程涉及的範圍極大,且包含許多的使用者及資源,因此需 要存取控制機制來控管使用者對於資源的存取,Kang與Park等學者對於跨組織工 作流程提出了存取控制機制所需的三種需求,分別為隔離工作流程與組織的安全 基礎建設、更精細且以情境為基礎的存取控制,及支援動態的限制條件[29],分 述如下:
1. 隔離工作流程與組織的安全基礎建設(Decoupling Workflow and Organization Security Infrastructures):由於在一個跨組織工作流程的生命週期內,可能發 生某些組織產生變化,如一個新的組織可能轉變成舊的組織或組織可能與其 他組織進行合併或分離,導致需要重整跨組織工作流程之安全規格,但這不
是實際可行的,因此,跨組織工作流程需要隔絕組織層級的改變,特別是安 全規格,如誰能存取某些資料,以便跨組織工作流程能順利的進行。
2. 更精細且以情境為基礎的存取控制(Fine-grained and Context-based Access Control):傳統的存取控制決策是基於主體與受體,主體可能為使用者或代 表使用者的程式,受體為資料或系統中的資源,而主體對於受體的存取控制 決策是由作業之系統所決定。由於跨組織工作流程大部份由大規模數量的工 作流程所組成,普通的存取控制機制對於跨組織工作流程可能太過粗糙,因 此,需要一個更精細的存取控制機制,而且是基於使用者的工作情境,根據 使用者所在的工作而授予權限。
3. 支援動態的限制條件(Supporting Dynamic Constraint):在跨組織工作流程 環境中,需要一些動態的限制條件,動態的限制條件是基於一個特定工作的 使用者,如在一個工作實例(instance)中,一個使用者執行準備支票的工 作,則無法執行核准支票的工作。然而,跨組織工作流程可能包含數個獨立 的工作流程,因此需要一些架構在參與的工作流程中分享相關的執行紀錄。
圖 2.12 為學者所提出之存取控制機制運用於跨組織工作流程架構,除了主 體的使用者與受體的資源外,尚包含「特定工作存取控制模組」及「特定組織存 取控制模組」兩個模組與「監控伺服器」及「工作流程安全伺服器」兩個伺服器 [29],詳細介紹如下:
1. 特定工作存取控制模組(Task-specific Access Control Module, TACM):由每 個工作流程控制且執行特定工作安全方針。
2. 特 定 組 織 存 取 控 制 模 組 ( Organization-specific Access Control Module, OACM):由每個組織控制且執行由每個組織所定義之安全方針。
3. 監控伺服器(Monitor Server):透過此伺服器能接收其他組織所傳送之特定 事件。
4. 工作流程安全伺服器(Workflow Security Server, WSS):提供特定工作流程 安全基礎建設資訊,及提供特定工作流程與參與組織之安全基礎建設的比對
資訊,以防止因為參與的組織產生變化而產生之問題。
圖 2.12 存取控制機制於跨組織工作流程架構圖[29]
2.5 小結
在適合國內企業採行之垂直型、水平型、綜合型及專案型四種策略聯盟型態 中,以垂直型策略聯盟與水平型策略聯盟兩種策略聯盟型態較為常見,為現實社 會中企業較常採用之合作模式,垂直型策略聯盟之參與者分別從事其核心作業,
透過此合作模式連結上游及下游企業,僅是企業之間根據簽訂之契約進行產品流 通,如一套裝電腦之產生,可由電腦零件製造工廠製造出來的零件,出貨到電腦 組裝公司組裝,最後出貨到品牌電腦公司掛牌販售。對於此垂直型的跨組織合作 模式,依舊可分為數個各自企業其內部之工作流程,因此,各企業對於其人員的 存取控制,皆採用各企業內部之存取控制機制,助於達到整體跨組織工作流程之 安全性與便利性。
而另一種常見之策略聯盟型態,水平型策略聯盟,亦稱水平式跨組織合作,
此水平式的跨組織合作模式,與垂直型策略聯盟合作模式不同在於參與者皆來自 相同性質的組織或企業,共同合作以達成特定目標,如多家軟體開發公司,共同 合作研發一套大型金融資訊系統。此跨組織合作模式並非長期運作,且每次合作
之目標不同,所需要的角色職務與工作內容亦不同,且使用者包含各個不同企業 的人員,因此,本研究著重在水平式的跨組織工作流程合作模式,各組織的參與 者共同擔任組織間所定義好的角色及執行所定義好的工作流程,對於使用者與角 色之間及角色與工作之間的關係,需有一完善之存取控制機制來控管,並加入更 嚴謹的限制條件規則,使此跨組織工作流程兼顧公平性及安全性。
而由Kang與Park等學者提出之存取控制機制於跨組織工作流程[29],屬於一 種水平式跨組織的合作,對於每個跨組織的工作流程,皆有相對應之存取控制機 制及資源,並有監控伺服器及工作流程安全伺服器兩個伺服器監督工作流程的進 行,當使用者進入跨組織工作流程時,根據本身在原本組織內所擔任的角色執行 工作並存取相關資源,但由於參與跨組織工作流程的組織之組織結構並非完全相 同,且各組織對於組織內部之角色職務定義亦非完全相同,若有相同角色職務而 來自不同組織之使用者,卻因角色職務名稱相同而在此跨組織工作流程中擁有相 同權限,可能會造成某一方之使用者實質權限上升或下降,若沒有適當的控管,
不但容易產生安全上的問題,也有失兩組織間的公平性。
因此,本研究認為需在進行跨組織工作流程之前,由各組織高階人員進行會 議協商重新定義每位使用者在此跨組織工作流程所擁有之層級,並將此層級之定 義轉換成數字型式之分數來表現,使用者根據此分數取得跨組織工作流程中之角 色執行工作,且過程中會透過更嚴謹的限制條件規則來約束,不僅使企業在進行 跨組織的合作時有更深一層的保護,亦讓整個跨組織工作流程在公平的環境下順 利進行。
第三章 以角色為基礎的存取控制於跨組織工作流程
由於跨組織工作流程所涉及的範圍極大,包含許多的使用者及資源,且彼此 企業的規模、組織結構並非完全相同,對於使用者執行工作、存取相關權限…等 行為,傳統的存取控制機制已無法負荷管理此跨組織工作流程,因此,我們使用 以角色為基礎的存取控制機制並加以延伸應用,針對跨組織工作流程內之使用 者、角色及工作三個元素加以分析定義,並於各元素之間建立限制條件規則,有 效控管三個元素之間的相對關係。
在跨組織工作流程的合作中,組織之間根據合作的目標,產生一跨組織工作 流程,定義出此跨組織工作流程中的所有工作及可執行工作之角色,而各組織參 與的人員,皆屬於此跨組織工作流程中同一使用者集合。
此跨組織工作流程共可分為兩個階段,一為使用者取得角色階段,另一為使 用者取得角色執行工作階段,每一階段皆有相對應之限制條件,使用者取得角色 階段之限制條件,目的在於篩選使用者取得角色集合的數量;而使用者取得角色 執行工作階段之限制條件,則是判斷使用者所擔任的角色對於該工作是否有權限 執行,以達成以角色為基礎的存取控制之安全原則,如最少權限、權責區分…等。
此外,本章將介紹以角色為基礎的存取控制於跨組織工作流程之分析及架構,並 以範例說明。
3.1 工作流程分析
根據工作流程管理聯盟所定義之工作流程,整體或部份工作流程在執行前,
會有一定義階段,定義出此工作流程中的各個工作、規則及管理工作流程之相關 控制資料。在本研究中,跨組織的工作流程亦是如此,組織之間不僅會共同定義 出此跨組織工作流程中的各個工作,也會定義出能夠執行各個工作的角色集合。
以角色為基礎的存取控制於跨組織工作流程包含「使用者」、「虛擬角色」及「工
作」三個元素與「使用者取得虛擬角色階段」及「使用者取得虛擬角色執行工作 階段」兩個階段的限制條件,各項元素及限制條件分述如下。
3.1.1 使用者
在跨組織的合作中,參與的使用者可能來自不同的企業,因此,在進入跨組 織工作流程取得適當角色執行工作之前,本身還只是代表著各自的企業及角色職 務,其中,企業內部角色職務之定義是根據企業之規則,包括人員資歷、能力…
等因素決定;而企業規模的定義,我們參考經濟部中小企業處所定義之中小企業 認定標準[4],如表 3.1 所示,可將企業分類為中小、小型規模。
表 3.1 中小企業認定標準表[4]
規模 中小企業
行業別 原則 例外 小企業
製造業 營造業 礦業 土石採取業
實收資本額在新臺 幣八千萬元以下
經常僱用員工 數未滿二百人
經常僱用員工 數未滿二十人
農林漁牧業 水電燃氣業 批發及零售業 住宿及餐飲業 運輸倉儲及通信業
金融及保險業 不動產及租賃業 專業科學及技術服務業
教育服務業
醫療保健及社會福利服務業 文化運動及休閒服務業
其他服務業
前一年營業額在新 臺幣一億元以下
經常僱用員工 數未滿五十人
經常僱用員工 數未滿五人
由於企業內部的角色職務名稱繁多且不易比較,所以我們以數字型式的分數 來代表角色職務,又稱為角色分數,分數愈大,代表該角色職務之層級與所擁有
之權限也愈大;而在不同規模的企業間可能發生角色職務名稱相同之情形,在角 色職務名稱相同之情形下,較大規模企業之人員資歷、能力…等因素,往往高於 較小規模之企業,且權限也愈大。因此,我們採用使用者所屬企業之規模(Business Scale)及原始角色(Original Role)兩個條件來決定使用者的原始角色分數
(Original Role Score),而使用者所擔任角色之原始角色分數是由參與跨組織工 作流程之各組織高階人員,經過彼此會議協商決定,以解決各組織角色結構的不 同。如表 3.2 所示,為一中小規模企業與一小規模企業進行跨組織合作之使用者 原始角色分數結構範例,因為彼此角色的組織結構不同,所以共同定義出來的角 色分數也不同;而在此範例中,中小企業廠長角色之使用者與小企業副總經理角 色之使用者分數相同,代表能夠取得跨組織工作流程中的角色之集合亦相同。有 關使用者之定義如下所述:
【使用者】u = (bs, or, ors)
代表使用者 u 由企業規模 bs、原始角色 or,及原始角色分數 ors 組成。
U = {u1, u2, …},代表使用者的集合。
BS = {bs1, bs2, …},代表企業規模的集合。
OR = {or1, or2, …},代表原始角色的集合。
ORS = {ors1, ors2, …},代表原始角色分數的集合。
表 3.2 跨組織工作流程原始角色分數結構範例表
角色分數 中小企業 小企業
總經理 10 8
副總經理 8 7
廠長 7 N/A
處長 5 N/A
經理 3 2
副理 2 N/A
職員 1 1
3.1.2 虛擬角色
使用者在參與跨組織工作流程之前,僅擔任各自企業之原始角色職務,稱之 為「原始角色」,由於水平式的跨組織合作之目標並非每次皆相同,且所使用的 角色亦非相同。因此,我們定義在跨組織工作流程內執行工作的角色為「虛擬角 色」(Virtual Role),代表使用者在進入跨組織工作流程時取得之角色只是暫時 的,當跨組織工作流程結束時,使用者會卸下此虛擬角色,回復成原本企業之原 始角色。在跨組織的工作流程中,使用者欲取得角色進入跨組織工作流程並非使 用原本在企業裡的角色,而是根據限制條件取得能夠擔任的虛擬角色之集合。本 研究所定義之虛擬角色包含三個屬性,各屬性之定義如下:
虛擬角色分數:代表此虛擬角色的分數,分數愈大,相對著角色層級愈高,
而虛擬角色分數也符合角色階層的概念,如在一專案中,專案經理能繼承程 式設計師的權限,而在此專案中的虛擬角色分數定義中,專案經理的虛擬角 色分數必定會大於程式設計師的虛擬角色分數,當使用者的原始角色分數足 以擔任專案經理,亦代表其虛擬角色分數能繼承程式設計師的權限。
使用者數量:如同以角色為基礎的存取控制之使用者數量(Cardinality)限 制條件[35],代表著此虛擬角色能夠分派給使用者的數量,虛擬角色授予給 使用者的數量應予以限制,特別是一些權限特殊的虛擬角色,如專案經理、
系統管理員…等角色需要有使用者數量的限制。
可擔任時間:代表著此虛擬角色分派給使用者所限制的開始與結束時間,如 將可擔任時間設定為上班時間,以免使用者取得虛擬角色時間過長,執行完 工作後卻還有時間使用該虛擬角色執行其他工作,獲得其他權限存取資源,
而造成舞弊事件發生。
【虛擬角色】vr = (vrs, UC, [Tvr-str
, T
vr-end])
代表虛擬角色 vr 由虛擬角色分數 vrs、可分派給使用者之數量 UC,及可擔
任時間[Tvr-str, Tvr-end]組成。
VR = {vr1, vr2, …},代表虛擬角色的集合。
VRS = {vrs1, vrs2, …},代表虛擬角色分數的集合。
UC,代表虛擬角色可分派給使用者的數量,為一自然數。
[Tvr-str, Tvr-end],代表虛擬角色能夠分派給使用者的開始與結束時間。
3.1.3 使用者取得虛擬角色階段之限制條件
當使用者欲取得虛擬角色執行跨組織工作流程之工作前,會經過此限制條件 篩選階段,決定出使用者在跨組織工作流程中能夠擔任的虛擬角色之集合。以下 是使用者取得虛擬角色階段限制條件介紹:
原始角色分數大於等於虛擬角色分數:在本研究中,跨組織工作流程在定義 階段時,組織間會定義出能夠執行跨組織工作流程中之各個工作的虛擬角色 和該虛擬角色的分數。而在此虛擬角色分數限制條件下,使用者根據原始角 色分數,取得大於所需之虛擬角色分數下所有虛擬角色集合。
已分派此虛擬角色給使用者的數量小於所定義能分派給使用者的數量:此使 用者數量應在虛擬角色定義階段時所決定。當使用者請求擔任虛擬角色時,
已分派此虛擬角色給使用者的數量,必須小於此虛擬角色定義能分派給使用 者的數量。
取得虛擬角色的時間需在所定義之時間區間內:在虛擬角色定義階段時,會 定義此虛擬角色能分派給使用者的開始與結束時間,而使用者請求擔任虛擬 角色的時間,必須在此虛擬角色定義之可擔任時間區間內。
【使用者取得虛擬角色階段限制條件規則】∃ui
∈ U, ∀vr
j∈ VR: (ors
i≥ vrs
j) and (Count(vr
j) < UC
vrj) and (T
app∈ [T
vr-str, T
vr-end]) ⇒ UVRA(u
i) = {vr
j}
使用者 u 由企業規模 bs、原始角色 or,及原始角色分數 ors 組成,虛擬角色
vr 由虛擬角色分數 vrs、可分派給使用者之數量 UC,及可擔任時間[Tvr-str, Tvr-end] 組成,存在一個屬於使用者集合 U 的使用者 ui,對於所有屬於虛擬角色集合 VR 的虛擬角色 vrj,若使用者 ui的原始角色分數 orsi大於等於虛擬角色分數 vrsj,且 虛擬角色已分派給使用者的數量 Count(vrj)小於所定義能分派給使用者之數量 UCvr,且使用者請求擔任虛擬角色的時間 Tj app包含在所定義能分派給使用者之時 間區間內[Tvr-str, Tvr-end],則此使用者 ui之使用者、虛擬角色分派關係(User-Virtual Role Assignment)UVRA(ui)的虛擬角色為{vrj}集合。
orsi ≥ vrsj,代表使用者的原始角色分數大於或等於此虛擬角色之分數,即使 用者可以擔任此虛擬角色或小於此虛擬角色分數的所有虛擬角色集合。
Count(vrj) < UCvrj,代表已分派此虛擬角色給使用者的數量,必須小於此虛 擬角色定義分派給使用者的數量限制。
Tapp ∈ [Tvr-str, Tvr-end],代表使用者請求擔任虛擬角色的時間,必須在此虛擬
角色定義之可擔任時間區間內。
3.1.4 工作
跨組織工作流程內的每個工作,皆有詳細的定義,包括所能執行此工作的虛 擬角色集合、可執行日期、互斥角色集合及工作執行紀錄。詳細定義如下:
虛擬角色集合:代表能夠執行此工作的虛擬角色集合,由所有組織在定義階 段共同定義。
可執行日期:代表某些工作是有期間性的,如資料庫管理師進行企業資料庫 之備份工作需要花上幾天的時間、資產管理師對企業內部進行資產盤點之工 作亦是如此,配合使用者請求擔任虛擬角色的時間限制,形成一個完整的日 期、時間限制,讓使用者能在某一特定日期內的某個時間區間擔任虛擬角色 執行工作。
互斥角色集合:包含了能執行此工作而有角色衝突關係的角色集合,如請款
的工作可分為準備支票與核准支票,前者能夠執行的角色可為經理或職員,
而後者能夠執行的角色只有經理,因此,無法由同一使用者擔任經理及職員 兩個角色執行請款的工作。
工作執行紀錄:為使用者執行工作的紀錄,用以產生能再執行此工作之合法 角色(Legal Role),包含了執行此工作的使用者、執行日期、所擔任之虛擬 角色及合法角色,合法角色是根據使用者在最近時間內執行此工作所擔任之 虛擬角色,與此工作所定義出有角色互斥關係的虛擬角色集合比對後,剩餘 無互斥關係的虛擬角色集合。
【工作執行紀錄】reca
= (u, T
exe, vr, LR)
reca代表工作 a 的工作執行紀錄,是由執行此工作之使用者 u、執行日期 Texe、 虛擬角色 vr,及合法角色集合 LR 組成。
LR = {lr1, lr2, …},代表未與執行工作 a 之虛擬角色互斥的合法角色集合。
如表 3.3 所示,假設能執行請款工作的虛擬角色包含會計部經理、會計部職 員、採購部經理及採購部職員,而經理與職員為互斥角色,當張三已擔任會計部 經理執行請款工作,而在此請款工作內,與會計部經理互斥之角色為會計部職員 與採購部職員,因此,其他可再執行請款工作之合法角色集合,只剩會計部經理 與採購部經理角色。有關工作執行紀錄與工作之定義如下所述:
表 3.3 工作執行紀錄表
工作 使用者 執行日期 擔任角色 合法角色
張三 2007/5/21 會計部經理 會計部經理 採購部經理 請款
李四 2007/5/25 採購部職員 採購部職員 會計部職員
【工作】a = (CVR, [Tact-str
, T
act-end], MER, rec)
代表工作 a 由虛擬角色集合 CVR、可執行日期[Tact-str, Tact-end]、互斥角色集
合 MER 及工作執行紀錄 rec 所組成。
IOW = {a1, a2, …},代表工作的集合,形成一跨組織工作流程。
CVR = {cvr1, cvr2, …},代表能執行此工作之虛擬角色集合。
[Tact-str, Tact-end],代表此工作可以被執行的開始與結束日期。
MER = {cvr1 ⊕ cvr2, cvr3 ⊕ cvr4, …},代表能執行此工作卻有角色互斥的虛擬 角色組合集合。
3.1.5 使用者取得虛擬角色執行工作階段之限制條件
當使用者取得虛擬角色之集合後,必須選擇一虛擬角色在跨組織工作流程中 執行一工作,而在使用者欲以虛擬角色執行工作之前,必須經過此檢驗階段,判 斷使用者擔任此虛擬角色是否有權限能執行該工作,以下是使用者取得虛擬角色 執行工作階段限制條件介紹:
擔任能執行此工作之虛擬角色:組織間在定義跨組織工作流程內的工作時,
也會定義出能夠執行該工作的虛擬角色之集合,使用者必須擔任其中之一虛 擬角色執行工作。
執行工作的日期需在所定義之日期區間內:當跨組織工作流程在定義時,會 定義出各個工作可執行的開始與結束日期,而使用者執行工作的日期,必須 在此日期區間內。
擔任屬於此工作之合法角色:為避免使用者擔任有利益衝突的兩個虛擬角色 執行同一個工作,如請購人員與核准人員,無法由同一個使用者在同一個工 作內擔任這兩個角色,以免發生核准自已請購的訂單。所以我們根據工作內 的一個工作執行紀錄屬性,判斷使用者是否使用合法的虛擬角色執行同一個 工作。
【使用者取得虛擬角色執行工作階段限制條件規則】∃ui
∈ U, ∀vr
j∈ VR, ∀a
k∈ IOW: UVRA(u
i) = {vr
j} and (vr
j∈ CVR(a
k)) and (T
exe∈ [T
act-str, T
act-end]) and (vr
j∈ LR(a
k)) ⇒ UVRAA(u
i, vr
j) = {a
k}
存在一個屬於使用者集合 U 的使用者 ui,所有屬於虛擬角色集合 VR 的虛擬 角色 vr,對於所有屬於跨組織工作流程 IOW 的工作 aj k,若使用者 ui形成使用者、
虛擬角色分派關係 UVRA(ui)的虛擬角色集合為{vrj},代表使用者 ui可擔任虛擬 角色 vrj,且虛擬角色 vrj屬於能執行工作 ak的虛擬角色集合 CVR(ak),且執行工 作的日期 Texe屬於所定義能執行工作 ak之日期區間內[Tact-str, Tact-end],且虛擬角色 vrj屬於工作 ak之合法角色集合 LR(ak),則與使用者、虛擬角色形成使用者、虛 擬角色及工作分派關係(User-Virtual Role-Activity Assignment)UVRAA(ui, vrj)的 工作為{ak},代表使用者 ui可以此虛擬角色 vrj執行工作 ak。
vrj ∈ CVR(ak),代表使用者所擔任之虛擬角色,必須屬於欲執行之工作所定 義好的虛擬角色集合之一。
Texe ∈ [Tact-str, Tact-end],代表使用者所擔任虛擬角執行工作的時間,必須在此 工作定義之執行日期區間內。
vrj ∈ LR(ak),代表使用者所擔任的虛擬角色,必須屬於工作之合法角色集合 之一。
3.2 工作流程架構
本研究的研究架構共可分為兩階段,一為使用者取得虛擬角色階段,另一為 使用者取得虛擬角色執行工作階段,每一階段皆有限制條件。本研究架構圖如圖 3.1 所示。
使用者
【定義 1】
使用者-虛擬角色 限制條件
【限制規則 1】
虛擬角色
【定義 2】
虛擬角色-工作 限制條件
【限制規則 2】
2 6 7
3 4 跨組織工作流程
【定義 3、4】
5 1
圖 3.1 研究架構圖
使用者取得虛擬角色階段,包含了使用者、虛擬角色兩個元素及使用者取得 虛擬角色的限制條件,使用者欲進入跨組織工作流程,需先根據虛擬角色所定義 之虛擬角色分數、可分派給使用者之數量及可分派給使用者之時間區間,決定使 用者所能擔任之虛擬角色集合。
使用者取得所能擔任之虛擬角色集合後,即進入第二個階段,使用者取得虛 擬角色執行工作階段,包含了使用者、虛擬角色、工作三個元素,及使用者取得 虛擬角色執行工作的限制條件,使用者在能擔任之虛擬角色集合中選擇一虛擬角 色執行工作,根據工作所定義之能執行此工作之虛擬角色集合、可執行日期及判 斷使用者所擔任之虛擬角色是否為合法角色,來決定使用者是否有權限以此虛擬 角色執行此工作。合法角色是根據使用者在最近時間內執行此工作所擔任之虛擬 角色,與此工作所定義出有角色互斥關係的虛擬角色集合比對後,剩餘無互斥關 係的虛擬角色集合。
3.3 工作流程架構範例
如表 3.4 所示,組織一與組織二所進行之水平式跨組織工作流程,假設所共 同定義之虛擬角色中,會計部經理之虛擬角色分數定義為 3,可分派給使用者之 數量定義為 2,可擔任時間定義為 09:00~17:00;會計部職員之虛擬角色分數定 義為 1、可分派給使用者之數量定義為 5、可擔任時間定義為 09:00~17:00。如 表 3.5 所示,組織所共同定義跨組織工作流程之工作中,工作 6 定義為請款的工 作,而能執行工作 6 的虛擬角色集合定義為會計部經理與會計部職員,可執行日 期定義為 2007/5/28~2007/5/30,互斥角色集合定義為會計部經理與會計部職員。
表 3.4 研究架構範例-虛擬角色資料表
虛擬角色 虛擬角色分數 可分派數量 可分派開始時間 可分派結束時間
會計部經理 3 2 09:00 17:00
會計部職員 1 5 09:00 17:00
*互斥角色集合:{會計部經理、會計部職員}
表 3.5 研究架構範例-工作資料表
工作 可執行之虛擬角色 可執行開始日期 可執行結束日期
請款 會計部經理
會計部職員 2007/5/28 2007/5/30
如表 3.6、表 3.7 所示,王五與趙六分別擔任來自組織一與組織二的會計部 經理,經過兩組織會議協商決定,兩人所擔任之原始角色的分數分別為 4 與 3,
若此時日期為 2007/5/29,時間為 10:00,管理者已分派給會計部經理與會計部職 員之使用者數量為 0,而王五與趙六兩人都欲擔任會計部經理之角色,則因王五 與趙六兩人的原始角色分數皆滿足會計部經理之虛擬角色分數,且使用者數量亦 符合虛擬角色所定義可分派給使用者之數量,皆符合使用者取得虛擬角色階段之 限制條件,因此,如線 1 與線 2 所示,兩人皆能擔任會計部經理之虛擬角色;如 線 3 所示,會計部經理屬於請款工作所定義之虛擬角色集合之一,根據請款工作
執行紀錄,會計部經理為合法角色,皆符合使用者取得虛擬角色執行工作階段之 限制條件,因此,兩人皆能執行請款的工作;如線 4 所示,因會計部經理之虛擬 角色分數大於會計部職員之虛擬角色分數,所以趙六亦能繼承會計部職員的權 限;但當趙六以會計部職員之虛擬角色再次執行請款工作時,會因請款工作執行 紀錄中,趙六能再擔任之合法角色不包含會計部職員,如表 3.8 所示,而被使用 者取得虛擬角色執行工作階段之限制條件阻止執行請款的工作,且以虛線 5 表示 趙六未能以會計部職員身份執行請款工作,如圖 3.2 所示。
表 3.6 研究架構範例-使用者資料表
公司 姓名 原始角色
組織一 王五 會計部經理
組織二 趙六 採購部經理
表 3.7 研究架構範例-原始角色資料表
角色分數 組織一 組織二
會計部經理 4 3
表 3.8 研究架構範例-工作執行紀錄資料表
工作 使用者 執行日期 擔任角色 合法角色
請款 趙六 2007/5/29 會計部經理 會計部經理
使用者
【定義 1】
組織一
王五 趙六
圖 3.2 研究架構範例圖
1
2
3 4 5
6 7
虛擬角色
【定義 2】
跨組織工作流程
【定義 3、4】
組織二
使用者-虛擬角色 限制條件
【限制規則 1】
虛擬角色-工作 限制條件
【限制規則 2】
會計部經理 會計部職員
請款
1 2 4
3 5