You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the only supported scopes are ScopeAll and ScopeApplicationConnect. With the addition of this issue: #7657, we might want to add a new scope that prevents creating new apikeys/tokens.
This is so an admin can make a token for a user, and that user cannot extend create additional api keys from that. This is just to add control options in the more "headless" usage of coder.
The text was updated successfully, but these errors were encountered:
How do you envision scoping to work in the long-term? Think, one year out? Our auth layer is pretty complex and has been difficult for others to debug, so I think it's worth thinking long-term about adding new features and hopefully simplifying the code on the way.
If we stay with a system of declarative permissions, then scopes will continue to work.
If we move to a new rbac/authz, we will have to convert any of the declarative scopes. I cannot imagine it being too difficult.
The way we enforce scopes now is to just run both the user's perms and the scope's perms through authz. If any return "false" (unauthorized), we reject the call. To be efficient though we do both of this in a single pass.
It's hard to be predictive of what a different authz system can be though.
Currently the only supported scopes are
ScopeAll
andScopeApplicationConnect
. With the addition of this issue: #7657, we might want to add a new scope that prevents creating new apikeys/tokens.This is so an admin can make a token for a user, and that user cannot extend create additional api keys from that. This is just to add control options in the more "headless" usage of coder.
The text was updated successfully, but these errors were encountered: