What’s happening with Backstage permissions and authorization

TL;DR The Spotify team has published an authorization framework RFC in the Backstage GitHub repository which is open for feedback until Friday, November 5. Read on for more information about our approach and future plans for authorization.

Our proposal for an open, flexible authorization framework

With Halloween just around the corner, we thought it would be a great time to talk about something that always has admins spooked: authorization.

While Backstage adopters and contributors bring so many different perspectives and organizational challenges, authorization has emerged as a common need — even an outright blocker to adoption — frequently requested by the community.

Backstage has many different authentication methods, but the project currently lacks built-in ways to authorize access to specific data, APIs, or interface actions — these are all visible to any authenticated user.

We’ve heard Backstage adopters share a broad range of authorization requirements: implementations like role-based access control (RBAC), attribute-based access control (ABAC), bespoke logic expressed in code, or integration with external authorization providers.

Our core belief is Backstage’s power stems from its flexibility and customization, so any authorization system should allow for many different authorization mechanisms. Today we’ve published an authorization framework RFC in the Backstage GitHub repository that addresses permissions and authorization within a Backstage application, which we believe provides this flexibility. We’d love your feedback so please comment early and often — the RFC will be open until Friday, November 5.

Our plans for a Spotify-built RBAC plugin

In between exploring Swedish archipelagoes (well, some of us), the Spotify team spent the summer with community members talking about RBAC and the need to make configuration powerful yet understandable. We learned a lot and are in active development of an RBAC plugin for Backstage — which will build on the proposed authorization framework.

However, unlike previous plugin contributions, Spotify will retain ownership of our RBAC plugin and will license it under different terms. To be clear, we’re not backing away from core contributions. We believe the proposed open source authorization framework is suitable for many different permissions needs (but if you disagree, again please comment away in the RFC). We want people to build what works best for them. And we believe our RBAC solution will be a great option among other authorization mechanisms.

Our goal is to be as transparent as possible with this community so we will be sharing more details on the plugin development and distribution plan shortly. Feel free to hit us up on Discord or in the repo if you have any questions in the meantime.