中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)語(yǔ)：用戶權(quán)限體系的搭建，是許多系統(tǒng)建設(shè)的基礎(chǔ)，尤其是在B端產(chǎn)品設(shè)計(jì)中都會(huì)涉及到這一功能模塊。那么我們?cè)撊绾螐牧汩_始著手搭建用戶體系？作者總結(jié)了相關(guān)步驟，希望能夠給你帶來(lái)一個(gè)全局性的認(rèn)識(shí)，做到心中有數(shù)。

搭建用戶權(quán)限體系，是很多系統(tǒng)建設(shè)的基礎(chǔ)，特別是很多B端產(chǎn)品都會(huì)涉及到這一功能模塊。那么我們?nèi)绾螐牧汩_始著手這件事呢？

下面的內(nèi)容希望能帶給你一個(gè)全局性的認(rèn)識(shí)，即使是之前從來(lái)沒(méi)有涉及過(guò)的小白，也能幫助你做到心中有數(shù)。

一、系統(tǒng)資源

用戶權(quán)限管理是一種對(duì)系統(tǒng)資源的訪問(wèn)控制，那么系統(tǒng)有什么樣的資源需要進(jìn)行權(quán)限分配呢？有3類：

1．菜單

菜單的授權(quán)意味著用戶可以使用該菜單下相關(guān)的功能。屬于高層級(jí)的授權(quán)。

2．操作

增刪改查的權(quán)限控制，有的角色只能看不能改，有的角色具有增刪改查全部權(quán)限。

3．?dāng)?shù)據(jù)

數(shù)據(jù)的權(quán)限控制，不同角色看到的數(shù)據(jù)范圍不同，有的角色只能看到基礎(chǔ)數(shù)據(jù)，有的角色能看到全部數(shù)據(jù)。

二、分配方式

了解了系統(tǒng)有哪些需要進(jìn)行權(quán)限分配的資源后，接下來(lái)面臨的問(wèn)題是：系統(tǒng)有很多的用戶，也有很多的資源，那么怎么實(shí)現(xiàn)給每一個(gè)用戶分配好合適的權(quán)限呢？有兩種實(shí)現(xiàn)路徑：

1．直接分配，即ACL模型

給每一個(gè)用戶直接進(jìn)行權(quán)限的逐一分配。

這種方式的好處是非常靈活，能最大化滿足每個(gè)用戶對(duì)于權(quán)限的個(gè)性化需求。

缺點(diǎn)也顯而易見，那就是不便于操作，權(quán)限的分配與管理效率比較低。

權(quán)限管理人員需要對(duì)系統(tǒng)有深入的了解，如果管理層級(jí)比較多時(shí)，系統(tǒng)的權(quán)限分配與管理無(wú)法大規(guī)模下放和向下有效分散，容易產(chǎn)生高層級(jí)管理人員覺(jué)得工作量大、基層人員覺(jué)得不能自主操控不方便等問(wèn)題。

2．基于角色進(jìn)行權(quán)限分配，即RBAC模型

這是一種間接分配方式，在用戶集合和權(quán)限集合之間建立一個(gè)角色集合，用戶通過(guò)角色與權(quán)限進(jìn)行關(guān)聯(lián)，形成“用戶-角色-權(quán)限”的授權(quán)模型。

這種方式的好處是不必在每次給用戶分配權(quán)限時(shí)都把系統(tǒng)所有的資源分配一遍，只要分配用戶相應(yīng)的角色即可，用戶就擁有了這些角色所關(guān)聯(lián)的權(quán)限。

而且角色的權(quán)限變更比用戶的權(quán)限變更要少得多，也能實(shí)現(xiàn)權(quán)限的動(dòng)態(tài)管理，即當(dāng)角色的權(quán)限發(fā)生了變化以后，所有擁有該角色的用戶也同時(shí)更新了權(quán)限狀態(tài)。

下面重點(diǎn)來(lái)介紹一下RBAC模型。

在RBAC模型中，用戶是真實(shí)的，而角色是我們?yōu)榱朔奖愎芾頇?quán)限集合而虛擬出來(lái)的。本質(zhì)上，角色是一組權(quán)限的集合。

RBAC模型又可以分為RBAC0、RBAC1、RBAC2、RBAC3。

RBAC0：基本模型。用戶和角色可以是一對(duì)一，也可以是多對(duì)對(duì)，一個(gè)用戶擁有的權(quán)限是他所有角色的集合。

RBAC1：角色分層模型。RBAC1是在RBAC0的基礎(chǔ)上增加角色分層，引入了繼承概念。將角色分成多個(gè)等級(jí)，等級(jí)高的角色可以繼承等級(jí)低的所有權(quán)限。

