Allow non-superuser admins to create new API sub-scopes #135
Assignees
Labels
Comments
GUI
added a commit
to NREL/api-umbrella
that referenced
this issue
May 22, 2016
- Allows limited admins to create sub-scopes underneath their current scopes (18F/api.data.gov#135). - Allows limited admins to create new groups utilizing the scopes they have access to (18F/api.data.gov#339). - Fixes potential security issues where a limited admin with knowledge of internal record UUIDs could overwrite records they didn't originally have access to with data they do have access to. Since this hinges upon knowing the random UUIDs of the records the admin doesn't have access view, this hopefully shouldn't be likely. - Refactor most of the admin permission tests to ensure better consistency and coverage. There's now a shared baseline of permission checks we can easily apply across all admin resource types to ensure basic permission checks. The same permission checks are also now tested across all CRUD actions (rather than requiring different tests be written for each CRUD action).
GUI
added a commit
to NREL/api-umbrella
that referenced
this issue
May 22, 2016
- Allows limited admins to create sub-scopes underneath their current scopes (18F/api.data.gov#135). - Allows limited admins to create new groups utilizing the scopes they have access to (18F/api.data.gov#339). - Fixes potential security issues where a limited admin with knowledge of internal record UUIDs could overwrite records they didn't originally have access to with data they do have access to. Since this hinges upon knowing the random UUIDs of the records the admin doesn't have access view, this hopefully shouldn't be likely. - Refactor most of the admin permission tests to ensure better consistency and coverage. There's now a shared baseline of permission checks we can easily apply across all admin resource types to ensure basic permission checks. The same permission checks are also now tested across all CRUD actions (rather than requiring different tests be written for each CRUD action).
GUI
added a commit
to NREL/api-umbrella
that referenced
this issue
May 22, 2016
- Allows limited admins to create sub-scopes underneath their current scopes (18F/api.data.gov#135). - Allows limited admins to create new groups utilizing the scopes they have access to (18F/api.data.gov#339). - Fixes potential security issues where a limited admin with knowledge of internal record UUIDs could overwrite records they didn't originally have access to (by overwriting the original record with data they do have access to). Since this hinges upon the limited admin knowing the random UUIDs of other records they don't have access to view, the likelihood of this actually being exploitable should be low. - Refactor most of the admin permission tests to ensure better consistency and coverage. There's now a shared baseline of permission checks we can more easily apply across all admin resource types to ensure basic permission checks. We also now perform the same permission check tests across all CRUD actions (rather than requiring different tests to be written for each CRUD action, which was easy to miss and difficult to maintain).
|
Fixed by NREL/api-umbrella#238 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the new admin permissions system rolling out, there's the concept of API scopes that admins can be granted access to. For example, I could be granted full access to just the
api.data.gov/nrel/scope. This means I could manage or create any APIs withinapi.data.gov/nrel/*, but I could not create or mange APIs anywhere else (soapi.data.gov/something-elsewould be off limits).Right now, only superusers can create API scopes (defining what hosts/paths agencies have ownership over and setting that up will be part of getting new agencies setup). However, in the future, it might be handy if agencies admins could then define their own sub-scopes, as long as it's within their current scope. So, for example, if I have ownership over the
api.data.gov/nrel/scope, then I could create a newapi.data.gov/nrel/transportationscope and then I could create new admin accounts that only had access to that area. This would allow a higher-level admin at an agency to segment off and manage their agency's permissions themselves.Right now, I think the API scopes will predominantly be used by the api.data.gov team to setup initial API scopes for new agencies (since we need to be involved in at least the very first step of picking what host and path each group has ownership over). However, if there's demand for agencies managing these types of permissions and sub-scopes themselves, allowing them to do so is certainly doable. Most of the pieces to do this are already there, we just need to allow these users to create new API scopes, but ensure the new scope is a child of their current scope.
The text was updated successfully, but these errors were encountered: