建站
咨詢
售后
建站咨詢
新聞中心
權(quán)限管控可以通俗的理解為權(quán)力限制，即不同的人由于擁有不同權(quán)力，他所看到的、能使用的可能不一樣。對應(yīng)到一個應(yīng)用系統(tǒng)，其實就是一個用戶可能擁有不同的數(shù)據(jù)權(quán)限（看到的）和操作權(quán)限（使用的）。
創(chuàng)新互聯(lián)公司2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目網(wǎng)站建設(shè)、網(wǎng)站制作網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元絳縣做網(wǎng)站,已為上家服務(wù),為絳縣各地企業(yè)和個人服務(wù),聯(lián)系電話:18982081108
主流的權(quán)限模型主要分為以下五種：
- ACL模型：訪問控制列表
- DAC模型：自主訪問控制
- MAC模型：強制訪問控制
- ABAC模型：基于屬性的訪問控制
- RBAC模型：基于角色的權(quán)限訪問控制
目前主流的權(quán)限模型是RBAC模型，碼猿慢病云管理系統(tǒng)則是使用RBAC模型進行權(quán)限控制。
關(guān)于以上5種權(quán)限模型在之前一篇文章中詳細介紹過：權(quán)限系統(tǒng)就該這么設(shè)計，yyds
RBAC 基于角色的權(quán)限訪問控制
Role-Based Access Control，核心在于用戶只和角色關(guān)聯(lián)，而角色代表對了權(quán)限，是一系列權(quán)限的集合。
RBAC三要素：
- 用戶：系統(tǒng)中所有的賬戶
- 角色：一系列權(quán)限的集合（如：管理員，開發(fā)者，審計管理員等）
- 權(quán)限：菜單，按鈕，數(shù)據(jù)的增刪改查等詳細權(quán)限。
在RBAC中，權(quán)限與角色相關(guān)聯(lián)，用戶通過成為適當(dāng)角色的成員而得到這些角色的權(quán)限。
角色是為了完成各種工作而創(chuàng)造，用戶則依據(jù)它的責(zé)任和資格來被指派相應(yīng)的角色，用戶可以很容易地從一個角色被指派到另一個角色。
角色可依新的需求和系統(tǒng)的合并而賦予新的權(quán)限，而權(quán)限也可根據(jù)需要而從某角色中回收。角色與角色的關(guān)系同樣也存在繼承關(guān)系防止越權(quán)。
優(yōu)點：便于角色劃分，更靈活的授權(quán)管理；最小顆粒度授權(quán)；
在碼猿慢病云管理系統(tǒng)（醫(yī)療系統(tǒng)）的用戶、角色、權(quán)限代表什么呢？
1. 用戶
這里的用戶和其他系統(tǒng)并無區(qū)別，則是能登錄系統(tǒng)的用戶，對應(yīng)的表為：codepae/sys_user，字段屬性如下：
|
字段 |
類型 |
注釋 |
|
user_id |
bigint |
用戶唯一ID |
|
name |
varchar |
姓名 |
|
gender |
char |
性別，字典 |
|
username |
varchar |
用戶名/賬號 |
|
password |
varchar |
密碼 |
|
dept_id |
bigint |
科室ID |
|
hos_id |
bigint |
醫(yī)院ID |
|
salt |
varchar |
隨機鹽 |
|
phone |
varchar |
手機號 |
|
avatar |
varchar |
頭像 |
|
lock_flag |
char |
0-正常，9-鎖定 |
|
del_flag |
char |
0-正常，1-刪除 |
其中比較重要的字段：
- username：用戶登錄系統(tǒng)的賬號，醫(yī)療系統(tǒng)中則是HIS系統(tǒng)中的工號，(username,hos_id,del_flag)組成唯一索引，同一家醫(yī)院這個賬號必須是唯一
- hos_id：醫(yī)院的ID，多租戶架構(gòu)模式下區(qū)分租戶的字段
- dept_id：科室ID/病區(qū)ID，醫(yī)院中的醫(yī)生、護士是按照科室/病區(qū)管理患者的，因此在入職時就會分配到對應(yīng)的科室/病區(qū)，比如女人的婦科病，去醫(yī)院看病掛的肯定是婦科，這個婦科門診則是有對應(yīng)的醫(yī)生坐診，不可能找個骨科的醫(yī)生去看婦科的毛病
為什么要有科室、病區(qū)這兩個概念？
科室則是平常我們醫(yī)院掛號經(jīng)?？吹降目剖?，比如婦科、骨科、內(nèi)分泌科、心內(nèi)科、心腦血管科等
病區(qū)這個概念是針對住院來說，住過院的應(yīng)該都知道護士照顧病人是通過病區(qū)->病房->床位號定位病人，比如二十病區(qū)->302房間->10號床
醫(yī)院為了病房能夠更好的管理，節(jié)省醫(yī)護的資源，一個病區(qū)中包含多個科室的患者，比如新生兒科、產(chǎn)科、兒科這三個科室你會看到里面的住院患者都是住在同一個病區(qū)，同一批護士管理，比如十病區(qū)。
這樣應(yīng)該就能理解了，大部分的HIS系統(tǒng)中，醫(yī)生是劃分到科室管理，比如婦科，骨科，畢竟術(shù)業(yè)有專攻，護士是按照病區(qū)劃分管理，因為護士本質(zhì)上是照顧病人，打打針等一些工作，專一性不是那么高；因此在sys_user用戶表中的dept_id既能表示科室也能表示病區(qū)了。
PS：一些比較落后的小醫(yī)院，HIS系統(tǒng)比較老舊，醫(yī)生、護士還是按照科室管理
2. 角色
在醫(yī)院中的主要角色則是：醫(yī)生和護士，這個想必大家都能理解
碼猿慢病云管理系統(tǒng)中內(nèi)置了七個角色，已經(jīng)完全夠用了，如下：
圖片
- 管理員：這個是每個醫(yī)院的系統(tǒng)管理員，在添加醫(yī)院的時候會指定一個管理員
- 系統(tǒng)管理員：這個是整個系統(tǒng)的管理員，擁有最高權(quán)限，可以看到所有醫(yī)院的數(shù)據(jù)
- 醫(yī)生：醫(yī)生的角色
- 護士：護士的角色
對應(yīng)數(shù)據(jù)庫：codeape/sys_role，如下：
|
字段 |
類型 |
注釋 |
|
role_id |
bigint |
唯一Id |
|
role_name |
varchar |
角色名稱 |
|
role_code |
varchar |
角色代碼 |
|
role_desc |
varchar |
角色描述 |
|
del_flag |
char |
刪除標(biāo)識：0-正常，1-刪除 |
和用戶通過另外一張表存儲關(guān)聯(lián)關(guān)系：codeape/sys_user_role
|
字段 |
類型 |
注釋 |
|
user_id |
bigint |
用戶唯一ID |
|
role_id |
bigint |
角色唯一ID |
碼猿慢病云管理系統(tǒng)中醫(yī)生和護士這兩個角色的最大區(qū)別：護士需要手持PDA（數(shù)據(jù)采集設(shè)備）采集數(shù)據(jù)(血糖、尿酸、血酮)，添加數(shù)據(jù)等操作，醫(yī)生則是每天查看患者的數(shù)據(jù)為治療提供輔助
3. 權(quán)限
碼猿慢病云管理系統(tǒng)中的權(quán)限有如下三類：
- 菜單的權(quán)限：客戶端菜單的權(quán)限
- 按鈕/接口的權(quán)限：客戶端按鈕/接口的權(quán)限，比如添加患者這個
- 科室/病區(qū)的權(quán)限：
1. 菜單的權(quán)限
控制客戶端的菜單顯示，如下：
圖片
目前有這幾個根菜單+子菜單。
2. 按鈕權(quán)限
客戶端按鈕的權(quán)限，比如新增、刪除、編輯按鈕的權(quán)限，比如住院患者的4個按鈕，如下：
圖片
每個按鈕都有一個權(quán)限標(biāo)識編碼，比如inhos_patinfohot_get，客戶端只需要判斷當(dāng)前登錄用戶的權(quán)限樹中是否存在這個權(quán)限，有則顯示，沒有則不顯示
3. 接口權(quán)限
客戶端的接口權(quán)限和按鈕權(quán)限共用，比如查詢住院患者這個權(quán)限對應(yīng)的標(biāo)識也是：inhos_patinfohot_get
那么這個接口權(quán)限如何控制？碼猿慢病云管理系統(tǒng)中是將接口權(quán)限的鑒權(quán)下沉到各個微服務(wù)，交給開發(fā)者在開發(fā)接口時通過@PreAuthorize注解控制權(quán)限，比如查詢住院患者列表的這個接口，如下：
//com.code.ape.codeape.inhos.controller.PatInfoHotController#getPatInfoHotPage
@Operation(summary = "分頁查詢在院患者", description = "分頁查詢在院患者")
@GetMapping("/page" )
@InjectAuth
@PreAuthorize("@pms.hasPermission('inhos_patinfohot_get')" )
public R> getPatInfoHotPage(Page page, PatInfoDTO dto) {
return R.ok(patInfoHotService.listPage(page,dto));
} @PreAuthorize這個注解是Spring Security內(nèi)置的鑒權(quán)接口，其中的value這個屬性支持SPEL表達式，真實的實現(xiàn)代碼如下：
/**
* @author 公眾號：碼猿技術(shù)專欄 版權(quán)：不才陳某所署，侵權(quán)必究
* {@link com.code.ape.codeape.common.security.component.PermissionService}
*/
public class PermissionService {
/**
* 判斷接口是否有任意xxx，xxx權(quán)限
* @param permissions 權(quán)限
* @return {boolean}
*/
public boolean hasPermission(String... permissions) {
if (ArrayUtil.isEmpty(permissions)) {
return false;
}
//代碼(1)
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
if (authentication == null) {
return false;
}
//代碼(2)
Collection authorities = authentication.getAuthorities();
////代碼(3)
return authorities.stream()
.map(GrantedAuthority::getAuthority)
.filter(StringUtils::hasText)
.anyMatch(x -> PatternMatchUtils.simpleMatch(permissions, x));
}
}邏輯其實很簡單，上述代碼三個部分：
- 代碼(1) ：從Spring Security 上下文中獲取當(dāng)前用戶登錄的身份信息Authentication，其中就包括權(quán)限
- 代碼(2) ：從用戶身份信息Authentication中獲取用戶的權(quán)限樹
- 代碼(3) ：將當(dāng)前登錄用戶的權(quán)限和@PreAuthorize傳入的權(quán)限比較，判斷是否鑒權(quán)通過
4. 科室/病區(qū)權(quán)限
這個權(quán)限則是比較特殊了，先描述一下場景：
在醫(yī)療系統(tǒng)中，醫(yī)生/護士是無權(quán)限查看全部科室的數(shù)據(jù)的，只能查看自己負責(zé)科室/病區(qū)的數(shù)據(jù)，這樣是為了避免醫(yī)療事故；你想想如果有個心懷不軌的醫(yī)生，隨意更改其他科室/病區(qū)患者的數(shù)據(jù)，導(dǎo)致醫(yī)生誤判病情，這樣的責(zé)任誰來承擔(dān)？
所以醫(yī)療系統(tǒng)中都需要控制醫(yī)護科室/病區(qū)這個權(quán)限，這樣才能保證不發(fā)生不必要的醫(yī)療事故。
碼猿慢病云管理系統(tǒng)中的科室/病區(qū)權(quán)限如何控制的呢？
在新增醫(yī)護的時候有個科室權(quán)限的多選器，如下圖：
圖片
這樣就能輕松設(shè)置醫(yī)護的科室/病區(qū)權(quán)限了，這部分對應(yīng)關(guān)系是持久化在codeape/sys_user_dept這張表中，如下：
|
字段 |
類型 |
注釋 |
|
user_id |
bigint |
用戶ID |
|
dept_id |
bigint |
科室/病區(qū)ID |
|
del_flag |
varchar |
刪除標(biāo)志 |
那么此時當(dāng)前醫(yī)護的科室/病區(qū)權(quán)限如何計算呢？
先給答案，分為兩種情況；
第一種：WEB端/PAD端
先說第一種：在WEB端/PAD端，醫(yī)護的權(quán)限=醫(yī)護所在的科室+醫(yī)護的科室權(quán)限+關(guān)聯(lián)科室
什么意思？比如白鹿這個護士，如下圖：
圖片
所屬科室為內(nèi)分泌科，科室權(quán)限為神經(jīng)內(nèi)科+內(nèi)分泌科+心內(nèi)科，那么前面兩層的權(quán)限則是神經(jīng)內(nèi)科+內(nèi)分泌科+心內(nèi)科（注意去重）
那么關(guān)聯(lián)科室什么意思？比如神經(jīng)內(nèi)科下面有個神經(jīng)內(nèi)科病區(qū)，但是醫(yī)護的科室在入職時都設(shè)置在了神經(jīng)內(nèi)科，那么他們?nèi)绾文芸吹缴窠?jīng)內(nèi)科病區(qū)的數(shù)據(jù)呢？
一種方案可以在科室權(quán)限那一欄再加上神經(jīng)內(nèi)科病區(qū)，這種當(dāng)然可行，但是你要為每個醫(yī)護都設(shè)置一遍。
第二種方案：可以將神經(jīng)內(nèi)科和神經(jīng)內(nèi)科病區(qū)關(guān)聯(lián)起來，這樣只要有神經(jīng)內(nèi)科這個權(quán)限，那么就必然有神經(jīng)內(nèi)科病區(qū)這個權(quán)限，這個在碼猿慢病云管理系統(tǒng)中也有設(shè)置關(guān)聯(lián)關(guān)系，如下圖：
圖片
在添加科室的時候可以選擇根節(jié)點科室。
對應(yīng)的關(guān)系持久化在codeape/sys_dept_relation中，結(jié)構(gòu)如下：
|
字段 |
類型 |
注釋 |
|
ancestor |
bigint |
祖先節(jié)點（科室/病區(qū)ID） |
|
descendant |
bigint |
子節(jié)點（科室/病區(qū)ID） |
科室/病區(qū)權(quán)限在用戶登錄時就會查詢出來放到SecurityContext上下文中，具體的方法如下圖：
圖片
那在醫(yī)護查詢數(shù)據(jù)如何去根據(jù)這個科室/病區(qū)權(quán)限過濾呢？
在請求DTO中有個基礎(chǔ)實體類com.code.ape.codeape.common.core.entity.BaseParam，如下：
@Data
public class BaseParam {
/**
* 醫(yī)院Id
*/
private Long hosId;
/**
* 用戶ID
*/
private Long userId;
/**
* 醫(yī)護的科室權(quán)限
*/
private List dataAuth;
/**
* 請求來源客戶端ID
*/
private String clientId;
/**
* 設(shè)備的SN號
*/
private String sn;
} 這個類中的所有屬性都會自動注入，只需要在controller方法中標(biāo)注一個注解：@InjectAuth，如何做到的呢？
@InjectAuth這個注解是通過AOP方式自動注入?yún)?shù)，代碼如下：
@Slf4j
@RequiredArgsConstructor
@Aspect
public class CodeapeInjectAuthAspect implements Ordered {
@SneakyThrows
@Around("@annotation(injectAuth) &&" +
"(@annotation(org.springframework.web.bind.annotation.PostMapping)||" +
"@annotation(org.springframework.web.bind.annotation.GetMapping)||" +
"@annotation(org.springframework.web.bind.annotation.DeleteMapping)||" +
"@annotation(org.springframework.web.bind.annotation.PutMapping)||" +
"@annotation(org.springframework.web.bind.annotation.RequestMapping))")
public Object around(ProceedingJoinPoint joinPoint, InjectAuth injectAuth) {
if (injectAuth.enable()){
CodeapeUser codeapeUser = Objects.requireNonNull(SecurityUtils.getUser());
Object[] args = joinPoint.getArgs();
for (int i = 0; i < args.length; i++) {
if (!(args[i] instanceof BaseParam)) {
continue;
}
BaseParam baseParam = (BaseParam) args[i];
/**
* 1. web端：權(quán)限就是當(dāng)前登錄用戶的權(quán)限
* 2. pda端，權(quán)限則是設(shè)備的權(quán)限+當(dāng)前登錄用戶的權(quán)限
* 這里的權(quán)限取值是token中的deptAuths，這個在登錄的時候就查詢出來，緩存在redis中，所以這里直接用就可以
*/
//醫(yī)院管理員+系統(tǒng)管理員不賦予權(quán)限
boolean flag= ArrayUtil.contains(codeapeUser.getRoleCodes(),SecurityConstants.SYSTEM_ADMIN_CODE)
||ArrayUtil.contains(codeapeUser.getRoleCodes(),SecurityConstants.HOS_ADMIN_CODE);
baseParam.setDataAuth(flag?null:Arrays.asList(codeapeUser.getDeptAuths()));
baseParam.setHosId(codeapeUser.getHosId());
baseParam.setUserId(codeapeUser.getId());
baseParam.setClientId(codeapeUser.getClientId());
baseParam.setSn(codeapeUser.getSn());
}
}
return joinPoint.proceed();
}
@Override
public int getOrder() {
return Ordered.HIGHEST_PRECEDENCE + 4;
}
}直接取的是CodeapeUser中的deptAuths，CodeapeUser則是SecurityContext上下文的用戶身份信息
這樣則能夠取到用戶的科室/病區(qū)權(quán)限，然后則能在SQL中根據(jù)這個dataAuth屬性去過濾數(shù)據(jù)了，比如分頁查詢住院患者的接口，controller方法如下：
com.code.ape.codeape.inhos.controller.PatInfoHotController#getPatInfoHotPage
圖片
圖片
SQL如下：
com.code.ape.codeape.inhos.mapper.PatInfoHotMapper#selectPatInfoPage
圖片
這部分的SQL片段則是根據(jù)住院患者的科室去過濾。
第二種PDA端
這里的PDA指的是護士的手持設(shè)備，這個設(shè)備和智能手機一樣，根據(jù)自己賬號登錄上去，給大家大致畫一下PDA上都有哪些內(nèi)容，如下圖：
圖片
其實就和APP是一樣的，里面可以看到大致四塊內(nèi)容（當(dāng)然還有其他)：
- 患者管理：這個是顯示所有的住院患者，護士可以選擇對應(yīng)的患者進行數(shù)據(jù)采集，這樣采集的數(shù)據(jù)才能和患者自定綁定
- 檢測任務(wù)：這個則是醫(yī)生下的醫(yī)囑任務(wù)，按照時間段顯示，比如醫(yī)生下的三餐前后測血糖這個醫(yī)囑任務(wù)，則經(jīng)過護士拆分后，則變成了6個子任務(wù)：空腹測血糖、早餐后測血糖、午餐前測血糖、午餐后測血糖、晚餐前測血糖、晚餐后測血糖。那么在每個時間段顯示要測血糖的患者床位即可，護士選擇對應(yīng)的床位則可以測血糖
- 檢測記錄：這里是展示所有患者測量的血糖數(shù)據(jù)，按照時間段表格形式的展示
- 質(zhì)控：這個則是設(shè)備的質(zhì)控，護士每天要定時對設(shè)備進行質(zhì)控(質(zhì)量檢測)，查看這臺設(shè)備測量是否準(zhǔn)確
那么問題來了，PDA上需要顯示的數(shù)據(jù)是整個醫(yī)院的數(shù)據(jù)嗎？顯然不可能，也是需要根據(jù)護士科室/病區(qū)權(quán)限過濾，可以看到上方有一個科室的篩選項，默認是所有科室，則是當(dāng)前登錄用戶的所有科室權(quán)限
那么PDA端的醫(yī)護權(quán)限和WEB端一樣嗎？
當(dāng)然不是，因為設(shè)備存在以下兩種網(wǎng)絡(luò)情況：
- 在線：連上wifi或者SIM卡，這樣能夠時刻保持網(wǎng)絡(luò)暢通的情況下，屬于在線狀態(tài)，拉數(shù)據(jù)/上傳數(shù)據(jù)直接訪問服務(wù)端即可
- 離線：有些醫(yī)院沒有內(nèi)網(wǎng)的wifi或者SIM卡，只能連有線網(wǎng)絡(luò)，一旦設(shè)備拔掉網(wǎng)線去病房檢測，則是離線的狀態(tài)
離線情況下就需要設(shè)備本地做緩存了，那么這個緩存的數(shù)據(jù)到底拉哪些數(shù)據(jù)？不可能將整個醫(yī)院的數(shù)據(jù)都拉下來，設(shè)備的內(nèi)存是有限的。這個時候就需要用到設(shè)備的權(quán)限了，在添加設(shè)備的時候有兩個的選項，如下：
圖片
科室和關(guān)聯(lián)科室這兩個選項，一般一臺設(shè)備只供一個病區(qū)使用，此時將科室選項選擇對應(yīng)的病區(qū)即可，那么特殊情況下，比如一病區(qū)和二病區(qū)共用一臺設(shè)備，此時就需要用到關(guān)聯(lián)科室了。
此時應(yīng)該明白了設(shè)備的權(quán)限=科室+關(guān)聯(lián)科室
只要設(shè)備連上網(wǎng)絡(luò)，在用戶不登錄的情況下，調(diào)用接口獲取數(shù)據(jù)的時候就應(yīng)該獲取的是設(shè)備權(quán)限的數(shù)據(jù)。
那登錄該臺設(shè)備的用戶權(quán)限呢？應(yīng)該怎么取值呢？很簡單，分為兩種情況：
- 用戶的權(quán)限和設(shè)備的權(quán)限取并集
- 用戶的權(quán)限和設(shè)備的權(quán)限取交集
按照正常的邏輯是應(yīng)該是第二種情況取交集，因為你護士沒有這個權(quán)限就不應(yīng)該看到該科室/病區(qū)的數(shù)據(jù)，但是實際情況是很多醫(yī)院的護士都是輪轉(zhuǎn)的，比如這個月到一病區(qū)，下個月到二病區(qū)，他們的科室/病區(qū)權(quán)限的維護并不是很及時，主要是信息科的人員太懶了，這樣的話就會導(dǎo)致如果按照第二種情況取交集，那么這個護士登錄該臺設(shè)備就看不到自己所管的科室/病區(qū)的數(shù)據(jù)了。所以在碼猿慢病云管理系統(tǒng)中是采用的第一種方案。
相關(guān)代碼在com.code.ape.codeape.common.security.service.CodeapePDAUserDetailsServiceImpl#getUserDetails，如下圖：
圖片
總結(jié)
這節(jié)內(nèi)容介紹了RBAC權(quán)限模型以及碼猿慢病云管理系統(tǒng)中權(quán)限是如何設(shè)計的，最重要的是科室/病區(qū)權(quán)限的設(shè)計，大家一定要理解其中的邏輯，幾乎所有的醫(yī)療系統(tǒng)都是按照這個邏輯處理的。
本節(jié)內(nèi)容摘錄了部分代碼，關(guān)于代碼的詳細介紹會在后面文章中介紹，現(xiàn)在先了解一下。
標(biāo)題名稱：醫(yī)療系統(tǒng)的權(quán)限就該這樣設(shè)計，穩(wěn)！
文章路徑：http://m.fisionsoft.com.cn/article/cocgggp.html
