權限管理登入

Role Based Access Control (RBAC) 建置規劃

湯菀鈺 2024/09/11 19:32:45

0 990

Role Based Access Control (RBAC) 規劃

簡介

專案開發需要一套權限管理系統，能夠簡化權限配置流程，減少錯誤，並提供更高的擴展性和可管理性。以下將介紹如何設計一個靈活且可擴展的權限管理架構及其實作步驟。

前言

隨著系統角色和權限結構的複雜化，設計架構需要考量以下問題：
- 權限管理複雜性: 隨著角色和權限數量的增加，權限管理變得越來越複雜。每新增一個角色或功能，都需要手動更新配置，這使得管理變得繁瑣且易出錯。
- 不一致的訪問控制: 不同用戶可能擁有不同的權限，這可能導致某些用戶無法訪問所需功能，或不應該有權訪問某些敏感功能，從而引發安全問題。
- 難以擴展: 當系統擴展時，原有的權限管理系統可能無法輕易地擴展以滿足新需求。這會限制系統的靈活性和未來的擴展能力。

設計方向

為了解決上述問題，我們需要設計一個可擴展且易於管理的權限控制系統。以下是主要的設計方向：

基於角色的訪問控制：通過角色來管理用戶的權限，每個角色擁有特定的權限。這樣可以簡化權限配置，並通過角色來集中管理權限。

使用群組和角色的關聯：將用戶組織到不同的群組中，並將角色分配給群組。用戶通過所屬群組獲得相應的角色和權限，從而簡化管理流程。

清晰的功能與權限映射：定義明確的功能和權限，並將它們與角色和群組關聯。這樣可以確保每個用戶擁有正確的權限，並且訪問控制過程透明且易於維護。

流程說明

TPI.TPIU.RBAC.角色群組登入流程圖.mermaid.gist

https://gist.github.com/user-attachments/assets/d8928363-6c84-423f-ada7-7afb463cc622

資料表結構

用戶資料表 (USER)：存儲用戶的基本信息

	  CREATE TABLE USER (
	    USER_ID INT PRIMARY KEY,
	    USERNAME VARCHAR(50) NOT NULL,
	    PASSWORD VARCHAR(255) NOT NULL
	  );

功能表 (FUNCTION)：存儲功能代碼和行為類型

	    CREATE TABLE FUNCTION (
	        FUNCTION_ID INT PRIMARY KEY,
	        FUNCTION_CODE VARCHAR(50),
	        ACTION_TYPE CHAR(1)
	    );

角色資料表 (ROLE)：存儲角色信息

	    CREATE TABLE ROLE (
	        ROLE_ID INT PRIMARY KEY,
	        ROLE_NAME VARCHAR(50) NOT NULL
	    );

使用者角色關聯表 (USER_ROLE)：定義用戶與角色的關聯

	    CREATE TABLE USER_ROLE (
	        USER_ID INT,
	        ROLE_ID INT,
	        PRIMARY KEY (USER_ID, ROLE_ID)
	    );

群組角色關聯表 (GROUP_ROLE)：定義群組與角色的關聯

	    CREATE TABLE GROUP_ROLE (
	        GROUP_ID INT,
	        ROLE_ID INT,
	        PRIMARY KEY (GROUP_ID, ROLE_ID)
	    );

群組使用者關聯表 (GROUP_USER)：定義群組與用戶的關聯

	    CREATE TABLE GROUP_USER (
	        GROUP_ID INT,
	        USER_ID INT,
	        PRIMARY KEY (GROUP_ID, USER_ID)
	    );

角色功能關聯表 (ROLE_FUNCTION)：定義角色與功能的關聯

	    CREATE TABLE ROLE_FUNCTION (
	        ROLE_ID INT,
	        FUNCTION_ID INT,
	        PRIMARY KEY (ROLE_ID, FUNCTION_ID)
	    );

配置角色和權限
- 根據需求將角色分配給群組，並為每個角色配置相應的權限。
- 通過 USER_ROLE，GROUP_ROLE 和 ROLE_FUNCTION 表來管理功能訪問。

測試資料

以下為各個資料表的結構與測試資料：

角色 (ROLE)

ROLE_ID ROLE_NAME

1 Admin

2 User

3 Guest

功能 (FUNCTION)

FUNCTION_ID	FUNCTION_CODE	ACTION_TYPE
1	ViewDashboard	R
2	EditProfile	W
3	DeleteUser	D

群組 (GROUP)

GROUP_ID	GROUP_NAME
1	AdminGroup
2	UserGroup
3	GuestGroup

使用者 (USER)

USER_ID	USER_NAME
101	Alice
102	Bob
103	Carol
104	Dave

群組與使用者關聯 (GROUP_USER)

GROUP_ID USER_ID

1 101

2 102

2 103

角色與群組關聯 (GROUP_ROLE)

GROUP_ID ROLE_ID

1 1

2 2

3 3

角色與功能關聯 (ROLE_FUNCTION)

ROLE_ID	FUNCTION_ID
1	1
1	2
1	3
2	1
2	2
3	1

用戶與角色關聯 (USER_ROLE)

USER_ID	ROLE_ID
101	1
102	2
103	2
104	3

用戶登入權限檢查流程

TPI.TPIU.RBAC.用戶登入權限檢查流程.md.gist

https://gist.github.com/user-attachments/assets/24f897e0-a854-4e45-b309-8899873fe382

登入流程測試案例

以下將說明如何透過登入流程來測試這些權限控管設計：

Admin 登入 (Alice)
- 步驟: 使用 Alice 的帳號 (USER_ID: 101) 登入。
- 預期結果:
  - Alice 屬於 AdminGroup，因此她擁有 Admin 角色的所有權限（根據 GROUP_ROLE 和 ROLE_FUNCTION 表設定）。
  - 由於 Alice 沒有額外的個人權限，她的權限完全來自群組角色。因此，Alice 可以查看儀表板、編輯個人檔案和刪除用戶。

User 登入 (Bob)
- 步驟: 使用 Bob 的帳號 (USER_ID: 102) 登入。
- 預期結果:
  - Bob 屬於 UserGroup，因此他擁有 User 角色的權限（根據 GROUP_ROLE 和 ROLE_FUNCTION 表設定）。
  - 此外，Bob 還有額外的個人角色權限（根據 USER_ROLE 表設定）。因此，Bob 可以查看儀表板、編輯個人檔案和刪除用戶，因為他的個人角色補充了群組角色中沒有的刪除用戶功能。

Guest 登入 (Carol)
- 步驟: 使用 Carol 的帳號 (USER_ID: 103) 登入。
- 預期結果:
  - Carol 屬於 UserGroup，因此她擁有 User 角色的權限（根據 GROUP_ROLE 和 ROLE_FUNCTION 表設定）。
  - Carol 的個人角色沒有額外設定，因此她的權限僅基於群組角色。因此，Carol 可以查看儀表板和編輯個人檔案。

獨立用戶測試 (Dave)
- 步驟: 使用 Dave 的帳號 (USER_ID: 104) 登入。
- 預期結果:
  - Dave 不屬於任何群組，但擁有 Guest 角色的權限（根據 USER_ROLE 表設定）。
  - 因此，Dave 只能查看儀表板，無法進行其他操作，因為他不在任何群組內，且沒有額外的角色權限。