TienChin 項(xiàng)目中的 RBAC 是怎么玩的？
這篇文章最后留下來一個(gè)問題，就是用戶的權(quán)限該如何設(shè)置？今天我們就來聊聊這個(gè)話題。
1. 角色與權(quán)限
首先我們先來看看角色與權(quán)限，該如何設(shè)計(jì)角色與權(quán)限，其實(shí)有很多非常成熟的理論，最為常見的莫過于 RBAC 了。
1.1 RBAC 簡(jiǎn)介
RBAC（Role-based access control）是一種以角色為基礎(chǔ)的訪問控制（Role-based access control，RBAC），它是一種較新且廣為使用的權(quán)限控制機(jī)制，這種機(jī)制不是直接給用戶賦予權(quán)限，而是將權(quán)限賦予角色。
RBAC 權(quán)限模型將用戶按角色進(jìn)行歸類，通過用戶的角色來確定用戶對(duì)某項(xiàng)資源是否具備操作權(quán)限。RBAC 簡(jiǎn)化了用戶與權(quán)限的管理，它將用戶與角色關(guān)聯(lián)、角色與權(quán)限關(guān)聯(lián)、權(quán)限與資源關(guān)聯(lián)，這種模式使得用戶的授權(quán)管理變得非常簡(jiǎn)單和易于維護(hù)。
1.2 RBAC 的提出
權(quán)限、角色這些東西，在早期 1970 年代的商業(yè)計(jì)算機(jī)程序中就可以找到相關(guān)的應(yīng)用，但是早期的程序相對(duì)簡(jiǎn)單，而且并不存在一個(gè)明確的、通用的、公認(rèn)的權(quán)限管理模型。
Ferraiolo 和 Kuhn 兩位大佬于 1992 年提出了一種基于通用角色的訪問控制模型（看來這個(gè)模型比松哥年齡還大），首次提出了 RBAC 權(quán)限模型用來代替?zhèn)鹘y(tǒng)的 MAC 和 DAC 兩種權(quán)限控制方案，并且就 RBAC 中的相關(guān)概念給出了解釋。
Ferraiolo，Cugini 和 Kuhn 于 1995 年擴(kuò)展了 1992 年提出的權(quán)限模型。該模型的主要功能是所有訪問都是通過角色進(jìn)行的，而角色本質(zhì)上是權(quán)限的集合，并且所有用戶只能通過角色獲得權(quán)限。在組織內(nèi)，角色相對(duì)穩(wěn)定，而用戶和權(quán)限都很多，并且可能會(huì)迅速變化。因此，通過角色控制權(quán)限可以簡(jiǎn)化訪問控制的管理和檢查。
到了 1996 年，Sandhu，Coyne，F(xiàn)einstein 和 Youman 正式提出了 RBAC 模型，該模型以模塊化方式細(xì)化了 RBAC，并提出了基于該理論的 RBAC0-RBAC3 四種不同模型。
今天，大多數(shù)信息技術(shù)供應(yīng)商已將 RBAC 納入其產(chǎn)品線，除了常規(guī)的企業(yè)級(jí)應(yīng)用，RBAC 也廣泛應(yīng)用在醫(yī)療、國(guó)防等領(lǐng)域。
目前網(wǎng)上關(guān)于 RBAC 理論性的東西松哥只找到英文的，感興趣的小伙伴可以看下，地址是：
https://csrc.nist.gov/projects/Role-Based-Access-Control
如果小伙伴們有中文的資料鏈接，歡迎留言說明。
1.3 RBAC 三原則
- 最小權(quán)限：給角色配置的權(quán)限是其完成任務(wù)所需要的最小權(quán)限集合。
- 責(zé)任分離：通過相互獨(dú)立互斥的角色來共同完成任務(wù)。
- 數(shù)據(jù)抽象：通過權(quán)限的抽象來體現(xiàn)，RBAC 支持的數(shù)據(jù)抽象程度與 RBAC 的實(shí)現(xiàn)細(xì)節(jié)有關(guān)。
數(shù)據(jù)抽象：通過權(quán)限的抽象來體現(xiàn)，RBAC 支持的數(shù)據(jù)抽象程度與 RBAC 的實(shí)現(xiàn)細(xì)節(jié)有關(guān)。
1.4 RBAC 模型分類
1.4.1 RBAC0
RBAC0 是最簡(jiǎn)單的用戶、角色、權(quán)限模型。RBAC0 是 RBAC 權(quán)限模型中最核心的一部分，后面其他模型都是在此基礎(chǔ)上建立。
在 RBAC0 中，一個(gè)用戶可以具備多個(gè)角色，一個(gè)角色可以具備多個(gè)權(quán)限，最終用戶所具備的權(quán)限是用戶所具備的角色的權(quán)限并集。
1.4.2 RBAC1
RBAC1 則是在 RABC0 的基礎(chǔ)上引入了角色繼承，讓角色有了上下級(jí)關(guān)系。
在本系列前面的文章中，松哥也曾多次向大家介紹過 Spring Security 中的角色繼承。
1.4.3 RBAC2
RBAC2 也是在 RBAC0 的基礎(chǔ)上進(jìn)行擴(kuò)展，引入了靜態(tài)職責(zé)分離和動(dòng)態(tài)職責(zé)分離。
要理解職責(zé)分離，我們得先明白角色互斥。
在實(shí)際項(xiàng)目中，有一些角色是互斥的，對(duì)立的，例如財(cái)務(wù)這個(gè)角色一般是不能和其他角色兼任的，否則自己報(bào)賬自己審批，豈不是爽歪歪！
通過職責(zé)分離可以解決這個(gè)問題：
靜態(tài)職責(zé)分離
在設(shè)置階段就做好了限制。比如同一用戶不能授予互斥的角色，用戶只能有有限個(gè)角色，用戶獲得高級(jí)權(quán)限之前要有低級(jí)權(quán)限等等。
動(dòng)態(tài)職責(zé)分離
在運(yùn)行階段進(jìn)行限制。比如運(yùn)行時(shí)同一用戶下5個(gè)角色中只能同時(shí)有2個(gè)角色激活等等。
1.4.4 RBAC3
將 RBAC1 和 RBAC2 結(jié)合起來，就形成了 RBAC3。
1.5 擴(kuò)展
我們?nèi)粘Ｒ姷降暮芏鄼?quán)限模型都是在 RBAC 的基礎(chǔ)上擴(kuò)展出來的。
例如在有的系統(tǒng)中我們可以見到用戶組的概念，就是將用戶分組，用戶同時(shí)具備自身的角色以及分組的角色。
我們 TienChin 項(xiàng)目所用的腳手架中的權(quán)限，就基本上是按照 RBAC 這套權(quán)限模型來的。
2. 表設(shè)計(jì)
我們來看下 RuoYi-Vue 腳手架中跟用戶、角色以及權(quán)限相關(guān)的表。
這里主要涉及到如下幾張表：
- sys_user：這個(gè)是用戶表。
- sys_role：這個(gè)是角色表。
- sys_user_role：這個(gè)是用戶角色關(guān)聯(lián)表。
- sys_menu：這個(gè)是菜單表，也可以理解為是資源表。
- sys_role_menu：這個(gè)是資源角色關(guān)聯(lián)表。
通過用戶的 id，可以去 sys_user_role? 表中查詢到這個(gè)用戶具備的角色 id，再根據(jù)角色 id，去 sys_role_menu? 表中查詢到這個(gè)角色可以操作的資源 id，再根據(jù)資源 id，去 sys_menu 表中查詢到對(duì)應(yīng)的資源，基本上就是這個(gè)樣一個(gè)流程。
那么 Java 代碼中該怎么做呢？
3. 代碼實(shí)現(xiàn)
首先定義了一個(gè) Java 類 SysUser，這個(gè)跟數(shù)據(jù)庫(kù)中的 sys_user? 表是對(duì)應(yīng)的，我們來看 UserDetailsService 的具體實(shí)現(xiàn)：
@Service
public class UserDetailsServiceImpl implements UserDetailsService {
private static final Logger log = LoggerFactory.getLogger(UserDetailsServiceImpl.class);
@Autowired
private ISysUserService userService;
@Autowired
private SysPermissionService permissionService;
@Override
public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
SysUser user = userService.selectUserByUserName(username);
if (StringUtils.isNull(user)) {
log.info("登錄用戶：{} 不存在.", username);
throw new ServiceException("登錄用戶：" + username + " 不存在");
} else if (UserStatus.DELETED.getCode().equals(user.getDelFlag())) {
log.info("登錄用戶：{} 已被刪除.", username);
throw new ServiceException("對(duì)不起，您的賬號(hào)：" + username + " 已被刪除");
} else if (UserStatus.DISABLE.getCode().equals(user.getStatus())) {
log.info("登錄用戶：{} 已被停用.", username);
throw new ServiceException("對(duì)不起，您的賬號(hào)：" + username + " 已停用");
}
return createLoginUser(user);
}
public UserDetails createLoginUser(SysUser user) {
return new LoginUser(user.getUserId(), user.getDeptId(), user, permissionService.getMenuPermission(user));
}
}
從數(shù)據(jù)庫(kù)中查詢到的就是 SysUser 對(duì)象，然后對(duì)該對(duì)象稍作改造，將之改造成為一個(gè) LoginUser 對(duì)象，這個(gè) LoginUser 則是 UserDetails 接口的實(shí)現(xiàn)類，里邊保存了當(dāng)前登錄用戶的關(guān)鍵信息。
在創(chuàng)建 LoginUser 對(duì)象的時(shí)候，有一個(gè) permissionService.getMenuPermission 方法用來查詢用戶的權(quán)限，根據(jù)當(dāng)前用戶的 id，查詢到用戶的角色，再根據(jù)用戶角色，查詢到用戶的權(quán)限，另外，如果當(dāng)前用戶的角色是 admin，那么就設(shè)置用戶角色為 *:*:*，這是一段硬編碼。
我們?cè)賮砜纯?LoginUser 的設(shè)計(jì)：
public class LoginUser implements UserDetails {
/**
* 權(quán)限列表
*/
private Set<String> permissions;
/**
* 用戶信息
*/
private SysUser user;
public LoginUser(Long userId, Long deptId, SysUser user, Set<String> permissions) {
this.userId = userId;
this.deptId = deptId;
this.user = user;
this.permissions = permissions;
}
@JSONField(serialize = false)
@Override
public String getPassword() {
return user.getPassword();
}
@Override
public String getUsername() {
return user.getUserName();
}
/**
* 賬戶是否未過期,過期無法驗(yàn)證
*/
@JSONField(serialize = false)
@Override
public boolean isAccountNonExpired() {
return true;
}
/**
* 指定用戶是否解鎖,鎖定的用戶無法進(jìn)行身份驗(yàn)證
*
* @return
*/
@JSONField(serialize = false)
@Override
public boolean isAccountNonLocked() {
return true;
}
/**
* 指示是否已過期的用戶的憑據(jù)(密碼),過期的憑據(jù)防止認(rèn)證
*
* @return
*/
@JSONField(serialize = false)
@Override
public boolean isCredentialsNonExpired() {
return true;
}
/**
* 是否可用 ,禁用的用戶不能身份驗(yàn)證
*
* @return
*/
@JSONField(serialize = false)
@Override
public boolean isEnabled() {
return true;
}
@Override
public Collection<? extends GrantedAuthority> getAuthorities() {
return null;
}
}
有一些屬性我省略掉了，大家可以文末下載源碼查看。
小伙伴們看到，這個(gè) LoginUser 實(shí)現(xiàn)了 UserDetails 接口，但是和 vhr 中有一個(gè)很大的不同，就是這里沒有處理 getAuthorities 方法，也就是說當(dāng)系統(tǒng)想要去獲取用戶權(quán)限的時(shí)候，二話不說直接返回一個(gè) null。這是咋回事呢？
因?yàn)樵谶@個(gè)腳手架中，將來進(jìn)行權(quán)限校驗(yàn)的時(shí)候，是按照下面這樣來的：
@PreAuthorize("@ss.hasPermi('system:menu:add')")
@PostMapping
public AjaxResult add(@Validated @RequestBody SysMenu menu) {
//省略
}
@PreAuthorize 注解中的 @ss.hasPermi('system:menu:add')? 表達(dá)式，表示調(diào)用 Spring 容器中一個(gè)名為 ss 的 Bean 的 hasPermi 方法，去判斷當(dāng)前用戶是否具備一個(gè)名為 system:menu:add 的權(quán)限。一個(gè)名為 ss 的 Bean 的 hasPermi 方法如下：
@Service("ss")
public class PermissionService {
/**
* 所有權(quán)限標(biāo)識(shí)
*/
private static final String ALL_PERMISSION = "*:*:*";
/**
* 管理員角色權(quán)限標(biāo)識(shí)
*/
private static final String SUPER_ADMIN = "admin";
private static final String ROLE_DELIMETER = ",";
private static final String PERMISSION_DELIMETER = ",";
/**
* 驗(yàn)證用戶是否具備某權(quán)限
*
* @param permission 權(quán)限字符串
* @return 用戶是否具備某權(quán)限
*/
public boolean hasPermi(String permission) {
if (StringUtils.isEmpty(permission)) {
return false;
}
LoginUser loginUser = SecurityUtils.getLoginUser();
if (StringUtils.isNull(loginUser) || CollectionUtils.isEmpty(loginUser.getPermissions())) {
return false;
}
return hasPermissions(loginUser.getPermissions(), permission);
}
/**
* 判斷是否包含權(quán)限
*
* @param permissions 權(quán)限列表
* @param permission 權(quán)限字符串
* @return 用戶是否具備某權(quán)限
*/
private boolean hasPermissions(Set<String> permissions, String permission) {
return permissions.contains(ALL_PERMISSION) || permissions.contains(StringUtils.trim(permission));
}
}
由于這里是純手工操作，在比較的時(shí)候，直接獲取到當(dāng)前登錄用戶對(duì)象 LoginUser，再手動(dòng)調(diào)用他的 hasPermissions 方法去判斷權(quán)限是否滿足，由于都是自定義操作，所以是否實(shí)現(xiàn) UserDetails#getAuthorities 方法已經(jīng)不重要了，不過按照這里的比對(duì)方案，是不支持通配符的比對(duì)的。
例如用戶具備針對(duì)字典表的所有操作權(quán)限，表示為 system:dict:*?，但是當(dāng)和 system:dict:list 進(jìn)行比較的時(shí)候，發(fā)現(xiàn)比較結(jié)果為 false，這塊想要比對(duì)成功也是可以的，例如可以通過正則表達(dá)式或者其他方式來操作，反正都是字符串比較，相信大家都能自己搞得定。
現(xiàn)在，前端提供操作頁(yè)面，也可以配置每一個(gè)用戶的角色，也可以配置每一個(gè)角色可以操作的權(quán)限就行了，這個(gè)就比較簡(jiǎn)單了，不多說。
