Feature #20640
Updated by Peter Amstutz 7 months ago
Requested by user: They would like to synchronize permissions set in Arvados to another system. This system does not support OpenID, users will log in with LDAP and they can do a mapping between username and arvados uuid. However it is not convenient to generate and use Arvados tokens in order to do permission lookups on the fly. Proposed solution is to have an admin API where the client can send a list of users and/or projects and get back the permissions associated with each user and/or project. This would make it possible to write a policy plug-in that queries permissions for a given user or project from Arvados on demand applies them to the 3rd party system. Design sketch: Implement a "list" API that behaves similarly to other list APIs, supporting our filter syntax. It return a list of items with the user uuid, target uuid, and permission level. The permission level is numeric internally but it might make sense to transform it to can_read, can_write or can_manage for the external API -- because if we ever want to tweak the implementation or introduce new types of permission, it would be better not to be committed to a specific numeric representation of permission. Since it is read only and rows don't have standalone identifiers, the endpoint would only support "list" method and not "get" or anything else. It should be usable by admins only -and regular users.- Admins have unrestricted access. -Regular users are limited to permissions for targets which they have "manage" access (this includes "self" so they can always see their own permissions), implemented as a self-join on the permission table.- h2. Detailed design endpoint: /arvados/v1/materialized_permissions User accessing the endpoint must be admin, otherwise returns 403. h3. Fields |Field|Type|Description| |user_uuid|string|user account that has permission| |target_uuid|string|target of the permission| |perm_level|string|one of "can_read", "can_write" or "can_manage"| There is an additional field 'traverse_owned' which records whether permission should be transitive through this target. This is important for table updates but clients shouldn't be doing any reasoning about permissions, so I don't know if this should be returned or not. h3. Methods *list* HTTP GET with query parameters (in the URL or body, as supported by every other endpoint). All other methods (PUT, POST etc) return method not supported. Any paths under the endpoint return 404. As with other endpoints, GET with no parameters yields default behavior (query result with default limit, count, order, select, with no filters). It should be possible to enumerate the entire table if you really want to (but this could be millions of entries, which is why you'd normally use a filter). |Argument|Type|Description| |limit|integer|same as other API methods| |count|string|default 'none', only accepts 'none'| |order|array|same as other API methods| |select|array|same as other API methods| |filters|array|same as other API methods| * Returns materialize_permission objects in "items" same as other list APIs * If a (user, target) combination isn't listed that would have otherwise matched the filters (and all pages have been fetched) no permission exists. * perm_level isn't indexed, including it explicitly in a query may cause a table scan, we should disallow filtering or ordering on it. * I'm omitting "offset" because it is not needed for keyset paging * several fields are of limited use, but I propose including them here so that the Python keyset_list_all method can be used to query permissions. ** keyset_list_all does assume assumes the the record has a 'uuid' field, it should be tweaked to allow specifying an alternate tiebreaker field Providing this list method This gives the client the flexibility to query permission of individual users and projects, get all permissions of a single user, or get all permissions on a specific project. This also allows us to use our existing code to construct the query. Even admin-only, the ability to get a list of every user granted access to a specific project is something that would be useful to add to Workbench. As a future extension it could allow regular users with can_manage access to a project to query the list of users with access to the project.