【正文】 否則一旦系統(tǒng)數(shù)據(jù)出現(xiàn)混亂、錯(cuò)誤等異常情況時(shí)就會(huì)措手無策，無法。 本模塊就是要通過一系列的算法來計(jì)算所需的權(quán)限數(shù)據(jù)，具體算法有：用數(shù)據(jù)庫實(shí)現(xiàn)的樹型結(jié)構(gòu)的遍歷、查找（內(nèi)部節(jié)點(diǎn)、子節(jié)點(diǎn)、指定節(jié)點(diǎn)）算 法，計(jì)算角色所擁有的全部功能及功能的作用范圍、作用時(shí)間的算法，計(jì)算單個(gè)用戶所擁有的全部功能及功能的作用范圍、作用時(shí)間的算法，判斷角色（或用戶）是否擁有某個(gè)功能及作用范圍、作用時(shí)間的算法等等。 . 公 用的權(quán)限數(shù)據(jù) 如系統(tǒng)公用的部門信息，職位、職級(jí)信息，其他用戶分組信息等等，這些數(shù)據(jù)都是業(yè)務(wù)系統(tǒng)經(jīng)常會(huì)用到的。 基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 5 章 核心模塊的設(shè)計(jì) 第 28 頁 共 80 頁 圖 ：角色 管理 用例圖 . 角色與用戶關(guān)聯(lián) 功能 圖 ： 角色與用戶關(guān)聯(lián) 用例圖 . 角色與操作關(guān)聯(lián) 增加角色修改角色刪除角色管理員管理角色動(dòng)態(tài)屬性增加用戶到角色管理員從角色中刪除用戶基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 5 章 核心模塊的設(shè)計(jì) 第 29 頁 共 80 頁 圖 ： 角色與操作關(guān)聯(lián)用例圖 . 計(jì)算權(quán)限數(shù)據(jù)模塊 前面 幾個(gè) 模塊主要是按照權(quán)限抽象模型將數(shù)據(jù)組織在一起，但這些數(shù)據(jù)如何能表示具體的權(quán)限，如何讓業(yè)務(wù)系統(tǒng)來使用這些，則是本模塊要解決的事情。例如：OA系統(tǒng)有公告模塊， 如 圖 ： 圖 ：采用樹型結(jié)構(gòu)登記功能 . 權(quán)限管理模塊 . 角色管理 業(yè)務(wù)系統(tǒng)模塊 業(yè)務(wù)系統(tǒng)功能 功能羅列 唯一的 ID 號(hào)“編程代碼” 登記業(yè)務(wù)系統(tǒng)中的模塊。這樣也達(dá)到了統(tǒng)一管理系統(tǒng)中所有的功能操作的目的。 所有業(yè)務(wù)系統(tǒng)的功能操作都必須在統(tǒng)一權(quán)限系統(tǒng)中注冊(cè)，并獲得唯一的 ID，分配權(quán)限時(shí)這些操作 ID 與角色 ID、時(shí)間組成權(quán)限數(shù)據(jù)，與某個(gè)用戶相關(guān)的所基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 5 章 核心模塊的設(shè)計(jì) 第 27 頁 共 80 頁 有權(quán)限數(shù)據(jù)就是該用戶擁有的訪問令牌，用于在各業(yè)務(wù)系統(tǒng)中判斷用戶是否可以執(zhí)行某個(gè)操作。 圖 ： 用戶 帳號(hào) 列表 圖 ：管理用戶帳號(hào) . 業(yè)務(wù)系統(tǒng)功能操作登記模塊 對(duì)于不同架構(gòu)、不同平臺(tái)上的系統(tǒng)（特別是已經(jīng)存在的系統(tǒng)），如何讓它們也融入到全新的權(quán)限系統(tǒng)中來呢？為此增加了“業(yè)務(wù)系統(tǒng)功能操作 登記模塊”。 如果 操作 作用域的時(shí)間期限小于角色擁有 操作 的時(shí)間期限，那實(shí)際作用時(shí)間應(yīng)等于 操作 作用域的時(shí) 間期限。因?yàn)槿绻巧€沒有開始或已經(jīng)不再擁有 操作 了，那對(duì)應(yīng)的 操作 作用的范圍也就失去了意義。 ? 整合了過去分散在各應(yīng)用系統(tǒng)中雖然有內(nèi)在關(guān)聯(lián)卻難以判別的用戶信息 資源，為更進(jìn)一步的用戶個(gè)性化服務(wù)打下了基礎(chǔ)。 ? 各系統(tǒng)之間耦合度低，應(yīng)用系統(tǒng)的改造不破壞其固有流程和結(jié)構(gòu)，整個(gè)系統(tǒng)的實(shí)施過程安全平滑。當(dāng)用戶訪問業(yè)務(wù)系統(tǒng)時(shí)，業(yè)務(wù)系統(tǒng)首先判斷用戶的瘦令牌中是否有相關(guān)的權(quán)限數(shù)據(jù)，如果沒有，則訪問統(tǒng)一權(quán)限系統(tǒng)獲取權(quán)限數(shù)據(jù)；如果有，則直接取出，然后 驗(yàn)證權(quán)限數(shù)據(jù)來決定是否執(zhí)行操作。 用來表示“用戶在什么時(shí)間什么范圍內(nèi)能做什么操作”。 ? 實(shí)際作用時(shí)間：是指操作實(shí)際起作用的時(shí)間。即“對(duì)哪些對(duì)象做事情”，如增加哪個(gè)部門的公告，或修改哪個(gè)部門的公告。 ? 操作（ Operator）：是具體的業(yè)務(wù)動(dòng)作，即“做什么事情”，如增加公告，修改公告，刪除公告等等。 基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 4 章 統(tǒng)一權(quán)限系統(tǒng)的設(shè)計(jì) 第 22 頁 共 80 頁 ? 用戶代表角色（ UserRole）：是角色的一種特例，只用來代表用戶自身。角色與角色之間有層級(jí)關(guān)系。采用統(tǒng)一權(quán)限系統(tǒng)后，每個(gè)用戶的身份是唯一的，并和已存在的業(yè)務(wù)系統(tǒng)中帳號(hào)做映射 。 ? 用戶（ User）：系統(tǒng)中的行為者。能力表是面向主體的，用以說明主體能對(duì)那個(gè)訪問對(duì)象執(zhí)行何種操作。本系統(tǒng)為考慮運(yùn)行速度根據(jù) 系統(tǒng)中角色、權(quán)限配置、用戶委派等關(guān)系動(dòng)態(tài)地的組成一張用戶能力表保存在系統(tǒng)中根據(jù)上述配置信息改變由系統(tǒng)動(dòng)態(tài)生成和保存。系統(tǒng)的訪問控制分為模塊級(jí)控制和界面元素級(jí)控制 [10]。訪問控制就是要處理怎樣表達(dá)和核對(duì)訪問規(guī)則的問題。 . 訪問控制機(jī)構(gòu) 杜絕對(duì)系統(tǒng)非法訪問主要方法是訪問控制?？诹钍亲畛Ｓ玫囊环N標(biāo)識(shí)，通常由若干字母、數(shù)字組合而成。 用戶鑒別機(jī)構(gòu)保存的一張登記有每個(gè)用戶名稱、標(biāo)識(shí)和有關(guān)情況的表，表中的用戶名通常是公開的，標(biāo)識(shí)則是保密的，當(dāng)用戶要訪問系統(tǒng)時(shí)，須首先把自已的名稱和標(biāo)識(shí)登記到系統(tǒng)中（即出示證件）。這是當(dāng)前較為常用的方法。第二、利用用戶特有的證件，如身份證、機(jī)器可讀卡先考片，其缺點(diǎn)是證件可能被別結(jié)束開始選擇一個(gè)角色 選擇一個(gè)操作選擇一組操作 選擇一組角色將角色和操作關(guān)聯(lián)起來選擇一個(gè)或一組角色操作對(duì)將角色操作對(duì)邏輯刪除重新計(jì)算受影響的權(quán)限數(shù)據(jù)基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 4 章 統(tǒng)一權(quán)限系統(tǒng)的設(shè)計(jì) 第 21 頁 共 80 頁 人復(fù)制 或冒用。目前有三種方法可用：第一、利用用戶的物理特征（聲波、指紋、相貌、簽名）。權(quán)限配置流程 如圖 所示 ： 圖 ：權(quán)限配置活動(dòng)圖 . 權(quán)限一覽 在授權(quán)完成后可檢查 登陸 用戶所的擁有的能力表信息，審查給用戶的權(quán)限是 否 合適，如不合適可重新進(jìn)行用戶委派和收回部分權(quán)限的處理。角色定義流程 如 圖 如 示 ： 圖 ：角色定義活動(dòng)圖 基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 4 章 統(tǒng)一權(quán)限系統(tǒng)的設(shè)計(jì) 第 20 頁 共 80 頁 . 權(quán)限配置 角色是一組訪問權(quán)限的集合，一個(gè)用戶可以是很多角色的成員，一個(gè)角色也可以有很多個(gè)權(quán)限，而一個(gè)權(quán)限也可以重復(fù)配置于多個(gè)角色。角色繼承關(guān)系提供了對(duì)已有角色的擴(kuò)充和分類的手段，使定義新的角色可以在已有角色的基礎(chǔ)上進(jìn)行，擴(kuò)充就是通過增加父角色的權(quán)限去定義子角色，分類通過不同子角色繼承同一父角色來體現(xiàn)。角色之間有相應(yīng)繼承的關(guān)系，當(dāng)一個(gè)角色 r1 繼承另一個(gè)角色 r2 時(shí)， r1就自動(dòng)擁有了 r2 的訪問權(quán)限 (表示 r1r2) [7]。這樣，用戶與角色之間以及角色與權(quán)限之間就形成了兩個(gè)多對(duì)多的關(guān)系。這個(gè)頁面實(shí)際運(yùn)行在權(quán)限模塊的服務(wù)器上，頁面接受參數(shù)以 獲知設(shè)置代理用戶的信息，以及提供正確的可分配的代理用戶信息 [6]。角色代理 ： 提供將自己的角色權(quán)限的全部或者部分提供給同角色組中其它人的功能 ,代理是有時(shí)間限制的。角色有上下級(jí)關(guān)系，以及角色向下級(jí)權(quán)限分配代理權(quán)限的功能。 用戶 和 角色之間的關(guān)系 是多對(duì)多的：一個(gè)用戶可以對(duì)應(yīng) 多個(gè)角色， 一個(gè)角色也可以對(duì)應(yīng) 多個(gè)用戶， 利用對(duì)照表的形式提供這種對(duì)應(yīng)關(guān)系。 角色中有一個(gè)特殊的角色 ，即 用戶代表角色：是角色的一種特例，只用來代表用戶自身。 角色 是對(duì)用戶進(jìn)行的分組，角色和用戶之間是多對(duì)多的關(guān)系。模塊帶有的管理界面負(fù)責(zé)管理全部系統(tǒng)的用戶信息操作。在系統(tǒng)中定義可 登陸 的用戶操作系統(tǒng)是系統(tǒng)安全管理所必須步驟，也是人與系統(tǒng)的接口。同時(shí)這種方式也 將 統(tǒng)一權(quán)限系統(tǒng)中注冊(cè)的 業(yè)務(wù)系統(tǒng) 的 操作從語義中分離出來， 因?yàn)樽?cè)的操作具體對(duì)應(yīng)的功能是由操作的文 字來表示的，與基本權(quán)限做了關(guān)聯(lián)之后，不再使用 OprationID 去判斷權(quán)限，所以也就與OprationID 的文字沒有關(guān)系了。在增加業(yè)務(wù)系統(tǒng)模塊時(shí)，自動(dòng)為模塊增加基本權(quán)限對(duì)應(yīng)的操作。 業(yè)務(wù)系統(tǒng)模塊的基本操作，如瀏覽、增加、刪除、修改等還必須在統(tǒng)一權(quán)限系統(tǒng)中注冊(cè) ，因?yàn)樵诮y(tǒng)一權(quán)限系統(tǒng)中，操作是分配權(quán)限的最小單位，每個(gè)操作必須有一個(gè)唯一的 ID。 比如業(yè)務(wù)系統(tǒng) 公告模塊（ ModuleId=10001）的 “增加公告”操作與基本權(quán)限中的“增加” (BaseRightCode=A)做了對(duì)應(yīng)， 則 業(yè)務(wù)系統(tǒng)編程人員可以按如下方式判斷用戶（ UserID=255）是否擁有公告模塊增加的權(quán)限： Boolean isCan=isUserCanOperate(255,10001 ,A)。 每個(gè)基本權(quán)限都有一個(gè)“基本權(quán)限代碼” , 本文稱之為 BaseRightCode，用來讓業(yè)務(wù)系統(tǒng)編程人員更好的識(shí)別和使用該權(quán)限，比如“增加”的基本權(quán)限代碼是“ A” ,“刪除”的基本權(quán)限代碼是“ D”等等。 為 解決這個(gè)問題，使權(quán)限的 維護(hù) 和使用更加 方便， 統(tǒng)一 權(quán)限系統(tǒng)中保留 了一些 基本權(quán)限 ，如瀏覽，增加，刪除，修改 、授權(quán)、統(tǒng)計(jì) 等。因?yàn)闃I(yè)務(wù)系統(tǒng)中每個(gè)模塊都會(huì)有瀏覽、增加、刪除、修改等基本操作，如果業(yè)務(wù)系統(tǒng)采用OprationID 來判斷權(quán)限，那每個(gè)模塊都需要記住大量的操作 ID，這對(duì)于業(yè)務(wù)系統(tǒng)來說是不方便的。統(tǒng)一權(quán)限系統(tǒng)客戶端 jar 包的具體運(yùn)行細(xì)節(jié)將在后文討論。 操作序號(hào) 是八位數(shù)字，由五位模塊流水號(hào)和三位流水號(hào)組成，如下： OprationID=ModuleID+三位流水號(hào)，如 10001001， 11056009 等。操作是 屬于某個(gè)模塊 的，操作 是最終節(jié)點(diǎn) （即樹的葉子節(jié)點(diǎn)） 。 模塊序號(hào)是五位數(shù)字，由兩位業(yè)務(wù)系統(tǒng)序號(hào)和三位模塊流水號(hào)組成，如下： ModuleID=SystemID+三位流水號(hào)，如 10001， 11056 等。 ? 模塊 業(yè)務(wù)系統(tǒng)中的所有 模塊都要在統(tǒng)一權(quán)限系統(tǒng)中對(duì)應(yīng)的系統(tǒng)下注冊(cè)，并獲得基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 4 章 統(tǒng)一權(quán)限系統(tǒng)的設(shè)計(jì) 第 16 頁 共 80 頁 唯一的模塊序號(hào)，本文稱之為 ModuleID。 SystemID 是兩位數(shù)字，其可取值范圍規(guī)定為 10－ 99。 對(duì)最終用戶 而言，統(tǒng)一權(quán)限系統(tǒng)和業(yè)務(wù)系統(tǒng)是一個(gè)整體 ， 不僅如此， 對(duì)業(yè)務(wù)系統(tǒng)程序開發(fā)員而言， 統(tǒng)一權(quán)限也是透明的，他們只需要在自己的程序中調(diào)用統(tǒng)一權(quán)限系統(tǒng)客戶端接口即可，并不需要知道統(tǒng)一權(quán)限系統(tǒng)是如何實(shí)現(xiàn)的。 . 統(tǒng)一權(quán)限系統(tǒng)與業(yè)務(wù)系統(tǒng)的關(guān)系 統(tǒng)一權(quán)限系統(tǒng)和業(yè)務(wù)系統(tǒng)之間是依賴和被依賴的關(guān)系。建立角色、功能、范圍、時(shí)間四個(gè)維度的抽象模型，統(tǒng)一管理所有的 用戶、所有的模塊和功能、所有的權(quán)限信息等。 所以本文的創(chuàng)新點(diǎn)在于提出并實(shí)現(xiàn)了一個(gè)新的權(quán)限管理框架 —— “ 統(tǒng)一權(quán)限系統(tǒng) ”。 所以統(tǒng)一 權(quán)限系統(tǒng)要解決的問題和 Portal 系統(tǒng)也是不一樣的。雖然“ 統(tǒng)一權(quán)限系統(tǒng) ”也提供將已存在 業(yè)務(wù) 系統(tǒng)的權(quán)限管理加入到統(tǒng)一權(quán)限系統(tǒng)中的方式 和接口 ，但要求對(duì)已有 業(yè)務(wù) 系統(tǒng)的權(quán)限管理模塊做 部分的改動(dòng)， 而且改動(dòng)的規(guī)模大小要視子系統(tǒng)的具體情況而定，對(duì)“統(tǒng)一權(quán)限系統(tǒng)”來說這是一個(gè)未知的因素， 所以這并不是“統(tǒng)一權(quán)限系統(tǒng)” 要解決的主要問題，本文也不推薦這樣做，只是在已存在業(yè)務(wù)系統(tǒng)必須加入到“統(tǒng)一權(quán)限系統(tǒng)”中，是非改不可的，并且對(duì)所進(jìn)行的修改在技術(shù)上是可行的情況下才這樣做。 而 本文所提出的“ 統(tǒng)一權(quán)限系統(tǒng) ” 主要的應(yīng)用 時(shí)期 是 在 系統(tǒng)建立之初， 主要的作用是將 它作為一個(gè)基礎(chǔ) 的權(quán)限管理 框架，其他業(yè)務(wù)系統(tǒng) 的權(quán)限控制 是在這個(gè)基礎(chǔ)之上建立而成，所以業(yè)務(wù)系統(tǒng)對(duì)統(tǒng)一權(quán)限系統(tǒng)是依賴關(guān)系，離開了統(tǒng)一權(quán)限系統(tǒng)，業(yè)務(wù)系統(tǒng)就無法正常使用。 通常其有如下三個(gè)特點(diǎn) : ? Personalization (個(gè)性化 ) ? Single sign on (單點(diǎn)登陸 ) ? Content aggregation (內(nèi)容聚合 ) 其中 Content aggregation 指的是將不同來源的信息整合到一個(gè)頁面中 ，讓用戶更方 便的 使用 . 比如 , 如果某客戶需要進(jìn)行一次商業(yè)采購 ,以往需要訪問不同 供應(yīng)商的主頁得到相關(guān)信息 , 但如果使用 Portal 將所有不同的貨物供應(yīng)商的商品 目錄 頁面都整合到一個(gè) Portal 頁面中 , 那么 對(duì) 所有的商品信息 就 可以更快的瀏覽 、 篩選和定貨 , 加 快了客戶的商業(yè)運(yùn)作效率 。 所以統(tǒng)一權(quán)限系統(tǒng)和單點(diǎn) 登陸 系統(tǒng)是不一樣的。 而 本文所提出的“ 統(tǒng)一權(quán)限系統(tǒng) ” 并不只是單點(diǎn) 登陸 。主要 解 決 在 多個(gè)系統(tǒng)之間 訪問時(shí) 不需要多次 登陸 的問題。因此 采用的方式是 通過在客戶端瀏覽器、單點(diǎn) 登陸 系統(tǒng)和應(yīng)用系統(tǒng)之間傳遞臨時(shí)會(huì)話，并讓應(yīng)用系統(tǒng)直接到單點(diǎn) 登陸 系統(tǒng)中獲取認(rèn)證信息來實(shí)現(xiàn)單點(diǎn) 登陸 ，或使用數(shù)字證書來實(shí)現(xiàn)單點(diǎn)登錄 [3]。 ? 開發(fā) 單點(diǎn) 登陸 系統(tǒng)的難度 不能太大 。要將已有的用戶庫進(jìn)行統(tǒng)一是不現(xiàn)實(shí)的。 單點(diǎn) 登陸 系統(tǒng) 的應(yīng)用 前題條件 是： ? 已經(jīng)存在多個(gè)系統(tǒng)； ? 用戶從一個(gè)系統(tǒng)訪問到另外一個(gè)系統(tǒng)時(shí)需要 登陸 后 才能訪問資源。各應(yīng)用系統(tǒng)由于功能側(cè)重、設(shè)計(jì)方法和開發(fā)技術(shù)有所不同，也就形成了各自獨(dú)立 的用戶庫和用戶認(rèn)證體系。下面將做出討論。 基于以上的分析，用 Web Services 來實(shí)現(xiàn)權(quán)限的統(tǒng)一管理是完全可行，而且是非常有必要的 [2]。 基于 Web Services 的統(tǒng)一權(quán)限系統(tǒng) 第 3 章 新的解決方案分析 第 12 頁 共 80 頁 Web Services 的最大的優(yōu)點(diǎn)就是 整合異構(gòu)系統(tǒng)間的數(shù)據(jù) 。 對(duì)客戶端調(diào)用來說，不僅數(shù)據(jù)庫的結(jié)構(gòu)是透明的，而且可以通過調(diào)用接口來實(shí)現(xiàn)調(diào)用權(quán)限的限制。 即使 接口名字 改變 了，也可通過方法重構(gòu)的方式修改接口包 ，業(yè)務(wù)系統(tǒng) 中 只需要重新引入新的包即可完成更新。 這些 Web Services 客戶端接口以包的形式引入到業(yè)務(wù)系統(tǒng)中使用。 統(tǒng)一 權(quán)限系統(tǒng)