IAM平臺是什么
IDaas平臺介紹
IAM組成
IAM系統的權限管理體系
- 一. 權限管理體系描述
- 二. 認證
  - 2.1 認證方式
    - 2.1.1 獨立認證
    - 2.1.2 疊加認證(認證鏈)
  - 2.2 認證協議
    - 2.2.1 CAS
    - 2.2.2 JWT
- 三. 鑒權
  - 3.1 權限模型
    - 3.1.1 RBAC(基于角色訪問控制)
    - 3.1.2 ABAC(基于屬性訪問控制)
  - 3.2 鑒權模型
    - 3.2.1 shrio
    - 3.2.2 casbin
    - 3.2.3 access list

IAM平臺是什么

IAM（Identity and Access Management 的縮寫），即“身份識別與訪問管理”，具有認證管理、策略授權、審計、動態授權、身份管理、應用管理等功能，

IDaas平臺介紹

IDaas（Identify as a Service 的縮寫）, IDaaS 實際上就是一個基于 SaaS 模式的 IAM 解決方案,也就是云上的身份和訪問管理服務,完全由受信任的第三方云服務廠商托管和管理，SaaS + IAM = IDaaS，即服務（SaaS）通常是指由別人（一般指云服務廠商）提供的服務，它可以讓個人或企業專注于自身更重要的業務，
在 SaaS 這種軟體交付模式下，軟體不再需要復雜的安裝部署程序，只需通過網路連接就可直接使用，軟體及其資料托管在云服務廠商中，廠商將全程負責處理軟體更新、漏洞修復等維護作業，用戶通常通過 Web 瀏覽器或 API 連接就可以使用軟體，

IAM組成

認證管理
身份管理
策略授權
審計
應用管理

IAM系統的權限管理體系

一. 權限管理體系描述

權限管理做為系統工程中比較重要的基礎模塊,因此一套完善和靈活的權限體系方案可以更好的為系統的安全賦能，完善的權限體系,需要依賴于一套完備的解決方案,在整個體系的建立程序中可以分為兩個部分(認證和授權)實作，并且這兩個部分沒有強依賴性,可以根據業務的不同選擇不同的型別進行組合，

認證(認證管理)

認證方式(賬號密碼、手機驗證碼、第三方賬號登錄等)

認證協議(cas、jwt、oauth2等)

鑒權(策略授權)

權限模型(RBAC、ABAC、DAC、MAC)

鑒權模型(shrio、casbin、access list)

二. 認證

認證程序(登錄)是一個系統工程的門戶也是訪問的第一步,只有進行認證過的瀏覽器才可以進行后續的操作,但是很多時候會將認證的方式和認證的協議搞混,其實這里可以看到認證的方式可以多種多樣的(甚至可以進行組合成認證鏈),而且認證的協議也可以是多種多樣的,不管是獨立的認證還是進行單點登錄的認證都可以根據自己的業務進自由組合，

2.1 認證方式

認證方式(登錄方式),隨著越來越多的業務場景和一些復雜的環境的要求,誕生出來不同的登錄方式,在不同的業務場景下可以進行自主的選擇和疊加,分為獨立認證方式和疊加認證兩種方式，

2.1.1 獨立認證

賬號密碼登錄

? 目前最常使用,但是安全性也是最低的一種認證方式,因此一般會采用一些措施保證登錄安全和帳號安全，
- 檢測長時間使用同一密碼進行強制修改密碼操作
- 對登錄程序中的資料進行加密傳輸
- 對資料的存盤進行加隨機鹽等安全的密碼方式進行脫敏存盤(防止撞庫)
手機驗證碼登錄

? 手機驗證碼有著快速登錄認證的特點,因此會有一部分系統選擇使用手機驗證碼進行登錄，但是也會存在一定的風險，
- 短信驗證碼防盜刷
- 短信驗證碼超時機制
第三方登錄(運營商、微信、支付寶等)

? 越來越多的第三方登錄方式(微信為主),由第三方進行認證的主要流程,然后應用后端進行認證結果的判斷,例如微信傳入openId,應用后端就需要進行賬號和openId的關聯，

2.1.2 疊加認證(認證鏈)

由于單一的認證場景下并不能保證認證程序的安全性,因此可以根據不同的業務場景進行認證方式的組合和疊加，

賬號密碼+短信驗證碼
賬號密碼+郵箱驗證

2.2 認證協議

認證的協議是認證結果完成之后認證票據的表達形式，也是認證程序中的一部分，因此需要了解不同的認證協議所應對的不同的認證場景，可以在不同的場景下選擇合適的認證協議，

2.2.1 CAS

單點登錄的協議的一種,通過SSO進行認證的登錄操作

sequenceDiagram 瀏覽器->>前端:訪問前端->>服務器后端:訪問服務器后端-->>前端:回傳CAS認證地址前端->>SSO:訪問 SSO-->>瀏覽器:無全域會話,重定向到登錄頁面瀏覽器->>SSO:攜帶登錄資訊進行登錄操作 SSO-->>SSO:檢驗登錄資訊并且生成TGT存入session SSO-->>瀏覽器:將保存TGT的sessionId（TGC）寫入cookie中并且將頁面重定向到前端地址瀏覽器->>前端:訪問前端->>服務器后端:訪問服務器后端-->>前端:回傳CAS認證地址前端->>SSO:訪問 SSO-->>SSO:校驗TGT并且生成ST SSO-->>服務器后端:攜帶ST回傳后端服務器后端->>SSO:驗證當前的ST資訊并且根據TGC從session獲得用戶資訊服務器后端->>前端:登陸成功

2.2.2 JWT

一種簡單的認證協議,因為無狀態和服務器無關性,因此具有較好的使用基礎,但是也會有一些相應的問題

sequenceDiagram 瀏覽器->>前端:訪問前端->>服務器后端:訪問服務器后端-->>前端:回傳SSO認證地址前端->>SSO:訪問 SSO-->>瀏覽器:無全域會話,重定向到登錄頁面瀏覽器->>SSO:攜帶登錄資訊進行登錄操作 SSO-->>SSO:檢驗登錄資訊并且生成全域會話 SSO-->>瀏覽器:將全域會話寫入cookie中并且將頁面重定向到前端地址瀏覽器->>前端:訪問前端->>服務器后端:訪問服務器后端-->>前端:回傳SSO認證地址前端->>SSO:訪問 SSO-->>SSO:校驗全域會話并且生成jwt token SSO-->>服務器后端:攜帶token回傳后端服務器后端->>SSO:驗證當前的token資訊并且獲得用戶資訊服務器后端-->>瀏覽器:將token寫入到瀏覽器中

三. 鑒權

做為權限體系的組成部分,鑒權也是至關重要的，再認證完成之后,接下來的訪問操作我們都需要根據之前生成的認證結果進行權限的校驗和判斷，這部分的設計也可以分為兩部分：權限模型和鑒權模型

3.1 權限模型

權限模型的選擇也需要去根據具體的業務進行選擇，主流的權限模型分為四種：

自主訪問控制(DAC，Discretionary Access Control)

強制訪問控制 (MAC，Mandatory Access Control)

基于角色訪問控制 (RBAC，Role-based Access Control)

基于屬性訪問控制 (ABAC，Attribute-based Access Control)

比較常用的則是后面兩種，我們就后面兩種的使用場景進行講解，

3.1.1 RBAC(基于角色訪問控制)

最常使用的一種訪問控制模型,基于角色進行授權，將權限關聯到角色上，通過角色的授權進行用戶的權限管理,這樣有利于進行權限的管理,只需要維護角色的權限即可,不用去關心用戶的屬性，需要注意單個用戶擁有多個角色的時候需要進行權限的合并，

graph TB subgraph 權限管控體系選單表-->角色和選單關聯表角色表-->用戶和角色關聯表角色表-->角色和選單關聯表用戶表-->用戶和角色關聯表 end

3.1.2 ABAC(基于屬性訪問控制)

基于屬性訪問控制模型,將權限分裂到不同的屬性上，可以針對不同的屬性分配不同的權限，適合權限體系多樣性的系統,并且可以實時動態變更權限的系統，

graph TB subgraph 權限管控體系選單表-->屬性和選單關聯表屬性表-->用戶和屬性關聯表屬性表-->屬性和選單關聯表用戶表-->用戶和屬性關聯表 end

3.2 鑒權模型

在鑒權體系中,在確定了權限模型之后,那就需要考慮鑒權模型的建立,通過選擇不同的鑒權模型進行權限資料的維護和校驗，模型在選擇的程序中可以根據不同的需求和權限模型進行選擇，目前比較主流的下列三種：

shrio

casbin

access list

3.2.1 shrio

一個Apache開源的安全框架,可以很好的和spring代碼進行融合，但是由于shrio在做權限的時候，依賴于介面層面的一些注解(不夠靈活)，再加上微服務體系中可能會集成進來的別的語言撰寫的代碼，因此在純java體系并且權限校驗的介面變化不頻繁的場景下可以選擇shrio

3.2.2 casbin

一個支持多種權限模型的框架,可以通過自行配置一些系統的權限規則模型進行權限的校驗，因其支持多種不同的模型并且支持鑒權介面的動態配置，再加上語言的無關性，所以有不錯的使用基礎，但是由于模型配置的問題，導致需要提前預置模型規則

3.2.3 access list

一個基于訪問控制串列延申出來的一套方案，通過自行去維護訪問的授權串列，來進行權限的校驗，由于其只依賴于外部存盤和需要預先配置的權限資料，因此不同的體系和不同的資源型別都可以通過這種方式進行配置，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/542630.html

標籤：其他

上一篇：IAM系統的權限管理體系介紹

下一篇：模塊化開發