作者：PioneerYi 

來源：juejin.im/post/6850037267554287629

一個(gè)系統(tǒng)，如果沒有安全控制，是十分危險(xiǎn)的，一般安全控制包括身份認(rèn)證和權(quán)限管理。用戶訪問時(shí)，首先需要查看此用戶是否是合法用戶，然后檢查此用戶可以對(duì)那些資源進(jìn)行何種操作，最終做到安全訪問。身份認(rèn)證的方式有很多種，最簡(jiǎn)單的就是直接用戶名密碼，還有業(yè)內(nèi)比較通用的方式CAS方式登陸等；授權(quán)的框架也很多，比如OAuth2，Shiro等。本文首先會(huì)講解一下CAS的概念，以及基于角色的權(quán)限管理模型（RBAC）的概念，接著進(jìn)行數(shù)據(jù)表的設(shè)計(jì)，最后講解如何利用Shiro進(jìn)行權(quán)限管理。

一、CAS身份認(rèn)證

集中式認(rèn)證服務(wù)（英語：Central Authentication Service，縮寫CAS）是一種針對(duì)萬維網(wǎng)的單點(diǎn)登錄協(xié)議。它的目的是允許一個(gè)用戶訪問多個(gè)應(yīng)用程序，而只需提供一次憑證。

1.1、名詞概念

CAS的核心就是其Ticket，及其在Ticket之上的一系列處理操作。CAS的主要票據(jù)有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0(基礎(chǔ)模式)協(xié)議中就有的票據(jù)，PGT、PGTIOU、PT是CAS2.0(代理模式)協(xié)議中有的票據(jù)。這些票據(jù)誰生成得了？肯定是有相關(guān)服務(wù)的，主要服務(wù)有：KDC，AS，TGS。兩者媒介肯定也是有的：TGC。

1.1.1、CAS的Ticket

1）TGT（Ticket Granting Tieckt）

TGT是CAS（具體為 KDC 的 AS 發(fā)放）為用戶簽發(fā)的登錄票據(jù)，擁有了TGT，用戶就可以證明自己在CAS成功登錄過。TGT封裝了Cookie值以及此Cookie值對(duì)應(yīng)的用戶信息。用戶在CAS認(rèn)證成功后，CAS生成cookie，寫入瀏覽器，同時(shí)生成一個(gè)TGT對(duì)象，放入自己的緩存，TGT對(duì)象的ID就是cookie的值。當(dāng)HTTP再次請(qǐng)求到來時(shí)，如果傳過來的有CAS生成的cookie，則CAS以此cookie值為key查詢緩存中有無TGT ，如果有的話，則說明用戶之前登錄過，如果沒有，則用戶需要重新登錄。

簡(jiǎn)而言之，即獲取這樣一張票據(jù)后，以后申請(qǐng)各種其他服務(wù)票據(jù) (ST) 便不必再向 KDC 提交身份認(rèn)證信息 ( 準(zhǔn)確術(shù)語是 Credentials) 。

2）ST（Service ticket）

ST是CAS（由 KDC 的 TGS 發(fā)放）為用戶簽發(fā)的訪問某一service的票據(jù)。

用戶訪問service時(shí)，service發(fā)現(xiàn)用戶沒有ST，則要求用戶去CAS獲取ST。用戶向CAS發(fā)出獲取ST的請(qǐng)求，如果用戶的請(qǐng)求中包含cookie，則CAS會(huì)以此cookie值為key查詢緩存中有無TGT，如果存在TGT，則用此TGT簽發(fā)一個(gè)ST，返回給用戶。用戶憑借ST去訪問service，service拿ST去CAS驗(yàn)證，驗(yàn)證通過后，允許用戶訪問資源。

任何一臺(tái) Workstation 都需要擁有一張有效的 Service Ticket 才能訪問域內(nèi)部的應(yīng)用 (Applications) 。如果能正確接收 Service Ticket ，說明在 CASClient-CASServer 之間的信任關(guān)系已經(jīng)被正確建立起來。

