IBM DB2 Content Manager 憑借其極好的內容管理和流程管理的特性，被廣泛的采用於企業解決方案中。Multi-tenancy 由於可以為企業節省資源，越來越受到企業解決方案的使用者和提供者的青睐。Multi-tenancy 環境中，客戶組織（tenant）的數據不允許被共享，所以如何保護支持 Multi-tenancy 的 IBM DB2 Content Manager 解決方案中每個 tenant 的數據使其不能被其他 tenant 所訪問，是至關重要的。
簡介
IBM DB2 Content Manager
IBM DB2 Content Manager 提供了一個完整的解決方案來存儲和檢索任何格式的文檔，用戶可以根據自身的商業需要使用它來管理非結構化的文檔，Content Manager 還提供了強大的數據管理能力和靈活的文檔路由功能。除此之外，Content Manager 具有完善的數據保護能力，Content Manager 通過訪問控制列表可以對資源進行訪問控制以保證只有具有訪問權限的用戶可以對資源進行訪問。這種數據保護能力極大的提高了 Content Manager 解決方案的數據安全性。
Multi-tenancy
Multi-tenancy 是一種軟件體系結構，在這種體系結構中軟件運行在 software as a service 服務商的服務器上，服務於多個客戶組織即 tenant。Multi-tenancy 使每個客戶組織都工作在一個為其定制好的虛擬軟件或者解決方案實例中，並認為自己在獨享環境。Multi-tenancy 與多軟件實例體系結構不同，多軟件實例結構擁有多個軟件實例並且每個實例服務於一個客戶組織，而 Multi-tenancy 結構是由一個軟件實例為所有的客戶組織提供服務。多軟件實例結構物理上隔離客戶組織的數據，而 Multi-tenancy 環境中的軟件或者解決方案邏輯上隔離客戶組織的數據和配置。
IBM DB2 Content Manager 憑借其極好的內容管理和流程管理的特性，被廣泛的采用於企業解決方案中。Multi-tenancy 由於可以為企業節省資源，越來越受到企業解決方案的使用者和提供者的青睐。Multi-tenancy 環境中，客戶組織（tenant）的數據不允許被共享，所以如何保護支持 Multi-tenancy 的 IBM DB2 Content Manager 解決方案中每個 tenant 的數據使其不能被其他 tenant 所訪問，是至關重要的。
簡介
IBM DB2 Content Manager
IBM DB2 Content Manager 提供了一個完整的解決方案來存儲和檢索任何格式的文檔，用戶可以根據自身的商業需要使用它來管理非結構化的文檔，Content Manager 還提供了強大的數據管理能力和靈活的文檔路由功能。除此之外，Content Manager 具有完善的數據保護能力，Content Manager 通過訪問控制列表可以對資源進行訪問控制以保證只有具有訪問權限的用戶可以對資源進行訪問。這種數據保護能力極大的提高了 Content Manager 解決方案的數據安全性。
Multi-tenancy
Multi-tenancy 是一種軟件體系結構，在這種體系結構中軟件運行在 software as a service 服務商的服務器上，服務於多個客戶組織即 tenant。Multi-tenancy 使每個客戶組織都工作在一個為其定制好的虛擬軟件或者解決方案實例中，並認為自己在獨享環境。Multi-tenancy 與多軟件實例體系結構不同，多軟件實例結構擁有多個軟件實例並且每個實例服務於一個客戶組織，而 Multi-tenancy 結構是由一個軟件實例為所有的客戶組織提供服務。多軟件實例結構物理上隔離客戶組織的數據，而 Multi-tenancy 環境中的軟件或者解決方案邏輯上隔離客戶組織的數據和配置。
權限集
權限（privilege）是指某個特定的用戶對特定的資源的訪問權力，它決定著哪些用戶可以訪問系統中哪些資源，但是這些用戶和資源分別是什麼並不是由權限決定的。也就是說，權限是抽象的規則集合，只有為它指定了用戶和資源的時候它才會變得具體起來，才能發揮作用。Content Manager 定義了許多權限來供用戶選擇和使用，例如添加和刪除文檔的權限，訪問工作列表的權限等等。
權限集（privilege set），顧名思義是權限的集合，可以包含多個 Content Manager 權限。在商業解決方案中，用戶很少只使用到一個權限或者很少只被一個權限所約束，絕大多數的用戶都需要多個權限聯合發揮作用來達到解決方案的要求。將用戶所需要的權限放在一個權限集中，然後統一的賦予用戶會提高權限賦予的效率並簡化用戶權限管理的復雜性。Content Manager 管理客戶端提供了良好的操作界面來幫助用戶將權限添加到權限集中，如圖 1 所示。
圖 1. 在 Content Manager 管理客戶端中建立權限集
用戶和用戶組
用戶和用戶組（user group）是 Content Manager 用來管理解決方案的用戶組織結構的模型。Content Manager 用戶可以直接對應到解決方案的用戶，所以 Content Manager 對用戶的權限控制可以直接的反應到解決方案中。
Content Manager 提供了兩種建立用戶的途徑，一種是直接在 Content Manager 中建立，另一種是將建立在 LDAP 中的用戶導入到 Content Manager 中。對於這兩種方式建立的用戶，權限控制是沒有區別的。圖 2 展示了在 Content Manager 管理客戶端中建立用戶的圖形化界面。
圖 2. 在 Content Manager 管理客戶端中建立用戶
查看原圖（大圖）
每個用戶都擁有一個最大權限集（maximum privilege set），最大權限集規定了用戶最大程度上可以擁有的權限，用戶無法獲得超出這個最大權限集以外的任何權限。建立用戶時候，需要為每個用戶指定一個資源管理器和默認的訪問控制列表。當用戶在 Content Manager 中存儲和檢索任何對象的時候，Content Manager 將會用這個指定的資源管理器進行存儲和檢索。訪問控制列表將在後續章節中進行介紹。
用戶組是用戶的集合，是對具有相同特征的用戶進行的分組。權限控制是可以以用戶組為單位的，如果在 Content Manager 中為一個用戶組設定了權限，那麼用戶組中的所有用戶會擁有和用戶組相同的權限。用戶建立的時候可以為其指定所在的用戶組，也可以在 Content Manager 管理客戶端將用戶指派到其他的用戶組中，如圖 3 所示。
圖 3. 在 Content Manager 管理客戶端中添加用戶到用戶組
查看原圖（大圖）
訪問控制列表
訪問控制列表（Access Control List，ACL）是 Content Manager 的權限控制中最為關鍵的特性。訪問控制列表由用戶或者用戶組和權限集的對應關系組成，也就是說訪問控制列表決定了特定的用戶可以對哪些資源進行特定的權限控制，但是並不能決定是哪些資源。這是因為訪問控制列表將用戶和權限集進行了關聯，但是並沒有和需要進行訪問控制的 Content Manager 資源進行關聯。
圖 4. 訪問控制列表中用戶和權限集的對應關系
查看原圖（大圖）
如圖 4，訪問控制列表中包含了多個用戶或者用戶組和權限集的對應關系。對於其中的任意一個對應關系，用戶或者用戶組決定了哪些用戶將受到控制，而與其對應的權限集則決定了這些用戶將受到什麼樣的權限控制。當訪問控制列表與 Content Manager 資源關聯時，用戶或者用戶組決定了哪些用戶可以訪問這些資源。權限集則決定了這些用戶可以對資源進行哪些訪問，也就是決定了對資源的訪問程度，例如完全不能訪問，只讀或者修改。一個訪問控制列表可以包含多個用戶或者用戶組和權限集的對應關系，所以不同的用戶對於資源的不同程度的訪問可以定義在一個訪問控制列表中。
Content Manager 的數據隔離
IBM DB2 Content Manager 提供了許多數據模型來滿足解決方案的建模需求，這些模型分別是 itemtype，工作節點和流程，工作列表。Content Manager 解決方案憑借這些模型建立自身的數據模型，這些模型是解決方案需要進行訪問控制的資源，在對 Content Manager 解決方案進行數據隔離時必須隔離解決方案的數據模型。對解決方案進行數據隔離後，Multi-tenancy 環境中 tenant 只能訪問屬於自己的數據模型而不能訪問其他 tenant 的數據模型。
訪問控制列表已經定義了特定的用戶可以對哪些資源進行特定的訪問。當將訪問控制列表綁定到資源時，哪些用戶可以對哪些資源進行哪種程度的訪問就被完全的確定了，也就是說對資源的訪問控制的定義完全完成了。
Itemtype 隔離
商業中存在著多樣化的數據，所以商業解決方案需要具有描述不同的數據的能力，解決方案需要將這些不同種類的數據進行抽象，然後用數據模型描述它們。 Content Manager 的 Itemtype 就是解決方案用來描述這些不同種類的數據的模型。Itemtype 可以描述商業中的一類數據，用多個 itemtype 就可以完成對商業中多個種類的數據的描述。
Itemtype 是一種數據模型，是數據的模板而不是真實的數據。Itemtype 與 Content Manager 文檔是文檔模板與具體文檔的關系，文檔必定從屬於文檔模板，也就是說 Content Manager 文檔必定從屬於某個 itemtype。Itemtype 包含許多 Content Manager 屬性（attribute），屬性描述著 itemtype 中的每項信息，例如 itemtype 對應著一類票據，itemtype 的屬性則可以對應這類票據的產生日期和所有者等信息。在 Content Manager 中，屬性可以被不同的 itemtype 共享，也就是說一個屬性可以被包含在多個 itemtype 中。所以 Content Manager 沒有提供對屬性進行訪問控制的能力，而只可以對 itemtype 進行訪問控制。由於數據模型是以 itemtype，而不是以屬性為單位，所以對 itemtype 進行訪問控制已經完全可以滿足解決方案數據隔離的要求，而不需要再對屬性進行任何形式的訪問控制。
圖 5. 在 Content Manager 管理客戶端中為 itemtype 指定訪問控制列表
查看原圖（大圖）
Content Manger 管理客戶端提供了圖形化的接口來指定訪問控制列表到 itemtype，如圖 4 所示。為 itemtype 指定訪問控制列表後，當用戶要求訪問 Content Manager 中文檔時 Content Manager 會首先檢查用戶是否有權限訪問所要求的文檔。Content Manager 的這種檢查分為兩個級別，一個級別是在 itemtype 級別進行權限的檢查，另一種是在文檔級別進行權限的檢查。也就是說，解決方案可以選擇在 itemtype 的級別還是在 itemtype 的文檔的級別對文檔進行訪問控制。Itemtype 級別的權限控制應用訪問控制列表到 itemtype 的級別，這種情況下訪問控制列表中的用戶可以訪問這個 itemtype 的任何文檔。文檔級別的權限控制應用訪問控制列表到每個獨立的文檔。在建立 Content Manager 用戶的時候，需要為用戶選擇一個默認的訪問控制列表，這個默認訪問控制列表可以在 itemtype 的權限控制中得到使用。在管理客戶端中選定進行文檔級別的權限控制後，解決方案可以選擇使用這個默認的訪問控制列表還是為 itemtype 指定的訪問控制列表。Content Manger 在檢查用戶對文檔的訪問權限後，會批准或者拒絕用戶對資源的訪問請求。如果請求被拒絕，用戶將沒有權利對資源進行相關權限的訪問。
Content Manager 擁有四種類型的 itemtype，分別是 item，resource item，document 和 document part。對於 document 類型的 itemtype，可以為 itemtype 添加 document part，document part 也需要進行權限控制。如圖 5，在將 document part 關聯到 itemtype 的時候，為 document part 指定訪問控制列表。
圖 6. 為 itemtype 的 document part 指定訪問控制列表
查看原圖（大圖）
工作節點和流程隔離
商業解決方案中存在著大量的流程，每個流程都反映出真實的商業過程。在 Multi-tenancy 解決方案中，每個 tenant 擁有的流程都不同並且作為保密數據不可以被其他 tenant 訪問。這就要求將解決方案中不同 tenant 的工作流程和組成流程的工作節點進行隔離。
工作流程是由一些工作節點和連接工作節點的路徑組成的，Content Manager 不需要對路徑進行權限控制，對流程的訪問控制主要體現在對流程本身和流程工作節點的訪問控制上。對工作流程沒有訪問權限的用戶將完全看不到工作流程。而對工作流程有訪問權限但是對其中的一些工作節點沒有訪問權限的用戶，可以在流程上進行操作但是沒有權力在沒有訪問權限的工作節點上進行操作。例如用戶可以在一個工作流程上路由一個 Content Manager 文檔，但是當文檔被路由到用戶沒有訪問權限的工作節點的時候，用戶將失去對文檔的控制權。
圖 7. 在 Content Manager 管理客戶端中為工作節點指定訪問控制列表
查看原圖（大圖）
如圖 6，在指定訪問控制列表到工作節點的圖形化界面上，只需選擇一個訪問控制列表就可以完成對這個工作節點的權限控制。在對工作流程進行訪問控制列表的指定時，需要打開工作流程並在流程特性中進行訪問控制列表的指定，如圖 7 所示。
圖 8. 在 Content Manager 管理客戶端中為工作流程指定訪問控制列表
查看原圖（大圖）
工作列表隔離
工作列表（worklist）是一些工作節點上所有 Content Manager 文檔的集合，它列出了等待用戶處理的文檔，是 Content Manager 與用戶的交互接口。在 Content Manager 中，文檔只能停留在工作節點而不能停留在工作節點之間的路徑上。所以如果一個文檔在流程中被路由，它注定停留在流程的某個工作節點上，進而可以被工作列表展現出來供用戶處理。Content Manager 工作列表和工作節點之間是一種可配置的涵蓋關系，當配置一些工作節點到一個工作列表中以後，這個工作列表就會包含它所涵蓋的工作節點上的所有 Content Manager 文檔。
在 Multi-tenancy 解決方案中，隔離每個 tenant 的工作列表是必須的，隔離的方式是使用訪問控制列表對工作列表的訪問權限加以控制。將訪問控制列表指定到工作列表後，指定的訪問控制列表可以限制訪問工作列表的用戶和用戶對於工作列表的訪問程度。擁有訪問權限，用戶才可以訪問工作列表並進行被批准的操作。Content Manager 管理客戶端提供了為工作列表指定訪問控制列表的圖形化界面，如圖 8 所示。
圖 9. 在 Content Manager 管理客戶端中為工作列表指定訪問控制列表
查看原圖（大圖）
隔離 Content Manager 中的文檔
前面已經描述了如何對 Content Manager 中的數據模型進行隔離。但是這不足以滿足所有解決方案的需要，一些解決方案在憑借訪問控制列表對數據模型進行隔離之後，還要求使用 Content Manager 資源管理器（resource manager）對 Content Manager 的文檔進行進一步的隔離。
這種隔離的核心思想是為 Multi-tenancy 解決方案中的每個 tenant 都建立一個 Content Manager 資源管理器，當一個 tenant 的用戶在存儲或者檢索文檔的時候，會使用屬於自己的 tenant 的資源管理器。在 Content Manager 中建立用戶時，為用戶指定了一個資源管理器，用戶會用這個資源管理器來存取和檢索 Content Manager 中的文檔。通常屬於同樣 tenant 的用戶具有同樣的資源管理器。
Content Manager 四種類型的 itemtype 中，document 類型的 itemtype 要求指定保存與其相關的 document part 的資源管理器，如圖 9，這些 document part 將會保存在這個指定的資源管理器中。
圖 10. 為 document 類型 itemtype 的 document part 指定資源管理器
查看原圖（大圖）
Resource item 類型的 itemtype 要求指定保存 resource item 的資源管理器，如圖 10，resource item 將會保存在這個指定的資源管理器中。
圖 11. 為 resource item 類型的 itemtype 指定資源管理器
查看原圖（大圖）
結束語
本文描述了使用 Content Manager 的訪問控制列表對 itemtype 和流程等 Content Manager 資源進行訪問控制的方法。受到訪問控制列表控制的資源將具備一定的訪問要求，只有滿足這些訪問要求的 Content Manager 用戶才能成功的訪問這些受控資源。這是對支持 Multi-tenancy 的 IBM DB2 Content Manager 解決方案進行數據隔離的原理。