如某個(gè)部門，有助理工程師和工程師，助理工程師的權(quán)限不能大于工程師。如果采用RBAC0，極有可能出現(xiàn)權(quán)限分配失誤，最終出現(xiàn)助理工程師擁有工程師都沒(méi)有的權(quán)限的情況。

RBAC1很好地解決了這個(gè)問(wèn)題，創(chuàng)建完助理工程師的角色并配置好權(quán)限后，工程師的角色繼承助理工程師的權(quán)限并且增加特有的權(quán)限即可。

RBAC2：角色限制模型。RBAC2是在RBAC0的基礎(chǔ)上增加了對(duì)角色的一些限制，包含角色互斥、基數(shù)約束、先決條件、運(yùn)行時(shí)互斥。

• 角色互斥：一個(gè)用戶不能同時(shí)擁有互斥的兩個(gè)或多個(gè)角色。如財(cái)務(wù)系統(tǒng)中，一個(gè)用戶不能同時(shí)擁有會(huì)計(jì)員角色和審核員角色。
• 基數(shù)約束：一個(gè)角色被分配的用戶數(shù)量是有限制的，不能無(wú)限地添加，即有多少用戶能夠擁有這個(gè)角色。如一個(gè)角色是為CEO創(chuàng)建的，那么這個(gè)角色的數(shù)量是有限的。
• 先決條件：想要獲得更高權(quán)限時(shí)，首先需要獲得低一級(jí)的權(quán)限。如先有助理工程師的權(quán)限，才能有工程師的權(quán)限。
• 運(yùn)行時(shí)互斥：一個(gè)用戶允許具有兩個(gè)角色，但在運(yùn)行時(shí)不可同時(shí)激活這兩個(gè)角色，如家長(zhǎng)和老師，一個(gè)用戶可能既是家長(zhǎng)又是老師，但在使用系統(tǒng)時(shí)，只能選擇一個(gè)角色。

RBAC3：統(tǒng)一模型。RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分層，也可以增加各種限制。

基于RBAC的延展。了解完RBAC模型本身以后，我們還需要了解一組與之相關(guān)的概念：用戶組、角色組、權(quán)限組。這3個(gè)概念的出現(xiàn)都是為了方便管理。

用戶組：用戶組是用戶的集合。

如果用戶數(shù)量比較龐大，可以給用戶分組，分好組以后可以給用戶組分配權(quán)限，這樣這個(gè)用戶組下的每一個(gè)用戶擁有的權(quán)限=用戶個(gè)人擁有的權(quán)限+該用戶組擁有的權(quán)限。以后加入更多的用戶，就自動(dòng)擁有了用戶組的權(quán)限，不用再一一進(jìn)行設(shè)置了。

角色組：角色組是角色的集合。

有時(shí)多個(gè)角色針對(duì)某一部分系統(tǒng)資源擁有相同的權(quán)限，如經(jīng)理、技術(shù)人員、銷售人員這些角色，對(duì)同一類文件擁有相同的權(quán)限，這時(shí)就可以為這些角色建立一個(gè)角色組，把權(quán)限賦予這個(gè)角色組，這樣這些角色就都擁有了權(quán)限。

權(quán)限組：權(quán)限組是權(quán)限的集合。

權(quán)限之間有時(shí)是相關(guān)聯(lián)的，這時(shí)就可以為這些關(guān)聯(lián)的權(quán)限設(shè)置一個(gè)權(quán)限組，當(dāng)授權(quán)時(shí)就可以把權(quán)限組賦予某個(gè)角色/角色組，就不需要再一一去設(shè)置了。如當(dāng)我們視頻通話時(shí)，需要同時(shí)具有相機(jī)和麥克風(fēng)的權(quán)限。

三、角色定義

在了解完RBAC模型以后我們會(huì)發(fā)現(xiàn)，在RBAC模型中角色是關(guān)鍵。為了對(duì)許多擁有相似權(quán)限的用戶進(jìn)行分類管理，我們抽象出角色的概念。那么我們?nèi)绾蝸?lái)定義角色呢？

角色是基于業(yè)務(wù)來(lái)定義，而不是依據(jù)行政關(guān)系。如雙人復(fù)核類業(yè)務(wù)，用戶A在一次業(yè)務(wù)過(guò)程中扮演操作員角色，用戶B扮演復(fù)核員角色。而在下一次業(yè)務(wù)過(guò)程中，用戶B扮演操作員角色，用戶A扮演復(fù)核員角色。這樣的角色定義完全是基于業(yè)務(wù)上的需要，而與用戶A和B的行政關(guān)系沒(méi)有任何關(guān)系。