3）PGT（Proxy Granting Ticket）

Proxy Service的代理憑據(jù)。用戶通過CAS成功登錄某一Proxy Service后，CAS生成一個(gè)PGT對(duì)象，緩存在CAS本地，同時(shí)將PGT的值（一個(gè)UUID字符串）回傳給Proxy Service，并保存在Proxy Service里。Proxy Service拿到PGT后，就可以為Target Service（back-end service）做代理，為其申請(qǐng)PT。

4）PT（Proxy Ticket）

PT是用戶訪問Target Service（back-end service）的票據(jù)。如果用戶訪問的是一個(gè)Web應(yīng)用，則Web應(yīng)用會(huì)要求瀏覽器提供ST，瀏覽器就會(huì)用cookie去CAS獲取一個(gè)ST，然后就可以訪問這個(gè)Web應(yīng)用了。如果用戶訪問的不是一個(gè)Web應(yīng)用，而是一個(gè)C/S結(jié)構(gòu)的應(yīng)用，因?yàn)镃/S結(jié)構(gòu)的應(yīng)用得不到cookie，所以用戶不能自己去CAS獲取ST，而是通過訪問proxy service的接口，憑借proxy service的PGT去獲取一個(gè)PT，然后才能訪問到此應(yīng)用。

TGT、ST、PGT、PT之間關(guān)系的總結(jié)

1：ST是TGT簽發(fā)的。用戶在CAS上認(rèn)證成功后，CAS生成TGT，用TGT簽發(fā)一個(gè)ST，ST的ticketGrantingTicket屬性值是TGT對(duì)象，然后把ST的值redirect到客戶應(yīng)用。

2：PGT是ST簽發(fā)的。用戶憑借ST去訪問Proxy service，Proxy service去CAS驗(yàn)證ST（同時(shí)傳遞PgtUrl參數(shù)給CAS），如果ST驗(yàn)證成功，則CAS用ST簽發(fā)一個(gè)PGT，PGT對(duì)象里的ticketGrantingTicket是簽發(fā)ST的TGT對(duì)象。

3：PT是PGT簽發(fā)的。Proxy service代理back-end service去CAS獲取PT的時(shí)候，CAS根據(jù)傳來的pgt參數(shù)，獲取到PGT對(duì)象，然后調(diào)用其grantServiceTicket方法，生成一個(gè)PT對(duì)象。

1.1.2、CAS的服務(wù)

CAS的主要服務(wù)有：

• KDC（Key Distribution Center )；
• AS（Authentication Service）它索取 Crendential，發(fā)放 TGT；
• TGS（Ticket  Granting Service），索取 TGT ，發(fā)放 ST。

1.1.3、CAS的媒介

TGC（Ticket Granting Cookie)

存放用戶身份認(rèn)證憑證的cookie，在瀏覽器和CAS Server間通訊時(shí)使用，并且只能基于安全通道傳輸（Https），是CAS Server用來明確用戶身份的憑證。

1.2、CAS工作原理

CAS的單點(diǎn)登錄的認(rèn)證過程，所用應(yīng)用服務(wù)器受到應(yīng)用請(qǐng)求后，檢查ST和TGT，如果沒有或不對(duì)，轉(zhuǎn)到CAS認(rèn)證服務(wù)器登錄頁面，通過安全認(rèn)證后得到ST和TGT，再重新定向到相關(guān)應(yīng)用服務(wù)器，在回話生命周期之內(nèi)如果再定向到別的應(yīng)用，將出示ST和TGT進(jìn)行認(rèn)證，注意，取得TGT的過程是通過SSL安全協(xié)議的。

從網(wǎng)上找了一個(gè)比較專業(yè)又比較詳細(xì)的CAS工作原理流程圖：

CAS流程

