Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add registrar Role #741

Open
danielballan opened this issue May 10, 2024 · 2 comments
Open

Add registrar Role #741

danielballan opened this issue May 10, 2024 · 2 comments

Comments

@danielballan
Copy link
Member

danielballan commented May 10, 2024

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
Copy link
Contributor

padraic-shafer commented May 10, 2024

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?

@danielballan danielballan added this to the v0.1.0 release milestone May 10, 2024
@genematx
Copy link
Contributor

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants