-
Notifications
You must be signed in to change notification settings - Fork 293
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
LookupSubjects API #261
Comments
I think the client should be able to selectively choose to return the path of all relations/permissions. I like the idea of using a FieldMask here to allow the client to specify to include it or not.
I think so, yeah. This just gives the client more flexibility to be selective about what they want to lookup. This could be really useful if the client only cares about certain subject types or relations. It also doesn't restrict the ability to lookup all, we'll just want to make sure we account for that case. To me it makes sense that if you omit this repeated field then that indicates you want to lookup all subjects for any subject type (and relation).
Yes, I believe this would be a good feature. A lot of permission aware external indexes only need to know about 'view' permission. Common cases for this include Reporting or Search features of a platform. Allowing the client to selectively choose what permission/relations they want to lookup the subjects for would be very valuable for that use case. It also doesn't restrict the user from being more generic instead of more specific, so in that regard it's more flexible IMO. If they don't provide a list of optional permissions then we just lookup assuming all permissions. |
Updated proposal:
|
@josephschorr do we want the
|
Yes, good point. Updated |
Plan after a recent discussion:
|
In our application we need to answer questions like "which users have access to the resource" to know which users should be notified if the resource changes. Currently I'm using the ExpandPermissionTree API and compute the unions/intersections/differences in the application to resolve this. I'm really looking forward to see LookupSubjects API implemented. |
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
…f a particular type for a resource and permission First part of work for authzed#261
Done in #770 |
The Lookup Watch API Proposal includes the addition of the "reachability" APIs, which allow a caller to query the data-driven shape of the permissions graph.
One of the APIs proposed is
LookupSubjects
which would act as a filtered, streaming form ofExpandPermission
, but across an entire object type:All fields on the request besides
consistency
andresource
would be optional, in which case all subjects (of all kinds) would be find for the specifiedresource
.Open Questions
LookupSubjectsResponse
contain the path of all relations/permissions that were traversed to reach a subject? This could be very useful in building permissions panels or auditing systems.optional_subject_type
(and relation) be repeated, to allow filtering to a set of allowed types, instead of a single type?optional_permission
be repeated, to allow filtering to a set of allowed permissions/relations?The text was updated successfully, but these errors were encountered: