這裏只對基於角色的訪問控制與基於資源的訪問控制做一個思想上的認識
一、說明
基於角色的權限訪問控制RBAC（role-based access control）是以角色爲中心進行的訪問控制，也就是判斷主體subject是那個角色的方式進行權限訪問控制，是粗粒度的
基於資源的權限訪問控制RBAC（resource-based access control）是以資源爲中心進行的訪問控制，只需要爲角色添加權限就可以
粗粒度與細粒度
粗粒度權限管理，對資源類型的權限管理。資源類型比如：菜單、url連接、用戶添加頁面、用戶信息、類方法、頁面中按鈕。。
粗粒度權限管理比如：超級管理員可以訪問戶添加頁面、用戶信息等全部頁面。
部門管理員可以訪問用戶信息頁面包括 頁面中所有按鈕。
細粒度權限管理，對資源實例的權限管理。資源實例就資源類型的具體化，比如：用戶id爲001的修改連接，1110班的用戶信息、行政部的員工。
細粒度權限管理就是數據級別的權限管理。
細粒度權限管理比如：部門經理只可以訪問本部門的員工信息，用戶只可以看到自己的菜單，大區經理只能查看本轄區的銷售訂單。。
二、區別
1、基於角色的訪問控制
由於基於角色的權限訪問控制的角色與權限往往是多對多的關係（比如admin角色可以所有CURD的權限，部門經理角色有Retrieve權限，這就是多對多關係了），如果角色所對應的權限發生變化 ，那我們所編寫的判斷邏輯就必須發生改變，可擴展性差
比如：原本只有admin可以訪問，那麼判斷可以這麼寫
if(role.equals(”admin”)){
//retrieve
}
但是假設後期需要給部門經理角色也賦予retrieve權限，那麼必須改變原有代碼，或者另外增加代碼，總之要改變原有的判斷邏輯
if(role.equals("admin") || role.equals("manager")){
//retrieve
}
2、基於資源的訪問控制
如果是基於資源的權限訪問控制，資源和權限一對一關係比較常見，很多時候資源和權限在數據庫中會被合併在一張表中，只需要爲資源分配相應的權限。所以一個具體操作對應的權限，只要直接判斷用戶是否擁有該權限即可，可擴展性強
//判斷用戶是否具有查看權限，用戶的角色可以任意變化，而這條判斷語句始終是可行的
if(user.hasPermission("retrieve")){
//retrieve
}
如果用戶的權限需要改變，只需要對數據庫中用戶的角色對應的權限進行改變，而權限與對應資源通常不會有改變的需求
總結：
不過使用基於資源的方式，仍然是需要角色的，用戶的權限分配的依據往往是角色（比如：如果我給你admin角色，那麼同時也會給你curd的權限）。而進行訪問控制時，則不依賴角色（比如：你想查看 ，那麼我可以直接問你你有retrieve權限嗎？如果有，你就可以訪問。而不關心你是什麼角色）。