1. 選題的依據與意義

​隨著歷史的發展，網路已經進入到千家萬戶，並且給人們的生活，工作業米極大的樂趣和效率。在大部分的國內外公司企業和國外的政府部均通過網路建立起了自己的辦公自動化系統，併發揮了重要的作用。1作為中國的領分階層，要允份貫徹黨中火與時俱進的思想，把辦公自動化系統引入到政府部門的日常工作中。為了保證辦公自動化的安全穩定的執行，使工作人員根據自己的職能和許可權僅能進行與自己工作有關的操作，就要在辦公自動化系統中根據每個人的職能為其分配相應的許可權。即許可權管理系統。
系統採用了Spring架構，Tomcat7.0作為執行伺服器，基於J2EE標準開發工具利月Javaweb中的Bootstrap技術，IDEA開發環境，資料庫採用Oracle。訪問使用者的許可權檢測可以通過客戶端實現或通過客戶端+伺服器檢測實現，而B/S中，瀏覽器是每一臺計算機都已具備的，如果不建立一個完整的許可權檢測，那麼個“非法使用者”很可能就能通過瀏覽器輕易訪問到B/S系統中的所有功能。因此B/S業務系統都需要有一個或多個許可權系統來實現訪問許可權檢測，讓經過授權的使用者可以正常合法的使用已授權功能，而對那些未經授權的“非法使用者”將會將他們徹底的“拒之門外”。

2. 需求分析

1)不同職責的人員，對於系統操作的許可權應該是不同的。優秀的業務系統，這是最基本的功能。

2)可以對“組”進行許可權分配。對於一個大企業的業務系統來說，如果要求管理員為其下員工逐“分配系統操作許可權的話。是件託時日不夠方便的事情。所以，系統中就提出了對“組”進行操作的概念，將許可權致的人員編入同組，然後對該組進行許可權分配。

3)許可權管理系統應該是可打展的。它應該可以加入到任何帶有許可權管理功能的系統中。就像是元件一樣的可以被不斷的重用，而不是每開發一套管理系統，就要針對許可權管理部分進行重新開發。

4)滿足業務系統中的功能許可權。傳統業務系統中，存在著兩種許可權管理.其一是功能許可權的管理，而另外種則是資源許可權的管理，在不同系統之間，功能許可權是可以重用的，而資源許可權則不能。

2.1功能需求

2.1.1使用者認證

在使用者認證，簡單的講，可以簡化為應用對使用者登入狀態的認證。傳統的單體應用，使用session來進行使用者認證，但是這種方式已經不適合微服務的場景了；微服務的結構下，可以通過分散式session來解決，也可以通過和Spring Cloud Security結合很好的OAuth2來解決。

a.使用者登入，驗證成功
b.伺服器給使用者客戶端分發令牌token，並將token以及其他資訊儲存到認證服務或者公共快取中
C.客戶端請求時帶伺服器分發的token，請求服務
d. 服務拿到使用者token，並通過認證服務或者公共快取中儲存的token來校驗使用者token
e. token校驗成功，執行服務邏輯，返回結果

2.1.2服務許可權認證

微服務的一大核心是將服務進行拆分，降低服務的複雜度，拆分後，就會有服務之間的呼叫關係，服務之間的許可權控制也是必要的。一般只需要維繫微服務之間的呼叫關係，微服務呼叫時，呼叫髮帶著自己的服務標識，被呼叫發校驗呼叫方的
許可權。

2.1.3使用者許可權認證

使用者許可權一般分為功能許可權和資料許可權。

2.2效能需求

2.2.1使用者許可權需求

1.功能許可權：

使用者功能許可權一般採用經典的RBAC（Role Based Access Control）方式進行控制，RBAC的核心就是通過角色來控制使用者許可權，也就是使用者通過角色和許可權產生關聯，再去控制使用者的操作。

2.資料許可權