我們?cè)谶M(jìn)行角色定義時(shí)，可能會(huì)對(duì)角色的顆粒度產(chǎn)生迷惑，不知道該范圍大一些包含的內(nèi)容多一些還是應(yīng)該范圍小一些包含的內(nèi)容少一些。

如一個(gè)用戶涉及A、B、C三項(xiàng)業(yè)務(wù)，那么我是應(yīng)該定義一個(gè)角色完成A、B、C三項(xiàng)業(yè)務(wù)的范圍還是應(yīng)該定義兩個(gè)角色分別完成A、B業(yè)務(wù)和C業(yè)務(wù)呢？甚至定義三個(gè)角色分別完成A業(yè)務(wù)、B業(yè)務(wù)和C業(yè)務(wù)呢？

這時(shí)有人可能會(huì)說(shuō)取決于ABC三項(xiàng)業(yè)務(wù)的關(guān)聯(lián)性，實(shí)際上這個(gè)問(wèn)題與業(yè)務(wù)的關(guān)聯(lián)性沒(méi)有關(guān)系。因?yàn)槿绻窍嚓P(guān)聯(lián)的業(yè)務(wù)那么必然會(huì)一起授權(quán)不可分割，如果是不相關(guān)的業(yè)務(wù)但是所有用戶都是一起使用，那么也應(yīng)該一起授權(quán)。

那么我們?cè)趺磁袛嗄兀科鋵?shí)上面的例子和問(wèn)題是走入了一個(gè)本末倒置的誤區(qū)，從業(yè)務(wù)來(lái)歸類用戶了，方向上反了。前面我們說(shuō)過(guò)，角色是擁有相似權(quán)限的用戶抽象。

所以梳理角色的時(shí)候分析用戶本身就可以了，歸類出每類有相似權(quán)限的用戶然后抽象成一個(gè)個(gè)角色。

用戶權(quán)限體系對(duì)于整個(gè)功能體系具有蝴蝶效應(yīng)，一點(diǎn)點(diǎn)小的差異/差錯(cuò)到了最上層的功能和使用層面會(huì)放大很多倍。而且一旦需要修改會(huì)很麻煩，所以我們需要特別小心。

四、前端展現(xiàn)方式

如果一個(gè)用戶有多個(gè)角色，那么在前端功能層面我們?cè)撊绾翁幚砟兀坑袃煞N方案：

1. 角色切換：當(dāng)一個(gè)用戶有多個(gè)角色時(shí)，前端僅展現(xiàn)當(dāng)前角色的相關(guān)功能，用戶需要切換角色去使用對(duì)應(yīng)的功能。
2. 統(tǒng)一展現(xiàn)：當(dāng)一個(gè)用戶有多個(gè)角色時(shí)，前端展現(xiàn)該用戶所有角色的功能的全集，用戶不再需要切換角色。

那么我們?cè)谶@兩種方案之間，該如何選擇呢？我們需要判斷用戶所擁有角色之間的關(guān)系。

一般來(lái)說(shuō)，如果角色之間存在運(yùn)行時(shí)互斥的情況，那么需要選擇角色切換方案，如前面提到的家長(zhǎng)和老師，一個(gè)用戶不可能在同一時(shí)間既是家長(zhǎng)角色又是老師角色，所以需要切換角色去使用對(duì)應(yīng)的功能。

再比如求職者和招聘者，一個(gè)用戶不可能同時(shí)使用求職者和招聘者的功能。除此以外，其他情況都可以選擇統(tǒng)一展現(xiàn)方案。

這里需要我們注意一點(diǎn)，如果你的系統(tǒng)有很多功能，一個(gè)用戶的運(yùn)行時(shí)互斥角色只涉及到部分功能模塊，那么角色切換可以只局限于局部，不必全局都進(jìn)行角色切換。

五、建議

1. 依據(jù)現(xiàn)實(shí)情況建立

依據(jù)現(xiàn)實(shí)情況已經(jīng)抽象形成的角色，最能貼合現(xiàn)實(shí)情況，能最大限度地滿足現(xiàn)實(shí)需要。除此以外，使用現(xiàn)實(shí)情況中的角色定義符合普遍認(rèn)知，避免“語(yǔ)言障礙”。

2. 最大化滿足個(gè)性化需要

需要進(jìn)行權(quán)限管理的系統(tǒng)，所涉及的業(yè)務(wù)特點(diǎn)、人員管理差異常常比較大，情況復(fù)雜，盡可能滿足個(gè)性化配置可以兼容各種現(xiàn)實(shí)情況。

作者：厚厚（微信公眾號(hào)：厚厚的語(yǔ)和文），多年互聯(lián)網(wǎng)和傳統(tǒng)企業(yè)的跨界產(chǎn)品經(jīng)理。

本文由 @厚厚 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自 Unsplash，基于 CC0 協(xié)議