專業(yè)版可能比較晦澀難懂，來個(gè)通俗版。通俗形象地說就是：相當(dāng)于用戶要去游樂場(chǎng)，首先要在門口檢查用戶的身份 ( 即 CHECK 用戶的 ID 和 PASS), 如果用戶通過驗(yàn)證，游樂場(chǎng)的門衛(wèi) (AS) 即提供給用戶一張門卡 (TGT)。

這張卡片的用處就是告訴游樂場(chǎng)的各個(gè)場(chǎng)所，用戶是通過正門進(jìn)來，而不是后門偷爬進(jìn)來的，并且也是獲取進(jìn)入場(chǎng)所一把鑰匙。

現(xiàn)在用戶有張卡，但是這對(duì)用戶來不重要，因?yàn)橛脩魜碛螛穲?chǎng)不是為了拿這張卡的而是為了游覽游樂項(xiàng)目，這時(shí)用戶摩天樓，并想游玩。

這時(shí)摩天輪的服務(wù)員 (client) 攔下用戶，向用戶要求摩天輪的 (ST) 票據(jù)，用戶說用戶只有一個(gè)門卡 (TGT), 那用戶只要把 TGT 放在一旁的票據(jù)授權(quán)機(jī) (TGS) 上刷一下。

票據(jù)授權(quán)機(jī) (TGS) 就根據(jù)用戶現(xiàn)在所在的摩天輪，給用戶一張摩天輪的票據(jù) (ST), 這樣用戶有了摩天輪的票據(jù)，現(xiàn)在用戶可以暢通無阻的進(jìn)入摩天輪里游玩了。

當(dāng)然如果用戶玩完摩天輪后，想去游樂園的咖啡廳休息下，那用戶一樣只要帶著那張門卡 (TGT). 到相應(yīng)的咖啡廳的票據(jù)授權(quán)機(jī) (TGS) 刷一下，得到咖啡廳的票據(jù) (ST) 就可以進(jìn)入咖啡廳

當(dāng)用戶離開游樂場(chǎng)后，想用這張 TGT 去刷打的回家的費(fèi)用，對(duì)不起，用戶的 TGT 已經(jīng)過期了，在用戶離開游樂場(chǎng)那刻開始，用戶的 TGT 就已經(jīng)銷毀了 。

二、基于角色的權(quán)限管理模型

在業(yè)界接受度較高的權(quán)限模型是RBAC(Role-Based Access Control),基本的概念是將“角色”這個(gè)概念賦予用戶，在系統(tǒng)中用戶通過分配角色從而獲得相應(yīng)的權(quán)限，一個(gè)用戶可以有多個(gè)角色，一個(gè)角色可以有多個(gè)權(quán)限，從而實(shí)現(xiàn)權(quán)限的靈活配置。

2.1、基本的RBAC模型

最基本的RBAC模型，就是由“用戶”，“角色”以及“權(quán)限”這三個(gè)主體組成，一個(gè)用戶可以有多個(gè)角色，一個(gè)角色可以有多個(gè)權(quán)限，他們之間的關(guān)系可以是多對(duì)一關(guān)系，也可以是多對(duì)多關(guān)系。

用戶角色權(quán)限關(guān)系

2.2、引入用戶組的RBAC模型

如果用戶數(shù)量比較龐大，新增一個(gè)角色時(shí)，需要為大量用戶都重新分配一遍新的角色，工程量巨大，此時(shí)可以引入用戶組的概念。如果部分用戶的使用場(chǎng)景是相對(duì)一致和基礎(chǔ)的，可以把這些用戶打包成一個(gè)組，基于這個(gè)組的對(duì)象進(jìn)行角色和權(quán)限的賦予。最終用戶擁有的所有權(quán)限 = 用戶個(gè)人擁有的權(quán)限+該用戶所在用戶組擁有的權(quán)限。

2.3、角色分級(jí)的RBAC模型