使用者的資料許可權需要新建模型去控制，通過資料範圍的模型去控制，核心是通過資料範圍來控制資料許可權，先定義好在哪些維度上進行資料許可權的控制，資料範圍有各個維度資料的資料集，根據這個資料集去控制使用者的資料的訪問範圍。

2.3屬性

2.3.1 可用性

（1）任何使用者都對應一個或多個角色，一個角色對應一個或多個許可權，每個使用者可以有相同或者不同的許可權。

（2）經RBAC的核心是使用者只和角色關聯，而角色代表對了許可權，這樣設計的優勢在於使得對使用者而言，只需角色即可以，而某角色可以擁有各種各樣的許可權並可繼承。

（3）在一個系統中，如果使用者組的許可權和成員僅可以被系統安全員修改的話，在這種機制下，使用者組的機制是非常接近於角色的概念的。角色也可以在使用者組的基礎上實現，這有利於保持原有系統中的控制關係。在這種情況下，角色相當於一個策略部件，與使用者組的授權及責任關係相聯絡，而使用者組是實現角色的機制，因此，兩者之間是策略與實現機制之間的關係。

2.3.2安全性

（1）使用者許可權

 安全性較好，使用者、許可權和角色三者緊密聯絡。 

（2）資料備份，使用Mysql資料庫，可進行系統資訊備份，允許恢復誤刪的重要資料。

1.概要設計

許可權設計通常包括資料庫設計、應用程式介面(API)設計、程式實現三個部分。這三個部分相互依存，密不可分，要實現完善的許可權管理體系，必須考慮到每一個環節可行性與複雜程度甚至執行效率。

3.1 用例建模

3.1.1 許可權

系統的所有許可權資訊。許可權具有上下級關係，是一個樹狀的結構。每個許可權，兩種情況，一個是隻是可訪問，另一種是可授權，例如對於“檢視使用者”這個許可權，如果使用者只被授予“可訪問”，那麼他就不能將他所具有的這個許可權分配給其他人。

3.1.2 使用者

應用系統的具體操作者，使用者可以自己擁有許可權資訊，可以歸屬於0～n個角色，可屬於0～n個組。他的許可權集是自身具有的許可權、所屬的各角色具有的許可權、所屬的各組具有的許可權的合集。它與許可權、角色、組之間的關係都是n對n的關係。

3.1.3 角色

為了對許多擁有相似許可權的使用者進行分類管理，定義了角色的概念，例如系統管理員、管理員、使用者、訪客等角色。角色具有上下級關係，可以形成樹狀檢視，父級角色的許可權是自身及它的所有子角色的許可權的綜合。父級角色的使用者、父級角色的組同理可推。

3.1.4 組

為了更好地管理使用者，對使用者進行分組歸類，簡稱為使用者分組。組也具有上下級關係，可以形成樹狀檢視。在實際情況中，我們知道，組也可以具有自己的角色資訊、許可權資訊。
下圖讓我們更好的看這些的關係

圖3.1

每個角色至少具備一個許可權，每個使用者至少扮演一個角色；可以對兩個完全不同的角色分配完全相同的訪問許可權；會話由使用者控制，一個使用者可以建立會話並激活多個使用者角色，從而獲取相應的訪問許可權，使用者可以在會話中更改啟用角色，並且使用者可以主動結束一個會話。使用者和角色是多對多的關係，表示一個使用者在不同的場景下可以擁有不同的角色。

3.2 總體架構

在RBAC之中,包含使用者users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個基本資料元素，此模型指明使用者、角色、訪問許可權和會話之間。
1、每個角色至少具備一個許可權，每個使用者至少扮演一個角色；可以對兩個完全不同的角色分配完全相同的訪問許可權；會話由使用者控制，一個使用者可以建立會話並激活多個使用者角色，從而獲取相應的訪問許可權，使用者可以在會話中更改啟用角色，並且使用者可以主動結束一個會話。
2、使用者和角色是多對多的關係，表示一個使用者在不同的場景下可以擁有不同的角色。
3、角色和許可權是多對多的關係，表示角色可以擁有多分權利，同一個權利可以授給多個角色。

