在昨天（Day 24）我們提到 Authorization（授權） 的基本概念，今天要更進一步介紹在實務中最常見的授權模型之一：RBAC（Role-Based Access Control，基於角色的存取控制）。

一、什麼是 RBAC？

RBAC 的核心理念很簡單：

授權不是直接賦予使用者權限，而是先把權限分配給「角色」，再把角色指派給使用者。

這樣的做法就像公司組織一樣：

• 使用者（User）＝ 員工
• 角色（Role）＝ 職位（例如：業務、會計、經理）
• 權限（Permission）＝ 具體的工作職責（新增客戶、刪除訂單、審核報表）

二、RBAC 的三層關係

在 RBAC 中，通常會有三個關鍵實體：

1. User（使用者）
   • 系統中的個體，例如 Alice、Bob。
2. Role（角色）
   • 抽象化的身份，例如 ROLE_ADMIN、ROLE_USER。
3. Permission（權限）
   • 更細的操作動作，例如 CREATE_ORDER、DELETE_USER。

關聯方式：

• User → Role → Permission
• 使用者直接綁定角色，而不是直接綁定權限。

三、RBAC 的優點

1. 易於管理
   • 不用針對每個人設定權限，只要給他角色即可。
   • 例如：新進員工給 ROLE_USER 就能立刻擁有基礎功能。
2. 降低錯誤
   • 權限集中於角色層級，避免人為遺漏或誤設。
3. 組織對應自然
   • 角色可以對應到公司職位或部門，例如「財務」、「人資」、「主管」。
4. 彈性擴展
   • 當系統新增功能，只要修改角色對應的權限，而不需逐一修改使用者。

四、RBAC 與 Spring Security 的結合

Spring Security 原生就支援 RBAC 的概念：

• 角色表示法：

  • 通常寫成 ROLE_ADMIN、ROLE_USER。
  • 在設定時可透過 .hasRole("ADMIN") 來檢查。

• 權限表示法：

  • 可用 .hasAuthority("DELETE_ORDER") 來檢查更細的操作。

• 典型場景：

  http.authorizeHttpRequests(auth -> auth
      .requestMatchers("/admin/**").hasRole("ADMIN")
      .requestMatchers("/reports/**").hasAnyRole("ADMIN", "MANAGER")
      .requestMatchers("/user/**").hasRole("USER")
      .anyRequest().authenticated()
  );
  

五、RBAC 的簡單案例

假設一個電商系統：

• 角色
  • ROLE_CUSTOMER：下單、查詢訂單
  • ROLE_SELLER：新增商品、查看訂單
  • ROLE_ADMIN：管理所有使用者與商品
• 權限對應
  • ROLE_CUSTOMER → CREATE_ORDER, READ_ORDER
  • ROLE_SELLER → CREATE_PRODUCT, READ_ORDER
  • ROLE_ADMIN → DELETE_USER, MANAGE_PRODUCT, READ_ALL_ORDERS

RBAC 是企業系統中最常見的授權模型，簡單卻足夠應付大部分需求。在實務上會有更多已經成熟實作的RBAC工具，大家可以在網路上先去尋找。

但隨著系統複雜度提高，有時會需要更細緻的控制，例如 ABAC（Attribute-Based Access Control，基於屬性的存取控制）。

那麼今天就分享到這裡，我們明天見！