在一些業(yè)務(wù)場(chǎng)景中，上層角色需要繼承下層角色的全部權(quán)限，此時(shí)則需要使用角色繼承的RBAC模型。此時(shí)除了對(duì)角色進(jìn)行定義，還需要管理角色間的關(guān)系，通過關(guān)系來體現(xiàn)角色的層級(jí)關(guān)系，從而達(dá)到繼承權(quán)限的效果。角色的繼承關(guān)系主有兩種：樹形圖和有向無環(huán)圖。

角色繼承模式

繼承關(guān)系常常來源于公司團(tuán)隊(duì)的組織架構(gòu)，此時(shí)常常將角色與組織結(jié)構(gòu)進(jìn)行關(guān)聯(lián)達(dá)到繼承角色模型的效果。

2.4、角色限制的RBAC模型

在一些產(chǎn)品或系統(tǒng)中，部分角色可能是需要隔離的、不允許被同時(shí)賦予一個(gè)人的，比如不能既是運(yùn)動(dòng)員又是裁判員。因此，有些角色存在互拆關(guān)系。此外，限制還可能是數(shù)量上的，比如某個(gè)產(chǎn)品組中有且只有一個(gè)管理員，不允許刪除或再分配其他管理員。

根據(jù)不同的業(yè)務(wù)需求，限制的形式很多，需要注意的是不能僅僅依賴后段限制，而是要在前端展示清晰的規(guī)則和恰當(dāng)?shù)南拗?，避免用戶出錯(cuò)。

2.5、權(quán)限管理的基本元素

權(quán)限管理的基本元素為：用戶，角色，資源，操作，權(quán)限。

1、用戶 應(yīng)用系統(tǒng)的具體操作者，用戶可以自己擁有權(quán)限信息，可以歸屬于0～n個(gè)角色，可屬于0～n個(gè)組。他的權(quán)限集是自身具有的權(quán)限、所屬的各角色具有的權(quán)限、所屬的各組具有的權(quán)限的合集。它與權(quán)限、角色、組之間的關(guān)系都是n對(duì)n的關(guān)系。

2、用戶組（可選） 為了更好地管理用戶，對(duì)用戶進(jìn)行分組歸類，簡(jiǎn)稱為用戶分組。組也具有上下級(jí)關(guān)系，可以形成樹狀視圖。在實(shí)際情況中，我們知道，組也可以具有自己的角色信息、權(quán)限信息。

3、角色 為了對(duì)許多擁有相似權(quán)限的用戶進(jìn)行分類管理，定義了角色的概念，例如系統(tǒng)管理員、管理員、用戶、訪客等角色。角色具有上下級(jí)關(guān)系，可以形成樹狀視圖，父級(jí)角色的權(quán)限是自身及它的所有子角色的權(quán)限的綜合。父級(jí)角色的用戶、父級(jí)角色的組同理可推。

4、資源 權(quán)限管理的一個(gè)單元實(shí)體對(duì)象，我們廣義的稱之為資源，可以是一個(gè)人，也可以是一個(gè)產(chǎn)品，一個(gè)文件，一個(gè)頁面 等等。5、操作 對(duì)資源進(jìn)行的實(shí)際操作，比如讀、寫、編輯等等。

6、權(quán)限 資源+操作，構(gòu)成一個(gè)權(quán)限控制點(diǎn)。

對(duì)象間的關(guān)系包括：

• 是否關(guān)系
• 繼承關(guān)系
• 限制關(guān)系（互斥、范圍限制、邊界限制、字段限制）

三、數(shù)據(jù)表設(shè)計(jì)

按照RBAC模型，數(shù)據(jù)庫(kù)可以這樣設(shè)計(jì)：

1、產(chǎn)品表（t_product_info）

2、產(chǎn)品成員表（t_product_member）

3、用戶信息表（t_user_info)

4、用戶角色表(t_user_role)

5、角色表（t_role）

6、基礎(chǔ)角色表（t_role_base）

7、角色權(quán)限表（t_role_permission）