3.2.1 用例模型

圖3.2.1 用例模型圖

3.2.2 程式流程

圖3.2.2 程式流程圖

3.2.3 業務流程

圖3.2.3 業務流程圖

3.3動態建模

使用者輸入正確的使用者名稱和密碼之後，控制器接收並在後臺進行操作。可以對使用者進行增刪改查操作。

圖3.3
許可權管理，使用者可以進行許可權管理操作，控制器查詢資料庫返回有的許可權，選擇許可權組進行修改和刪除操作，也可以增加許可權組。使用者也可以具有相應的操作許可權。

4.資料庫設計

許可權管理系統的資料是非常強大的，所以需要將資料仔細分類。許可權邏輯配合業務邏輯。即許可權系統以為業務邏輯提供服務為目標。相當多細粒度的許可權問題因其極其獨特而不具通用意義，它們也能被理解為是“業務邏輯”的一部分。比如，要求：“合同資源只能被它的建立者刪除，與建立者同組的使用者可以修改，所有的使用者能夠瀏覽”。這既可以認為是一個細粒度的許可權問題，也可以認為是一個業務邏輯問題。在這裡它是業務邏輯問題，在整個許可權系統的架構設計之中不予過多考慮。當然，許可權系統的架構也必須要能支援這樣的控制判斷。或者說，系統提供足夠多但不是完全的控制能力。即設計原則歸結為：“系統只提供粗粒度的許可權，細粒度的許可權被認為是業務邏輯的職責”。
許可權公式：Who+What(Which)+How的問題，在這裡我們實現What和部分Which的許可權問題(粗粒度和細粒度相合，到一定的程度)，其他的許可權問題留給業務邏輯解決。下圖便是一個主要的邏輯關係圖。

4.1 資料庫E-R圖

圖4.1

4.2 資料庫表之間的關係

在資料庫建模時，對於N對N的關係，一般需要加入一個關聯表來表示關聯的兩者的關係。初步估計一下，本系統至少需要十張表，分別為：許可權表、使用者表、角色表、組表、使用者許可權關聯表、使用者角色關聯表、角色許可權關聯表、組許可權關聯表、組角色關聯表、使用者屬組關聯表。
許可權表及相關內容大體可以用六個表來描述，如下：
1 角色（即使用者組）表：包括三個欄位，ID，角色名，對該角色的描述；
2 使用者表：包括三個或以上欄位，ID，使用者名稱，對該使用者的描述，其它（如地址、電話等資訊）；
3 角色-使用者對應表：該表記錄用戶與角色之間的對應關係，一個使用者可以隸屬於多個角色，一個角色組也可擁有多個使用者。包括三個欄位，ID，角色ID，使用者ID；
4 限制內容列表：該表記錄所有需要加以許可權區分限制的資料表、功能和欄位等內容及其描述，包括三個欄位，ID，名稱，描述；
5 許可權列表：該表記錄所有要加以控制的許可權，如錄入、修改、刪除、執行等，也包括三個欄位，ID，名稱，描述；
6 許可權-角色-使用者對應表：一般情況下，我們對角色/使用者所擁有的許可權做如下規定，角色擁有明令允許的許可權，其它一律禁止，使用者繼承所屬角色的全部許可權，在此範圍內的許可權除明令禁止外全部允許，範圍外許可權除明令允許外全部禁止。

圖4.2

5.系統實現

系統最終會由終端使用者來維護，許可權分配的直觀和容易理解比較重要，包括概念數量上的簡單和意義上的簡單還有功能上的簡單。想用一個許可權系統解決所有的許可權問題是不現的。設計中將常常變化的“定製”特點比較強的部分判斷為業務邏輯，而將常常相同的“通用”特點比較強的部分判斷為許可權邏輯就是基於這樣的思路。我們將許可權分類，首先是針對資料存取的許可權，通常有錄入、瀏覽、修改、刪除四種，其次是功能，它可以包括例如統計等所有非直接資料存取操作，另外，我們還可能對一些關鍵資料表某些欄位的存取進行限制。
完善的許可權設計應該具有充分的可擴充套件性，也就是說，系統增加了新的其它功能不應該對整個許可權管理體系帶來較大的變化。這個整套邏輯可以結合各個不同的專案，由於我們小組做的是一個微服務的專案沒有ui展示的介面。

6.測試與除錯

相比於常見的三層測試金字塔，在微服務場景下，這個層次可以被擴充套件為5層。分別為單元測試、整合測試、元件測試、契約測試、端到端測試。

單元測試：每個微服務內部，對於領域物件和領域邏輯的測試。它的隔離性比較高，去除其他依賴，執行速度較快。它和其他元件原則上沒有依賴。即使要測試的物件對其他類有依賴，我們會Stub/Mock的手段來將這些依賴消除。

整合測試：整合測試強調模組和外部的互動的驗證，在整合測試時，通常會涉及到外部的元件，比如資料庫和第三方服務。這時候需要儘可能真實的模擬實現與外部元件進行互動，比如使用和真實環境相同型別的資料庫。

元件測試：貫穿應用層和領域層的測試。不過通常來說，這部分的測試不會訪問真實的外部資料來源，而是使用同schema的記憶體資料庫，而且對外部service的訪問也會使用Mock的方式。

契約測試：在微服務場景中，服務之間會有很多依賴關係。根據消費者驅動契約，我們可以將服務分為消費者端和生產者端，通常消費者自己會定義需要的資料格式以及互動細節，並生成一個契約檔案。然後生產者根據自己的契約來實現自己的邏輯，並在持續整合環境中持續驗證。有興趣研究下Pact框架。

端到端測試：端到端測試是整個微服務測試中最困難的，一個完整的環境的創建於維護可能需要花費很大的經歷，特別是當有多個不同的團隊在獨立開發的場景下。另一方面，從傳統的測試金字塔來看，端到端測試應該覆蓋那些業務價值最高的Happy Path。也就是說，端到端測試並不關注異常場景，甚至大部分的業務場景都不考慮。在端到端測試中，最重要的反而不是測試本身，而是環境的自動化能力。實踐docker為主的devops思想。

7.總結

開發專案技術不夠複雜，由於開發人員和測試人員的知識薄弱，技術欠佳，以至於此專案還有待完善。隨著系統的日益龐大，為了方便管理，也可引入角色組對角色進行分類管理，跟使用者組不同，角色組不參與授權。例如：某電網系統的許可權管理模組中，角色就是掛在區局下，而區局在這裡可當作角色組，它不參於許可權分配。另外，為方便上面各主表自身的管理與查詢，可採用樹型結構，如選單樹、功能樹等，當然這些可不需要參於許可權分配。這套系統運用了Oracle是現在大型資料庫中的主流資料庫，與許可權管理系統需要的安全性和可維護性非常合。希望我們組在今後的學習中，能完善這個專案。下學期會學大資料，然後把資料分析也加入在我們組的專案中。

8.致謝

首先得感謝韓萍老師對我們這學期這麼軟體工程的授課，以及在部落格園佈置的那些作業，都對我們這次的團隊專案有所幫助，能更好的分析問題，解決問題。還要感謝姜水波老師對我們java web的授課，讓我們學會了怎麼去連線資料庫，以及很多的前端基礎知識。還要感謝部落格園的那些助教，因為有他們，我們才能理解每次作業的意義在哪裡，才能順利的完成作業。在這裡我也要感謝我的同學，也正是有你們的鼓勵與幫助，一起共同的成長與生活，每天一起熬夜做專案，在遇到問題的時候一起交流，討論，將錯誤一個一個的解決了，雖然還有很多不足，但是有在共同進步非常的開心。