Add `registrar` Role

[danielballan]

Summarizing discussion with @dylanmcreynolds

---

In Tiled, a Role has a list of Scopes (e.g. read:metadata, read:data, etc.). Principals are in a many-to-many relation with Roles, and Roles can be added (via SQL query) dynamically to customize deployments. The union of the Scopes of a user Roles sets a boundary on the actions they can take, as each FastAPI endpoint in Tiled is protected with a list of Scopes it requires. Individual API keys can be configured with a narrower subset of Scopes. And Access Control Policies can further narrow that subset for a given Node.

Tiled ships with two Roles by default, user and admin. Currently, the register scope, which tells the server to expose a local file as an Asset served by Tiled, is available to admin but not to user. We propose adding a third role, named registrar, with a list of scopes just one item long: ["register"].

Since a Principal can carry multiple roles, a user or service that needs to register Scope, can be assigned the Roles user and registrar.

Alternatives

• "Why not just add register Scope to the user Role? It already has write:metadata and write:data." When a client writes data, they are asking Tiled to store data that they already have (and are uploading). When a client registers data, they are asking Tiled to expose a file. Even with multiple protections in place, there is a risk that some misconfiguration might enable a client to expose a file that should not be exposed. Therefore, it's useful to be able to grant this scope specifically to clients that need it, not to all.
• "Why not just use admin for this?" The admin Role can perform other powerful actions, like create Service Principals and mint API keys on behalf of other Principals. It should be possible to grant register Scope without also granting these more powerful Scopes too.
• "Why not make a separate Scope like trusted_user (or some such thing with a better name)?" Principals are many-to-many with Roles, specifically to enable mixing and matching.

[padraic-shafer]

You've sold me on this.

Would it be reasonable to add a prefix to the scope's name, such as admin:register to convey they gravity of the scope?

[genematx]

I think the justification in bullet points makes total sense, and i really like Padraic's idea to help bring attention to the gravity of the Scope. I just want to flag a boring grammar issue: should the Scope's name be formed as <verb>:<noun> to be consistent with what we have already? (although, I understand this pattern doesn't match the rest of exisiting Scopes.)

[danielballan]

Per a long-ago discussion with @tacaswell I think there is a path to restricting what the register scope can do via an AccessPolicy. If that happens, it will not really be an administrative capability. I would like to let that idea cool before we rename it, and leave this as a “maybe” for now.