8、用戶組表（t_user_group，可選）

9、組角色表（t_user_group_role，可選）

10、用戶權(quán)限表（t_user_permission，可選)

四、角色及權(quán)限點(diǎn)設(shè)計(jì)

權(quán)限控制的整個(gè)過程可以描述為：“誰”對(duì)“什么”進(jìn)行什么”操作"，從而，引出我們需要做的工作有：角色設(shè)計(jì)，資源定義，以及對(duì)資源的操作定義。再詳細(xì)描述下，鑒權(quán)就是根據(jù)用戶身份（角色）獲得其對(duì)那些資源，可以進(jìn)行什么操作，其中對(duì)資源的操作做為一個(gè)獨(dú)立的權(quán)限體。

4.1、定義系統(tǒng)中的用戶角色

一般是采用“通用角色+實(shí)例角色”的模式，實(shí)例角色可繼承通用角色，從而擁有通用角色的權(quán)限。

常見的通用角色定義：ADMIN、MANAGER、MEMBER、GUEST 常見角色權(quán)限分配：1）SUPER_ADMIN,具有系統(tǒng)一切權(quán)限 1）產(chǎn)品ADMIN，具有當(dāng)前產(chǎn)品所有權(quán)限；2）產(chǎn)品MANAGER，不具備刪除權(quán)限，可修改，添加成員等 3）產(chǎn)品MEMEBER,可查看，修改信息，不可添加成員；4）產(chǎn)品GUEST,只可查看

實(shí)例角色：實(shí)例角色一般可以這樣定義：“資源點(diǎn)+通用角色+資源ID”

注：其中資源可能是產(chǎn)品，可能是頁面，也可能是菜單等

4.2、定義系統(tǒng)中的資源以及操作

一般系統(tǒng)中的最常見資源就是：產(chǎn)品（P) 一般對(duì)資源的主要操作包括：增加（CREATE)、刪除（DELETE)、修改（EDIT)、查看（VIEW)

當(dāng)然，系統(tǒng)中的資源肯定不止產(chǎn)品，同時(shí)產(chǎn)品這個(gè)粒度有些太粗，還可以更細(xì)化控制，當(dāng)然一切都根據(jù)實(shí)際業(yè)務(wù)需求情況定義相應(yīng)的資源點(diǎn)和操作。

4.3、權(quán)限體策略

權(quán)限控制策略采用五元組，如下：

資源：操作：實(shí)例：BU：密級(jí)

其中，資源可以是人，也可以是一個(gè)需求，一個(gè)文件等等；操作為對(duì)資源的操作；實(shí)例極為產(chǎn)品ID或者用戶ID；BU，密級(jí)用于控制不同BU,不同保密模塊的可見性

五、身份認(rèn)證加權(quán)限管理實(shí)施

JAVA可以采用SHIRO框架，一個(gè)最簡(jiǎn)單的一個(gè)Shiro應(yīng)用：1）應(yīng)用代碼通過subject授權(quán)，而subject又委托給SecurityManager；2）我們需要給Shiro的security注入Realm，從而讓SecurityManager能得到合法的用戶及其權(quán)限進(jìn)行判斷；

Shiro的最主要要做的工作其實(shí)就是兩個(gè)：身份認(rèn)證和權(quán)限校驗(yàn)，下面分別進(jìn)行介紹。

5.1、身份認(rèn)證

通過前面的文章分析，我們知道自定義身份校驗(yàn)校驗(yàn)邏輯，只需要繼承AuthenticatingRealm即可，Override如下接口進(jìn)行身份認(rèn)證：

@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token){}
復(fù)制代碼

上面這個(gè)接口，參數(shù)AuthenticationToken，它可以自定義子類實(shí)現(xiàn)，框架提供的有：UsernamePasswordToken，CasToken。

