rbac許可權模型的運用
前言：角色訪問控制（rbac）引入了role的概念,目的是為了隔離user(即動作主體，subject)與privilege(許可權，表示對resource的乙個操作，即operation+resource)。 role作為乙個使用者(user)與許可權(privilege)的**層，解耦了許可權和使用者的關係，所有的授權應該給予role而不是直接給user或group。privilege是許可權顆粒，由operation和resource組成，表示對resource的乙個operation。例如，對於新聞的刪除操作。role-privilege是many-to-many的關係，這就是許可權的核心。基於角色的訪問控制方法（rbac）的顯著的兩大特徵是：1.由於角色/許可權之間的變化比角色/使用者關係之間的變化相對要慢得多，減小了授權管理的複雜性，降低管理開銷。2.靈活地支援企業的安全策略，並對企業的變化有很大的伸縮性。
在我們系統中存在著
5種角色需要對不同的內容進行訪問。
1.1 確定角色需要操作的物件
1.1.1 以資料庫中的表作為資源
在本系統中可以存在兩種方案來定義角色需要操作的物件，一種方案是角色直接與數庫
中的表相關聯，也就是說建立一張角色與表的關係表就可以放映出這個關係，但是這樣設計有乙個地方不好控制，系統完成後是以乙個乙個頁面的形式存在於客戶面前，而每乙個頁面裡面所表現的內容難道只和資料庫中的一張表有關係？如果存在和多張表的關係時候，那就得首先判斷某特定使用者屬於的角色對這些表的所有許可權之後再處理具體的表示層；這種做法需要請求乙個頁面的時候進行比較多的判斷，相當於在角色頁面中又增加了乙個資料庫，即為角色，資料庫，頁面之間的關係，在做乙個對資料庫操作比較少的系統時這麼做顯然是很麻煩的。
1.1.2 以頁面作為資源
本系統另外一種定義資源的方式是以頁面做為資源，當頁面做為資源的時候，我們可以在一開就用乙個
asp.net內建的物件session來儲存角色，然後再使用者要請求該頁面的時候用這個session來查資料庫中的角色許可權表，來判斷該角色是否對該頁面有各種操作的許可權，當然某乙個使用者可能有好幾個角色，那只需要多生成幾個session來儲存角色。這樣做的好處是，在使用者請求頁面的時候判斷比較容易。
1.1.3資源選擇總結
以上兩種方案我選擇的是以頁面做為資源，主要是該系統對於資料庫的操作不會像
his系統中那樣對於資料庫的操作那樣多。
1.2操作的描述
操作作為許可權的核心之一，通常情況下包括了增刪改查四種操作，關鍵的問題就在於如何在資料庫中放映出這四種操作，這裡仍然有兩種方案。第一可以將這四種操作分別作為四個字段，用乙個標誌號來表示某主體是否具有某種操作，第二可以將這四個操作放在乙個欄位中用
4位二進位制數表示，有某一操作就將具體的二進位制數至1。這樣做的好處，對於許可權的操作看起來清晰明了，而且在具體查詢角色許可權表的時候也只用去查詢乙個字段，不用查詢4個字段，操作上會減少不少。
1.3對於角色和使用者的簡單描述
乙個系統會有使用它的使用者群，這個群裡，肯定會有很多具有對這個系統有著同等權力的
使用者，於是將這些具有同等權力的使用者分進某乙個角色裡。這樣角色的數量肯定會少於使用者的數量，於是在以後的對龐大的使用者資料進行的維護過程中，可以將維護過程簡化為使用者角色管理與角色許可權管理了。
1.4本系統關於使用者許可權的基本資料表
經過以上分析，本系統所需要的使用者管理模組所需要基本資料表就出來了
1.使用者資訊表
2.角色資訊表
3.使用者角色關係表
4.角色許可權關係表
5.許可權物件說明表
以上的**中，每張表都會用乙個
id號來作為該錶的主鍵，其中使用者和角色之間是多對多的關係，角色和許可權之間也是多對多的關係。每個表中具體字段暫且不表。
1．5分析基本資料表
現在假設乙個使用者登陸本系統且這個使用者為合法使用者，那麼在他登陸之後就可以根據使用者角色表確定該使用者的角色（這個角色可以是乙個角色，也可以是多個角色）；然後再根據角色許可權表可以最終確定該使用者對那幾個頁面有某種具體的組合操作的權力。
狹義上的許可權管理有了這
5張表明顯已經足夠了，但是我們系統中存在乙個功能樹，樹的節點是根據特定角色的許可權來顯示的，也就是說得加乙個表功能樹資料表，裡面將頁面物件與樹的節點關聯起來，當然並不是所有的頁面都會與某乙個節點對應，也不是所有的節點一定要對應於乙個頁面，關於這個功能樹的表的設計問題在層次資料庫設計中本人已經做過分析，這裡不再詳述。我採用的是父節點加子節點的設計方式。
那麼在使用者登陸之後查詢到了該使用者對應的能操作的且存在於功能樹結點中的頁面，是不是就能夠很順利的顯示出樹呢？看來似乎還有個小問題需要解決掉！
因為乙個使用者可能對應於幾個角色，好幾個角色中顯然也有可能存在對同乙個頁面有相同的操作權力，如果該頁面是功能樹的乙個節點，在使用者登陸之後要顯示出樹就得想辦法去掉相同的節點。
在後台**中我們可以做到這一點，具體做法肯定是把某使用者所對應的所有角色的相關頁面
id號放入乙個datatable（ado.net中乙個具體物件，相當於一張**）,然後去掉重複的頁面，即id號相同的頁面，然後再從功能樹資料表中去查詢這些頁面的父節點生成一顆功能樹（具體生成方案兩種做法，深度遍歷和廣度遍歷，本章不做討論）。當然我們完全可以在資料庫中在做一張表為角色功能樹節點對應表，這樣直接通過查詢這張**找出不重複的節點來生成樹，這樣就減少了很多後台邏輯，帶來了很大的方便。
1．6許可權管理模組總結
綜上所述，本系統的許可權管理模組一共有
7張資料表：
1. 使用者資訊表
2. 角色資訊表
3. 使用者角色關係表
4. 角色許可權關係表
5. 許可權物件說明表
6. 功能樹資料表
7．角色功能樹節點對應表
1． 7 對rbac模型的分析
nist（the national institute of standards and technology，美國國家標準與技術研究院）標準rbac模型由4個部件模型組成，這4個部件模型分別是基本模型rbac0（core rbac）、角色分級模型rbac1（hierarchal rbac）、角色限制模型rbac2（constraint rbac）和統一模型rbac3（combines rbac）。
上述幾節主要是針對rbac0來談的，從實際運用和rbac的其他3個模型我們可以看出，在rbac模型中對於角色的設計其實是擴充套件性和靈活性都很強的，本系統中主要是涉及的角色種類並不太多，所以沒有考慮角色的繼承和限制關係。但是在多覺得功能樹節點的重複問題上，明顯也可以用角色的繼承和限制加以解決，但是由於功能樹的節點並不多，所有節點一共也就不到二十個，所以並沒有採用rbac3模型。
當然該模型還有一些可以擴充套件的地方,在參閱了一些文章後，我覺得以下幾點可以更好的擴充套件rbac模型。
1.使用者組授權功能。
2.角色型別功能。這個功能並不是很重要，建立乙個型別表，每個角色可以歸屬乙個角色型別，便於表達方便，層次清晰，這個功能主要的作用在於表示層的顯示上。
3.角色優先功能。可以定義乙個優先級別表，給每個角色賦予優先級別，在處理角色的請求時，根據角色的優先級別排入煉表裡進行處理，煉表裡的角色請求可以根據優先順序別的不同動態調整，系統在處理角色請求時，每次都從隊首取乙個角色請求，再將隊首指標指向下乙個角色請求。
4.角色生存週期功能。這個功能可以指定角色的生存時間，時間可以是使用者指定的，也可以是根據某個條件來決定的。
5.角色根據責任鏈動態變更許可權功能。在乙個責任鏈裡，乙個客戶程式發出請求，這個請求將沿著責任鏈進行傳遞，責任鏈裡的每個結點將依次處理該請求，如果結點不能處理該請求，則將此請求**到責任鏈的下一結點上；或者是，責任鏈中的每乙個結點都對該請求進行處理。在處理的過程中，角色的許可權將根據需求動態變化。
6.角色根據狀態動態變更許可權功能。在應用程式中可能存在多種狀態，比如在乙個字處理程式中，當檔案狀態是唯讀時，和檔案狀態在可讀可寫時，它的功能是不一樣的，那麼角色需要根據這種狀態的變更而動態變更許可權集，以便適應這種應用程式的要求。
當然了模型的存在並不意味著任何設計都一定要套用某種模型，只是說這個模型給了我們一些很好的啟示和一套已經比較成熟的方**，畢竟這些只是工程模型並不是數學或者物理定理，我們再設計中實事求是的根據需求，合理的考慮一些擴充套件性結合這些模型肯定能設計出一套滿足我們需要的系統。
static extern 在大工程中的運用
一，static和extern 大工程下我們會碰到很多原始檔。檔案a.c static int i 只在a檔案中用 int j 在工程裡用 static void init 只在a檔案中用 void callme 在工程中用 上面的全域性i變數和init 函式只能用在a.c檔案中,全域性變數sum的...
中運用 膠水在木雕中的運用技巧
hi，歡迎收看本期 木雕裡的那些事 我是你的解密人，谷藏峰 做木雕時，有時難免會碰到，關鍵部件斷裂的情況，自己辛辛苦苦做了那麼久，就因為這些小缺陷，整個報廢，未免有些可惜。那麼該怎麼辦呢？這個時候，就要用到它了 502膠水 這是我們生活中，粘鞋時會用到的一種速乾膠水。在各種五金雜貨店都能買到。它能在...
paxos工程中的運用 multi paxos
上篇介紹了paxos的理論知識 要在實際工程運用大多數使用multi paxos協議，原因是樸素paxos每次提議都執行完整paxos協議代價過大 3次網路互動，2 次本地持久化，因此，multi paxos引入leader概念，較少paxos的prepare互動，較少樸素paxos每次提議互動過多...