前段時(shí)間分別用vue和react寫了兩個(gè)后臺(tái)管理系統(tǒng)的模板vue-quasar-admin和3YAdmin猿诸。兩個(gè)項(xiàng)目中都實(shí)現(xiàn)了基于RBAC的權(quán)限控制。因?yàn)楸韭毠ぷ魇呛蠖碎_(kāi)發(fā)蛮穿，比較清楚權(quán)限控制一個(gè)管理系統(tǒng)應(yīng)該必須具備的核心功能，而且是可以做到通用的钓账。打算寫寫關(guān)于管理系統(tǒng)前后端分離方面的文章，也是做一個(gè)知識(shí)的總結(jié)絮宁，其中會(huì)涉及到vue,react,node,.net core等方面的知識(shí)梆暮。
術(shù)語(yǔ)描述
- 用戶(Subject)：發(fā)起操作的主體
- 對(duì)象(Object)：指操作所針對(duì)的客體對(duì)象，比如文章或評(píng)論
- 權(quán)限(Permission)：用來(lái)指代對(duì)某種對(duì)象的某一種操作绍昂，例如“添加文章的操作”
- 權(quán)限碼：權(quán)限的代號(hào)惕蹄，例如用“ARTICLE_ADD”來(lái)指代“添加文章的操作”權(quán)限
權(quán)限有時(shí)候也可以稱為動(dòng)作或者功能。比如“添加文章”治专，既可以認(rèn)為它是一個(gè)動(dòng)作卖陵，也可以認(rèn)為它是一個(gè)功能。對(duì)象也可以稱為資源张峰。
常用的權(quán)限模型
- ACL(Access Control List)(訪問(wèn)控制列表)
- DAC(Discretionary Access Control)(自主訪問(wèn)控制)
- MAC(Mandatory Access Control)(強(qiáng)制訪問(wèn)控制)
- RBAC(Role-Based Access Control)(基于角色的訪問(wèn)控制)
- ABAC(Attribute-Based Access Control)(基于屬性的訪問(wèn)控制)
ACL(Access Control List)(訪問(wèn)控制列表)
ACL是最早也是最基本的一種訪問(wèn)控制機(jī)制泪蔫，它是用來(lái)描述用戶和權(quán)限之間關(guān)系的數(shù)據(jù)列表。它的原理非常簡(jiǎn)單：每一項(xiàng)資源喘批，都配有一個(gè)列表撩荣，這個(gè)列表記錄的就是哪些用戶可以對(duì)這項(xiàng)資源執(zhí)行CRUD等操作。當(dāng)試圖訪問(wèn)這項(xiàng)資源時(shí)饶深，會(huì)首先檢查這個(gè)列表中是否有關(guān)于當(dāng)前用戶的訪問(wèn)權(quán)限餐曹，從而確定當(dāng)前用戶可否執(zhí)行相應(yīng)的操作。
例如一個(gè)文件對(duì)象的 ACL 為 Alice: read,write; Bob: read敌厘，這代表 Alice 對(duì)該文件既能讀又能寫台猴，而 Bob 只能讀取。
由于ACL的簡(jiǎn)單性俱两，使得它幾乎不需要任何基礎(chǔ)設(shè)施就可以完成訪問(wèn)控制饱狂。但同時(shí)它的缺點(diǎn)也是很明顯的，由于需要維護(hù)大量的訪問(wèn)權(quán)限列表宪彩，ACL在性能上有明顯的缺陷休讳。另外，對(duì)于擁有大量用戶與眾多資源的應(yīng)用尿孔，管理訪問(wèn)控制列表本身就變成非常繁重的工作俊柔。
最開(kāi)始的ACL定義中，用戶直接和權(quán)限掛鉤活合，數(shù)據(jù)存儲(chǔ)的是用戶與權(quán)限的關(guān)聯(lián)關(guān)系雏婶。如果兩個(gè)用戶的權(quán)限是一樣的，那么就需要分別存儲(chǔ)這兩個(gè)用戶與權(quán)限的關(guān)聯(lián)關(guān)系芜辕，也是上面所提到的ACL的缺陷尚骄。為了解決這些問(wèn)題，便有了對(duì)ACL設(shè)計(jì)的改進(jìn)侵续，相同權(quán)限的用戶放到同一個(gè)分組里倔丈，分組與權(quán)限掛鉤憨闰，不再是用戶直接與權(quán)限掛鉤。以及后來(lái)出現(xiàn)的RBAC(基于角色的訪問(wèn)控制)需五，角色與分組也是差不多的概念鹉动，角色直接與權(quán)限掛鉤，用戶再與角色進(jìn)行關(guān)聯(lián)宏邮。
所以泽示，現(xiàn)在一般說(shuō)ACL,不再是用戶直接和權(quán)限掛鉤的一種權(quán)限控制模型，把它看做一個(gè)單純的訪問(wèn)控制列表即可蜜氨。列表里維護(hù)的可能是用戶與權(quán)限的關(guān)系械筛，也可以是用戶組與權(quán)限的關(guān)系，也可以是角色與權(quán)限的關(guān)系飒炎，甚至是部門埋哟，職位等等于權(quán)限的關(guān)系。
ACL是權(quán)限體系中的業(yè)務(wù)規(guī)則郎汪。RBAC等權(quán)限模型要用到ACL才能工作赤赊，ACL服務(wù)于RBAC等權(quán)限模型，其它權(quán)限控制體系里的權(quán)限規(guī)則也叫ACL煞赢。
DAC(Discretionary Access Control)(自主訪問(wèn)控制)
系統(tǒng)會(huì)識(shí)別用戶抛计，然后根據(jù)被操作對(duì)象（Subject）的權(quán)限控制列表（ACL: Access Control List）或者權(quán)限控制矩陣（ACL: Access Control Matrix）的信息來(lái)決定用戶的是否能對(duì)其進(jìn)行哪些操作，例如讀取或修改照筑。
而擁有對(duì)象權(quán)限的用戶吹截，又可以將該對(duì)象的權(quán)限分配給其他用戶，所以稱之為“自主（Discretionary）”控制朦肘。
因?yàn)橛脩裟茏灾鞯貙⒆约簱碛械臋?quán)限授予其他用戶饭弓，所以DAC模型可以任意傳遞權(quán)限，用戶能間接獲得本不具有的訪問(wèn)權(quán)限媒抠，因此DAC模型的安全性較低，不能給系統(tǒng)充分的數(shù)據(jù)保護(hù)咏花。
DAC可以直接使用ACL的物理模型趴生，區(qū)別在于，DAC模型中用戶可以將自己具備的權(quán)限分配給其它用戶(程序里的操作就是根據(jù)用戶ID篩選出權(quán)限列表昏翰，根據(jù)列表為要分配權(quán)限的用戶構(gòu)造出新的權(quán)限列表并保存)
DAC是傳統(tǒng)的UNIX訪問(wèn)控制模型苍匆，也是Windows文件系統(tǒng)的訪問(wèn)控制模型。
Windows的文件訪問(wèn)權(quán)限的設(shè)置中棚菊，除了用戶浸踩，還有組。這個(gè)組與后面要說(shuō)到的RABC模型的角色有什么區(qū)別呢统求？
https://stackoverflow.com/questions/7770728/group-vs-role-any-real-difference
我認(rèn)為沒(méi)必要去劃分的太清楚检碗，不管是組還是角色，都是為了更好的管理和分配權(quán)限在最原始的ACL模型上做的改進(jìn)。如果有需要绪囱，甚至可以把權(quán)限分配到部門绪抛，職位上。
MAC(Mandatory Access Control)(強(qiáng)制訪問(wèn)控制)
MAC是為了彌補(bǔ)DAC權(quán)限控制過(guò)于分散的問(wèn)題而誕生的怕犁。在MAC的設(shè)計(jì)中边篮，每一個(gè)對(duì)象都有一些權(quán)限標(biāo)識(shí)，每個(gè)用戶同樣也會(huì)有一些權(quán)限標(biāo)識(shí)奏甫，而用戶能否對(duì)該對(duì)象進(jìn)行操作取決于雙方的權(quán)限標(biāo)識(shí)的關(guān)系戈轿，這個(gè)限制判斷通常是由系統(tǒng)硬性限制的。訪問(wèn)時(shí)阵子，系統(tǒng)先對(duì)用戶的訪問(wèn)許可級(jí)別和資源對(duì)象的密級(jí)進(jìn)行比較凶杖，再?zèng)Q定用戶是否可以訪問(wèn)資源對(duì)象。用戶不能改變自身和資源對(duì)象的安全級(jí)別款筑，只有系統(tǒng)管理員或管理程序才能 控制資源對(duì)象和用戶的級(jí)別智蝠。比如在影視作品中我們經(jīng)常能看到特工在查詢機(jī)密文件時(shí)，屏幕提示需要“無(wú)法訪問(wèn)奈梳，需要一級(jí)安全許可”杈湾，這個(gè)例子中，文件上就有“一級(jí)安全許可”的權(quán)限標(biāo)識(shí)攘须，而用戶并不具有漆撞。
MAC非常適合機(jī)密機(jī)構(gòu)或者其他等級(jí)觀念強(qiáng)烈的行業(yè)，但對(duì)于類似商業(yè)服務(wù)系統(tǒng)于宙，則因?yàn)椴粔蜢`活而不能適用浮驳。
MAC可以繼續(xù)使用DAC的模型，但是要對(duì)用戶進(jìn)行等級(jí)劃分捞魁，比如一級(jí)至会，二級(jí)，三級(jí)谱俭。奉件。。昆著，對(duì)對(duì)象資源也要做劃分县貌，比如機(jī)密，秘密和最高機(jī)密凑懂。用戶訪問(wèn)的資源的時(shí)候煤痕，根據(jù)用戶等級(jí)與資源訪問(wèn)級(jí)別來(lái)做判斷，比如一級(jí)用戶只能訪問(wèn)機(jī)密文件，如果訪問(wèn)的是最高機(jī)密文件摆碉，系統(tǒng)就會(huì)拒絕塘匣。這一系列規(guī)則是優(yōu)先于DAC的，如果MAC與DAC混用兆解，要先校驗(yàn)MAC再校驗(yàn)DAC馆铁。
RBAC(Role-Based Access Control)(基于角色的訪問(wèn)控制)
ACL的訪問(wèn)控制機(jī)制中，直接維護(hù)的是用戶與功能的關(guān)系锅睛，這一系列的關(guān)系就是一個(gè)權(quán)限列表埠巨。當(dāng)很多的用戶具有相同功能權(quán)限的時(shí)候，就要進(jìn)行繁瑣的關(guān)聯(lián)操作现拒。RBAC就是在用戶與權(quán)限之間引入了角色的概念辣垒。用戶與角色之間做關(guān)聯(lián)，權(quán)限列表維護(hù)的是角色與功能的關(guān)系印蔬。
RBAC是目前使用最普遍的權(quán)限控制模型勋桶。當(dāng)某些用戶具備相同的權(quán)限的時(shí)候，只需要為這些用戶建一個(gè)角色侥猬，把相應(yīng)的功能關(guān)聯(lián)到這個(gè)角色上例驹，生成角色的權(quán)限列表。當(dāng)有新的用戶需要相同權(quán)限的時(shí)候退唠，把用戶關(guān)聯(lián)到這個(gè)角色上即可鹃锈。而當(dāng)用檢查或校驗(yàn)用戶的操作權(quán)限的時(shí)候，查詢用戶所屬角色的權(quán)限列表即可瞧预。
當(dāng)然屎债，RBAC也不是完美的，比如想要為某個(gè)用戶單獨(dú)設(shè)置某個(gè)功能權(quán)限垢油，可能需要為這個(gè)功能權(quán)限單獨(dú)創(chuàng)建一個(gè)角色盆驹，然后把特定的用戶關(guān)聯(lián)到這個(gè)角色上。當(dāng)想要移除某個(gè)用戶的特定功能權(quán)限的時(shí)候滩愁，可能需要重新設(shè)置角色的功能權(quán)限躯喇，把特定功能權(quán)限從當(dāng)前角色中移除，建立新的角色并關(guān)聯(lián)特定的功能權(quán)限惊楼，然后再把新角色與相關(guān)的用戶做關(guān)聯(lián)(也可以直接在特定功能的程序里校驗(yàn)操作用戶)
這里說(shuō)一個(gè)比較常見(jiàn)的RBAC的錯(cuò)誤的用法：那就是直接使用角色做權(quán)限判斷玖瘸。比如只有角色A才能做文章的刪除操作。
function delPost(postId){
if(!isRole('A')){
return false;
}
}
如果需求該為角色B也可以刪除文章檀咙。那就必須修改代碼
function delPost(postId){
if(!isRole('A')&&!isRole('B')){
return false;
}
}
正確的做法應(yīng)該是添加"刪除文章"這個(gè)功能，把這個(gè)功能關(guān)聯(lián)到相應(yīng)的角色上璃诀。判斷的時(shí)候是根據(jù)功能去判斷而不是角色弧可。
function delPost(postId){
if(!hasPermission('POST_DEL')){
return false;
}
}
針對(duì)“只有角色A才能做文章的刪除操作”這一需求，把這個(gè)刪除功能關(guān)聯(lián)到角色A上，然后把需要這個(gè)操作權(quán)限的用戶加入到角色A中即可棕诵。當(dāng)別的角色也需要這個(gè)操作權(quán)限裁良，把功能關(guān)聯(lián)到對(duì)應(yīng)角色上即可，不需要再修改代碼校套。
在RBAC的核心基礎(chǔ)上价脾，還可以做相應(yīng)的擴(kuò)展，比如角色繼承笛匙，角色分組之類的侨把，這些擴(kuò)展都是為了在一定程度簡(jiǎn)化權(quán)限管理工作。
ABAC(Attribute-Based Access Control)(基于屬性的權(quán)限控制)
RBAC雖然是目前最普遍的權(quán)限控制模型妹孙。但是某些情況下秋柄，RBAC是無(wú)法滿足并且也實(shí)現(xiàn)不了的。比如業(yè)務(wù)員1和業(yè)務(wù)員2都屬于業(yè)務(wù)員角色蠢正，都有查看客戶訂單的權(quán)限骇笔。當(dāng)有一個(gè)需求，要求業(yè)務(wù)員1只能查看北京地區(qū)的客戶的訂單嚣崭，業(yè)務(wù)員2只能查看上海的客戶的訂單笨触。這單單使用RBAC是無(wú)法實(shí)現(xiàn)。借助RBAC雹舀，可行的做法是芦劣，分地區(qū)創(chuàng)建角色，然后程序中根據(jù)角色做數(shù)據(jù)的過(guò)濾葱跋，這種做法缺點(diǎn)之前也提到過(guò)持寄，需求變更的時(shí)候可能需要每次都修改代碼。
上面業(yè)務(wù)員查看訂單的例子娱俺，地區(qū)是訂單的一個(gè)屬性稍味，需求就是針對(duì)這個(gè)地區(qū)屬性來(lái)做訂單的查詢范圍的權(quán)限控制。這種權(quán)限控制方式就是ABAC(Attribute-Based Access Control)(基于屬性的權(quán)限控制)荠卷，也被一些人稱為是權(quán)限系統(tǒng)設(shè)計(jì)的未來(lái)模庐。
不同于常見(jiàn)的將用戶通過(guò)某種方式關(guān)聯(lián)到權(quán)限的方式，ABAC則是通過(guò)動(dòng)態(tài)計(jì)算一個(gè)或一組屬性是否滿足某種條件來(lái)進(jìn)行授權(quán)判斷的（可以編寫簡(jiǎn)單的邏輯）油宜。屬性通常來(lái)說(shuō)分為四類：用戶屬性（如用戶年齡）掂碱，環(huán)境屬性（如當(dāng)前時(shí)間），操作屬性（如讀壬髟）和對(duì)象屬性（如一篇文章疼燥，又稱資源屬性），所以理論上能夠?qū)崿F(xiàn)非常靈活的權(quán)限控制蚁堤，幾乎能滿足所有類型的需求醉者。
例如規(guī)則：“允許所有班主任在上課時(shí)間自由進(jìn)出校門”這條規(guī)則，其中，“班主任”是用戶的角色屬性撬即，“上課時(shí)間”是環(huán)境屬性立磁，“進(jìn)出”是操作屬性，而“校門”就是對(duì)象屬性了剥槐。
ABAC非常的靈活唱歧，但是實(shí)現(xiàn)也是非常的難。這其中涉及到邏輯的動(dòng)態(tài)執(zhí)行粒竖，數(shù)據(jù)動(dòng)態(tài)過(guò)濾等颅崩，更加具體就是動(dòng)態(tài)拼接SQL語(yǔ)句(使用ORM的話就是動(dòng)態(tài)組裝對(duì)應(yīng)ORM的查詢語(yǔ)句)。
感興趣的可以在Github上搜索ABAC温圆，看看不同語(yǔ)言是否已經(jīng)有現(xiàn)成的解決方案挨摸。下面說(shuō)說(shuō)我學(xué)習(xí)到的一種實(shí)現(xiàn)方式：
還是業(yè)務(wù)員查看訂單的例子，在RBAC的基礎(chǔ)上岁歉，擴(kuò)展一個(gè)實(shí)體規(guī)則得运，訂單就是實(shí)體，也就是針對(duì)訂單設(shè)置一系列的規(guī)則锅移。規(guī)則存儲(chǔ)格式可以是json也可以是xml,甚至是Sql語(yǔ)句熔掺，能解析即可。比如北京地區(qū)這個(gè)規(guī)則：
{
"regionId":1
}
上海地區(qū)：
{
"regionId":3
}
regionId 就是系統(tǒng)里對(duì)應(yīng)區(qū)域的Id,也是訂單或訂單相關(guān)表的某個(gè)字段非剃。
保存這個(gè)規(guī)則的時(shí)候置逻，規(guī)則內(nèi)容(就是上面的json),規(guī)則實(shí)體(也就是訂單，表明這個(gè)規(guī)則是針對(duì)訂單的)是必須的备绽。也可以加上這個(gè)規(guī)則是適用增刪改查中的一種或多種券坞。
創(chuàng)建好實(shí)體的規(guī)則，將規(guī)則與角色做關(guān)聯(lián)肺素，也就是將北京地區(qū)的規(guī)則關(guān)聯(lián)到北京地區(qū)角色上恨锚，上海地區(qū)的規(guī)則關(guān)聯(lián)到上海地區(qū)角色上。
后端做權(quán)限校驗(yàn)的時(shí)候倍靡，還是先按RBAC模型的控制方式進(jìn)行校驗(yàn)(是否具備訂單查看權(quán)限)猴伶，然后根據(jù)當(dāng)前操作對(duì)象(也就是實(shí)體)，取出用戶所屬角色關(guān)聯(lián)的對(duì)應(yīng)實(shí)體的規(guī)則塌西。然后解析規(guī)則他挎，動(dòng)態(tài)拼接Sql或者ORM語(yǔ)句。
沒(méi)做地區(qū)限制(或沒(méi)配置規(guī)則)的時(shí)候捡需，Sql可能是
select userId,orderNo,createdDate from T_Order
配置了規(guī)則办桨，解析拼接后可能就是
select userId,orderNo,createdDate from T_Order where regionId=1
這里是針對(duì)地區(qū)這個(gè)屬性實(shí)現(xiàn)了動(dòng)態(tài)的權(quán)限控制。實(shí)際開(kāi)發(fā)過(guò)程中站辉，要控制的東西是非常多了崔挖，查看字段的控制贸街，數(shù)據(jù)范圍的控制庵寞。要滿足這些復(fù)雜的控制狸相，需要制定一套完整的規(guī)則，以及針對(duì)規(guī)則編寫相應(yīng)的解析程序捐川。比如根據(jù)配置的規(guī)則脓鹃，最后解析出來(lái)可能是各種Sql語(yǔ)句:<,>,=,like,in,not in等等。
可以看出古沥，要真正的落地實(shí)現(xiàn)ABAC是多么的復(fù)雜瘸右。每次都要解析規(guī)則，對(duì)程序的性能也造成的影響岩齿，就算使用緩存太颤，命中的概率也是非常的小，因?yàn)楹芏嘁蛩囟际莿?dòng)態(tài)的盹沈。
所以龄章，如果需要根據(jù)屬性做權(quán)限判斷的場(chǎng)景不是很多的話，還是建議使用RBAC乞封，然后程序中做判斷比較省事省力做裙。
總結(jié)
ACL早期定義中是一種權(quán)限控制機(jī)制，這種機(jī)制直接維護(hù)的是用戶與功能的關(guān)系肃晚，功能就是針對(duì)對(duì)象定義的一些操作锚贱，比如增刪改查的等。用戶與功能的關(guān)系列表也稱為權(quán)限列表或訪問(wèn)控制列表关串，現(xiàn)在說(shuō)ACL拧廊，一般就是指這個(gè)權(quán)限列表或訪問(wèn)控制列表，但是里面維護(hù)的關(guān)系不一定是用戶與功能的關(guān)系晋修，在RBAC中維護(hù)的就是角色與功能的關(guān)系吧碾。
RBAC在ACL的基礎(chǔ)上加入了角色的概念，權(quán)限列表或訪問(wèn)控制列表里維護(hù)的不再是用戶與功能的關(guān)系飞蚓，而是角色與功能的關(guān)系滤港。ACL可以和RBAC混著用，既可以在角色上設(shè)置權(quán)限趴拧，也可以直接給用戶設(shè)置權(quán)限溅漾，更加靈活。借助角色的思想著榴，可以在用戶組添履，組織，職位等等上設(shè)置權(quán)限脑又，以便更好的做好權(quán)限管理暮胧，也就是將權(quán)限設(shè)置從單一個(gè)體轉(zhuǎn)移到某一類組合上锐借。
ABAC非常的靈活，也非常的難實(shí)現(xiàn)往衷。