如果是采用用戶名密碼方式登陸，那么就構(gòu)造一個(gè)UsernamePasswordToken，然后取數(shù)據(jù)查詢用戶名密碼是否有效；如果是采用的CAS方式登陸，那么就通過ticket構(gòu)造一個(gè)CasToken，然后與CAS服務(wù)交互驗(yàn)證ticket是否有效。如果驗(yàn)證通過會(huì)生成一個(gè)AuthenticationInfo。此時(shí)身份認(rèn)證完成。

最簡(jiǎn)單的用戶密碼登陸身份校驗(yàn)代碼 CAS方式驗(yàn)證首先得有CAS系統(tǒng)，這里就不說明CAS方式怎么驗(yàn)證了，說一下怎么用用戶密碼登陸進(jìn)行身份校驗(yàn)，認(rèn)證流程都一樣

自定義一個(gè)AuthenticatingRealm:

public class MyRealm1 implements AuthenticatingRealm {  
    @Override
  protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {  
        String username = (String)token.getPrincipal();  //得到用戶名 
        String password = new String((char[])token.getCredentials()); //得到密碼  
        //取數(shù)據(jù)庫(kù)中看用戶名是否有效
        //checkUserInfo();
        
        //如果身份認(rèn)證驗(yàn)證成功，返回一個(gè)AuthenticationInfo實(shí)現(xiàn)；  
        return new SimpleAuthenticationInfo(username, password, getName());  
    }  
}  
復(fù)制代碼

5.2、權(quán)限校驗(yàn)

權(quán)限校驗(yàn)主要要做的事情就是完成"從數(shù)據(jù)庫(kù)中查出用戶所擁有的所有權(quán)限是否包含當(dāng)前待校驗(yàn)的權(quán)限"這么一個(gè)判斷過程，因此主要要做的就是：1）從數(shù)據(jù)庫(kù)中查出用戶所擁有的所有權(quán)限；2）解析權(quán)限，看看是否包含待校驗(yàn)的權(quán)限。

1、第一步：獲取用戶權(quán)限信息 獲取用戶權(quán)限信息這個(gè)過程是在Realm中完成的，繼承AuthorizingRealm，然后Override如下兩個(gè)接口獲取用戶的權(quán)限信息：

//獲取用戶身份信息，Authorization前需要先獲取用戶身份信息
@Override
protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token){}

//獲取用戶權(quán)限信息
@Override
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principalCollection){
}
復(fù)制代碼

權(quán)限信息查詢過程一般為：1）從數(shù)據(jù)庫(kù)中讀區(qū)用戶自身所配權(quán)限；2）從數(shù)據(jù)庫(kù)中讀取用戶角色所用擁有的權(quán)限（角色包含實(shí)例角色和BASE角色） 3）用戶最終的權(quán)限：用戶自身權(quán)限+用戶角色權(quán)限

2、第二步：權(quán)限校驗(yàn)

1）如果通過角色校驗(yàn)，則調(diào)用hasRole，與傳入的角色比較即可；

2）如果通過權(quán)限體校驗(yàn)，則調(diào)用isPermitted(...),與傳入的權(quán)限進(jìn)行比較即可。

shiro內(nèi)部邏輯如下：首先通過PermissionResolver將權(quán)限字符串轉(zhuǎn)換成相應(yīng)的Permission實(shí)例，默認(rèn)使用WildcardPermissionResolver，即轉(zhuǎn)換為通配符的WildcardPermission；接著調(diào)用Permission.implies(Permission p)逐個(gè)與傳入的權(quán)限比較，如果有匹配的則返回true，否則false。

六、參考資料

https://shiro.apache.org/

https://github.com/apache/shiro

https://jinnianshilongnian.iteye.com/blog/2018398

https://my.oschina.net/bochs/blog/2248956

https://blog.itning.top/posts/Essays/20190408-A-brief-explanation-of-single-sign-on-SSO-and-centralized-authentication-service-CAS-

     

      
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
     
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問題，請(qǐng)聯(lián)系我們，謝謝！