如何設(shè)計(jì)一個(gè)通用的權(quán)限管理系統(tǒng)

一個(gè)系統(tǒng)，如果沒(méi)有安全控制，是十分危險(xiǎn)的，一般安全控制包括身份認(rèn)證和權(quán)限管理。用戶(hù)訪問(wèn)時(shí)，首先需要查看此用戶(hù)是否是合法用戶(hù)，然后檢查此用戶(hù)可以對(duì)那些資源進(jìn)行何種操作，最終做到安全訪問(wèn)。

身份認(rèn)證的方式有很多種，最簡(jiǎn)單的就是直接用戶(hù)名密碼，還有業(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ù)（英語(yǔ)：Central Authentication Service，縮寫(xiě)CAS）是一種針對(duì)萬(wàn)維網(wǎng)的單點(diǎn)登錄協(xié)議。它的目的是允許一個(gè)用戶(hù)訪問(wèn)多個(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ù)誰(shuí)生成得了？肯定是有相關(guān)服務(wù)的，主要服務(wù)有：KDC，AS，TGS。兩者媒介肯定也是有的：TGC。

1.1.1、CAS的Ticket

1）TGT（Ticket Granting Tieckt）

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

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

2）ST（Service ticket）

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

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

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

3）PGT（Proxy Granting Ticket）

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

4）PT（Proxy Ticket）

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

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

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

2：PGT是ST簽發(fā)的。用戶(hù)憑借ST去訪問(wèn)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ù)傳來(lái)的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)

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

1.2、CAS工作原理

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

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

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

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

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

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

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

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

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

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

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

2.1、基本的RBAC模型

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

2.2、引入用戶(hù)組的RBAC模型

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

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

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

繼承關(guān)系常常來(lái)源于公司團(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ù)需求，限制的形式很多，需要注意的是不能僅僅依賴(lài)后段限制，而是要在前端展示清晰的規(guī)則和恰當(dāng)?shù)南拗疲苊庥脩?hù)出錯(cuò)。

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

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

1、用戶(hù) 應(yīng)用系統(tǒng)的具體操作者，用戶(hù)可以自己擁有權(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、用戶(hù)組（可選） 為了更好地管理用戶(hù)，對(duì)用戶(hù)進(jìn)行分組歸類(lèi)，簡(jiǎn)稱(chēng)為用戶(hù)分組。組也具有上下級(jí)關(guān)系，可以形成樹(shù)狀視圖。在實(shí)際情況中，我們知道，組也可以具有自己的角色信息、權(quán)限信息。

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

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

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、用戶(hù)信息表（t_user_info)

4、用戶(hù)角色表(t_user_role)

5、角色表（t_role）

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

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

8、用戶(hù)組表（t_user_group，可選）

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

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

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

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

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

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

常見(jiàn)的通用角色定義：ADMIN、MANAGER、MEMBER、GUEST 常見(jiàn)角色權(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)品，可能是頁(yè)面，也可能是菜單等

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

一般系統(tǒng)中的最常見(jiàn)資源就是：產(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或者用戶(hù)ID；BU，密級(jí)用于控制不同BU,不同保密模塊的可見(jiàn)性

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

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

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

5.1、身份認(rèn)證

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

@Override
protected?AuthenticationInfo?doGetAuthenticationInfo(AuthenticationToken?token){}

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

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

最簡(jiǎn)單的用戶(hù)密碼登陸身份校驗(yàn)代碼 CAS方式驗(yàn)證首先得有CAS系統(tǒng)，這里就不說(shuō)明CAS方式怎么驗(yàn)證了，說(shuō)一下怎么用用戶(hù)密碼登陸進(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();??//得到用戶(hù)名?
????????String?password?=?new?String((char[])token.getCredentials());?//得到密碼??
????????//取數(shù)據(jù)庫(kù)中看用戶(hù)名是否有效
????????//checkUserInfo();
????????
????????//如果身份認(rèn)證驗(yàn)證成功，返回一個(gè)AuthenticationInfo實(shí)現(xiàn)；??
????????return?new?SimpleAuthenticationInfo(username,?password,?getName());??
????}??
}??

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

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

1）從數(shù)據(jù)庫(kù)中查出用戶(hù)所擁有的所有權(quán)限；

2）解析權(quán)限，看看是否包含待校驗(yàn)的權(quán)限。

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

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

//獲取用戶(hù)權(quán)限信息
@Override
protected?AuthorizationInfo?doGetAuthorizationInfo(PrincipalCollection?principalCollection){
}

權(quán)限信息查詢(xún)過(guò)程一般為：

1）從數(shù)據(jù)庫(kù)中讀區(qū)用戶(hù)自身所配權(quán)限；

2）從數(shù)據(jù)庫(kù)中讀取用戶(hù)角色所用擁有的權(quán)限（角色包含實(shí)例角色和BASE角色）

3）用戶(hù)最終的權(quán)限：用戶(hù)自身權(quán)限+用戶(hù)角色權(quán)限

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

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

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

shiro內(nèi)部邏輯如下：首先通過(guò)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-and-open-authorized-OAuth.html

推薦閱讀
把 Spring Cloud 給拆了！詳解每個(gè)組件的作用
Java中5種List的去重方法及它們的效率對(duì)比，你用對(duì)了嗎？
是時(shí)候扔掉 Postman 了，試試 IntelliJ IDEA 自帶的高能神器！
2020年11月程序員工資統(tǒng)計(jì)，平均14327元
這應(yīng)該是全網(wǎng)最全的Git分支開(kāi)發(fā)規(guī)范手冊(cè)~

最后，推薦給大家一個(gè)有趣有料的公眾號(hào)：寫(xiě)代碼的渣渣鵬，7年老程序員教你寫(xiě)bug,回復(fù) 面試或資源 送一你整套開(kāi)發(fā)筆記 有驚喜哦