rbac：role based access control，翻譯過來基本上就是基於角色的訪問控制系統。
acl：access control list，訪問控制列表，是前幾年盛行的一種許可權設計，它的核心在於使用者直接和許可權掛鉤。rbac的核心是使用者只和角色關聯，而角色代表對了許可權，這樣設計的優勢在於使得對使用者而言，只需角色即可以，而某角色可以擁有各種各樣的許可權並可繼承。acl和rbac相比缺點在於由於使用者和許可權直接掛鉤，導致在授予時的複雜性，雖然可以利用組來簡化這個複雜性，但仍然會導致系統不好理解，而且在取出判斷使用者是否有該許可權時比較的困難，一定程度上影響了效率。
我想理一理思路，看看acl與rbac的區別:
還是以部門新聞來討論，對於靜態授權，在系統設計做需求分析的時候，往往就可以確定乙個系統角色的種類，像新聞系統中，根據需求，可能會有新聞發布者(publisher)，新聞審核者(reviewer)，新聞瀏覽者(visitor)，管理員(manager)以及超級管理員(administrator)。
在設計的時候我們也已經把這些角色與相應的一些operation繫結在一起。
如：publisher擁有publish_operation modify_operation
reviewer擁有review_operation modify_operation delete_operation
visitor擁有visit_operation,
manager擁有create_news_system_instance_operation
modify_news_system_instance_operation
delete_news_system_instance_operation
administrator負責create_user_operation
delete_user_operation
assign_permission_operation
deassign_permission_operation
assign_role_operation
deassign_role_operation
在授權時，往往先為乙個使用者(user)，賦予乙個角色，如:manager.這樣，user就擁有了對所有news_instance(也就是部門新聞)操作的許可權。現在假設使用者(usera)訪問create_news_system_instance功能來建立乙個新的新聞例項，叫做採購部門新聞.因為我們在設計的時候就確定，該功能只能由manager來訪問，於是，系統中許可權的判斷部分會首先判斷當前使用者(usera)是否manager角色，是的話就允許訪問，否則顯示沒有授權的錯誤資訊。
所以，對於manager這樣的應用:
[1]在設計的時候，我們就將這樣的角色與相應的permissions(alistofsubject-operationpairs)關聯在一起了，這裡的subject是所有的新聞例項(news_instance),operation就是create,modify以及delete.
[2]在授權的時候，超級管理員(administrator)可以利用assign_role_operation將使用者(user)與manager這個角色關聯起來。這樣，user就擁有了對所有新聞例項的create,modify以及delete操作的許可權。
[3]在許可權判斷的時候，rbac系統首先判斷當前使用者是否是設計時確定的角色(這裡是manager),如果是，就允許使用者訪問，否則就拒絕訪問，並顯示錯誤資訊。
對於publisher這樣的角色有些不同，publisher這個角色只與operation繫結在一起，並沒有與具體的subject相關聯，因此，在授權的時候，還需要指定相應的subject.
所以，對publisher這樣只能事先確定operation的應用來說:
[1]在設計的時候，我們只能確定該角色能進行哪些操作，而不能確定這些操作實施的物件。
[2]在授權的時候:
[2.1]首先將publisher與subject關聯,如將publisher與採購部門新聞關聯產生:採購部門新聞_news_publisher的角色
[2.2]administrator為使用者(user)授於採購部門新聞_news_publisher角色。從而user擁有了對"採購部門新聞"的發布許可權
[3]在許可權判斷的時候，使用者訪問採購部門新聞_news_publish_operation,系統首先判斷該使用者是否採購部門新聞_news_publisher?如果是，就允許使用者訪問，否則就拒絕訪問，並顯示錯誤資訊。
這裡用到的方法可能是這個樣子:
booleancheckpermission(採購部門新聞,publish_operation,user)
}returnfalse;
}假如說，不採用rbac的做法，考慮一下，使用acl，那又會是什麼樣子呢?
對於manager那樣能在設計時就確定subject與operation的角色，我認為沒有必要考慮acl了.對於publisher這樣，只能事先確定operation的角色，我們來做個對比.許可權系統要靈活，但是也要簡潔，要不然就很可能導至失控。因為巢狀的層次太多，有可能發生不可預知的情況.有一天管理員可能會莫明的發現，怎麼這個人會有這個許可權的?
所以，我認為在rbac裡不支援role的層級關係為妙。
好了，現在來看看acl對publisher應用
這裡指的acl是直接將user或group與subject關聯的做法。
user與subject是多對多的情況，
group與subject也是多對多的情況，
同樣的，user與group也是多對多的情況。
現在，還是以採購部門新聞為例:
[1]在授權的時候，可以有以下操作:
[1.1]將user與subject關聯在一起,但是要指定相應的operation.
如:assignpermission(採購部門新聞,publish_operation,user)
[1.2]將group與subject關聯在一起:
如:assignpermission(採購部門新聞,publish_operation,group)
[1.3]將user與group關聯
如:assignusergroup(user,group)
[2]在許可權判斷的時候，使用者訪問採購部門新聞_news_publish_operation，系統做如下檢查:
booleancheckpermission(採購部門新聞,publish_operation,user)
ACL的原理與基本ACL的配置
acl access control list 訪問控制列表，在路由器介面上使用的規則列表。規則 匹配資料報，實現資料報的控制 過濾或放行 作用 動作 permit允許，deny拒絕。acl讀取第三層 ip 和第四層 tcp udp 的頭部資訊 源ip，目標ip，源埠，目標埠，然後根據預先定義好的規...
ACL原理與配置
個人總結 實驗環境 實驗思路 具體實施 將放置的ar1 ar2和ar3連線。框選路由器後全部開啟。連線線處顯示綠色訊號燈，表示全部開啟 ar1 ar1 int g0 0 0 ar1 gigabitethernet0 0 0 ip add 10.1.1.1 24 ar2 ar2 int g0 0 0 ...
標準ACL 擴充套件ACL和命名ACL的配置詳解
訪問控制列表 acl 是應用在路由器介面的指令列表 即規則 這些指令列表用來告訴路由器，那些資料報可以接受，那些資料報需要拒絕。訪問控制列表 acl 的工作原理 acl使用包過濾技術，在路由器上讀取osi七層模型的第3層和第4層包頭中的資訊。如源位址，目標位址，源埠，目標埠等，根據預先定義好的規則，...