在上一篇文章中，我們透過撰寫權限政策，成功解決了實體組件的可視度問題，確保經過擁有權檢查通過後，特定類型的實體才會被使用者看見。同時，插件的存取權限設定也非常重要。以上一篇提到 Filebrowser 插件為例，我們必須阻止非管理員角色的使用者進入使用，以保障系統安全。本篇文章前半部將針對插件應用權限政策，並且在使用者無權使用插件時，必須顯示提示資訊頁面。
文章的後半部分將介紹我們提出的『Backstage 的三層權限框架概念』，該框架利用不同層次的身份驗證方式，為插件提供安全保護。我們將詳細解釋每一層的功能與作用，並展示它們如何協同運作，以確保 Backstage 的安全性與可擴展性。最後，我們將探討如何將 SSO（單一登入）無縫整合至此框架中，並分析採用 SSO 的優勢，如簡化用戶體驗與提升安全性，同時也會討論實施過程中可能遇到的挑戰及其應對方案。
權限策略的設置非常重要，特別是在涉及到敏感資料或特定核心業務的功能時。像是一些插件的功能可能只適合開發者或特定部門的人員操作。我們需要限制這些插件的使用權限，而非任意使用者都可進入。
如果使用者請求的權限屬於 catalogEntityCreatePermission 創建實體請求，我們會檢查他們是否屬於 backstage-developer 群組。如果屬於該群組，我們將授予存取權，否則拒絕。直接使用catalogEntityCreatePermission 方法雖非標準做法，但這裡用於示範如何實現概念。
新增完規則後，我們為 n8n 路由加入了 RequirePermission 限制，指定需要權限catalogEntityCreatePermission。代表只有擁有創建實體權限的使用者才能夠進入 n8n 插件頁面，其他使用者則會被阻止，再加上我們的權限策略限制只有backstage-developer 群組才擁有創建實體權限來加以限制。
當我們為 n8n 插件設定的權限規則生效後，沒有權限的使用者會在嘗試訪問該插件時遇到錯誤訊息。但是過於簡略我們很難清楚是什麼原因。
為了提升使用者體驗，我們可以針對個頁面來自定義錯誤訊息，提供更具體的提示。例如，我們可以顯示使用者沒有足夠的權限訪問該插件，並引導他們聯繫管理員以獲取進一步的幫助。
建立了一個自定義的前端頁面檔案 PermissionDenied.tsx，專門用來顯示權限不足的錯誤訊息。
接下來，我們將這個頁面指定為在訪問插件時的錯誤處理頁面。
更新之後的錯誤訊息頁面，是不是清晰許多了呢～
若我們測試將我的使用者加入到 backstage-developer 群組中。
確認 Ownership 有出現群組實體
再次訪問 n8n 插件，我們擁有符合規則的權限組，這次我們成功進入頁面了。到這邊就大致上演示完，幫插件設定權限限制的的基本概念了，基礎本都是基於上一篇的文章時做內容去做加工。
只依賴 Backstage 的權限政策來限制插件或服務的使用權，可能無法讓人完全放心，特別是在整合既有的重要服務時，資安問題常常成為關注焦點。當我們面對不熟悉 Backstage 的使用者或開發者時，如何讓他們信任並願意將資料提供給平台整合，是一個巨大的挑戰。在開發過程中，除了技術可行性，實務中的接受度也成為關鍵考量。
針對這些潛在的安全問題，我們提出了一個更完善的安全框架。這個框架結合了前面文章討論的案例與議題，將身份驗證分為三個不同層次，每一層提供不同的安全模式，實現更全面的保護。架構如下：
第一層 - SSO OTP 登入驗證
權限框架的第一層防護，通過公司內部的單一登入系統 SSO，使用者必須完成身份驗證才能進入 Backstage。我們還結合內部 OTP 密碼驗證，與員工手機 APP 綁定，更進一步確保只有內部員工才能進入平台。
第二層 - Backstage Permission 權限政策
登入驗證完成後，第二層防護則由 Backstage 的權限系統負責。每位使用者根據其所屬群組（如開發人員、管理人員或其他部門）擁有不同的操作權限。這一層次的權限設定較為細節，範圍涵蓋大多數 Backstage 的功能，根據具體業務需求分類分組，解決跨權限訪問的問題。
第三層 - 插件本身的獨立驗證
最後一層是插件本身的驗證機制，或說原始服務、外部應用。有些應用具備自己的內部身份驗證系統，或額外的驗證步驟。即便 Backstage 的 SSO 和權限政策被攻破，應用的內部權限系統仍可提供額外的防護。例如，Uptime Kuma 可以選擇開啟帳密登入驗證機制。
三層權限架構提供了一個靈活的情境框架，能有效應對不同場景，實現高安全性與彈性設定的協調。針對需要嚴格管制的應用，就算突破前面的兩層驗證，該服務本身的驗證也能作為最後防線。針對權限需求較低的應用場景，SSO 的串接優勢就突顯出來。依靠第一層 SSO 所提供的憑證驗證，使用者可以直接無縫通過第三層的插件驗證，實現與 Backstage 的無縫整合，提升整體使用體驗。
這三層架構的彈性設計適用於各種應用場景，特別是在不同插件對安全性的需求各異時，能靈活配置不同層級的保護措施。例如我們可以拿先前的演示案例來說明。
例如：
讀取專案資訊的一般權限
對於只需要讀取資料而不涉及修改或進階操作的情境，如專案資訊瀏覽或技術文件的瀏覽，可以只依賴前兩層的 SSO 和基本的 Backstage 權限政策進行保護。這樣既保障了基本數據的隱私，又不會過度增加操作負擔。
Filebrowser 檔案瀏覽器插件
Filebrowser 插件允許使用者直接對伺服器存取、上傳或管理檔案，安全需求相對非常高。因此，除了 SSO 和 Backstage 的權限管理，還需要第三層插件內建的身份驗證來進一步保障敏感檔案的安全存取，Filebrowser本身擁有用戶管理功能，確保只有授權用戶能執行特定操作。
Discourse 內部論壇服務
對於內部的論壇系統如 Discourse，這類應用對 Backstage 的安全政策依賴較低，主要是透過 SSO 憑證進行身份驗證即可，權限需求較為寬鬆。由於論壇系統主要為公司員工提供討論與交流空間，相對不涉及敏感資料或核心業務操作，因此不需要啟動 Backstage 的進階權限政策或獨立出插件層驗證，這樣的設計能有效簡化操作流程，提升使用的便利性。
iThome鐵人賽
看影片追技術