Backstage三层权限架构的设计

一、开发前准备

1. 确认 Backstage 服务已经搭建完成，未完成请参考这篇文章：如何搭建Backstage项目
2. 开发参考文档：
   • iTHome | Backstage: 打造企业内部开发者平台

二、三层权限架构的概念

单纯依赖 Backstage 的权限政策来限制插件或服务的使用权，可能无法让人完全放心，特别是在整合既有的重要服务时，安全问题常常成为关注的重点。

针对这些潜在的安全问题，我们需要设计并实现一个更完善的安全框架。

这里，参照参考文档，并结合整个系统的设计需求，我们将使用三层权限架构，作为整个系统的安全框架。

第一层 — SSO Microsoft Azure 登录验证

权限架构的第一层防护，是通过公司内部的 Microsoft Azure 认证系统实现的。使用者必须完成身份验证后才能进入 Backstage。

第二层 — Backstage Permission 权限政策

登入验证完成后，第二层防护则由 Backstage 的权限系统负责。每一位使用者根据其所属的群组将会拥有不同的操作权限。这一层次的权限可以设定得更加细节，范围可以涵盖大多数的 Backstage 功能，根据具体业务需求分类分组，解决跨权限访问的问题。

第三层 — 插件本身的独立验证

最后一层是插件本身的验证机制，或者说原始服务、外部应用。有些应用具备自己的内部身份验证系统，或额外的验证步骤。即便 Backstage 的 SSO 和权限政策被攻破，应用内部的权限系统仍可以提供额外的防护。

三层权限架构提供了一个较为灵活的情景框架，能有效应对不同场景，实现高安全性与弹性设定的协调。针对最需要严格管制的应用，就算突破前面的两层，该服务本身的验证也能作为最后防线。针对权限需求较低的应用场景，SSO 的串接优势就凸显出来了：依靠第一层 SSO 提供的认证，使用者可以直接无缝通过第三层的插件验证，实现与 Backstage 的无缝整合，提升整体使用体验。

三、整体架构的应用场景

例如：

（1）读取项目资料的一般权限

对于只需要读取资料而不涉及修改或进阶操作的情景，如项目资料浏览或技术文件浏览，可以只依赖前两层的 SSO 和基本的 Backstage 权限政策进行保护。这样既保障了基本数据的隐私，又不会过度增加操作负担。

（2）Filebrowser 档案浏览器插件

Filebrowser 插件允许使用者直接对服务器存取、上传或者管理档案，安全需求相对非常高。因此，除了 SSO 和 Backstage 的权限管理，还需要第三层插件内建的身份验证来进一步保障敏感档案的安全存取，Filebrowser 本身拥有用户管理功能，确保只有授权用户才能执行特定操作。

（3）Discourse 内部论坛服务

对于内部的论坛系统，如 Discourse。这类应用对于 Backstage 的安全政策依赖比较低，主要是透过 SSO 认证进行身份验证即可，权限需求比较宽松。由于论坛系统主要为公司员工提供讨论与交流的空间，相对不涉及敏感资料或核心业务操作，因此不需要启动 Backstage 的进阶权限政策或将插件独立出来进行验证，这样的设计能够有效简化操作流程，提升使用的便捷性。

四、小结

三层架构并不是要求每个插件都启用全部三层，而是提供一套可按敏感度取舍的框架：