https://authzed.com logo
Join Discord
Powered by
Hi is it possible in some way to
# spicedb
m
Hi, is it possible in some way to determine which rule authorized a permission? For example, based on the global admin permissions example (https://authzed.com/docs/reference/schema-lang#global-admin-permissions), is it possible to determine (at check time) whether the permission was authorized by an owner or the platform superuser permission? Or some feature which could be used to create this behavior?
v
is this for debugging purposes, or you actually want a response you can introspect in the client side?
if for debugging purposes, you can invoked check via 
zed
with an 
--explain
flag.
m
the aim is to create an audit log when a higher permission is used
v
the Expand API is kinda what you want here, but does not give you exactly what you are looking for because it returns the entire tree for a specific resource, and not just for a single subject
you could filter it out, but it may be a large tree
the explain data as part of 
Check
response is also available, but I believe we don't provide API guarantees for those (I think they come as part of the gRPC trailer)
@Joey thoughts?
m
explain does seem like a tough solution for this (both in having to scan it, and i assume performance implications)
v
I mean, if you want to retrieve it from the same 
Check
call, that overhead is going to be necessary, unless you want to determine it with a different API call that happens offband
j
@mattw currently, no. its been proposed to return which permission was used to grant access but there is a gotcha with that idea: it may be more than one
if a user was, for example, both a viewer of a document and a platform admin
which is hit is not deterministic
because as soon as one is hit, the other check branch is canceled (since we know the answer)
m
fair enough, i guess that it would be an ok caveat that it returns the first matched if it is deterministic, if thats the case. Anyway I will see if i can reasonably do this with explain
ok i didnt read your message apparently (about it not being deterministic)
j
well, if your aim is to create an audit log for every check
that seems... problematic
because expand is a more heavier operation
much*
m
the aim is to log when some particular permissions are used (eg platform super_admin)
but it would require an explain for every check i suppose
j
yep
and it would be odd if half the time you got the audit logs and half not, depending on timing of the branches (if a user has access via both)
m
yes thats true, perhaps explain cannot fill this use case either
j
your "best" bet might be to have the platform branch be its own check, issue both in parallel, then check the result yourself and log accordingly
m
yeah really i would need to remove the platform super_admin check in that case (and check them completely separately), because i would like to only log when the local (eg not the resource owner) fails
anyway, this was helpful, thank you for the info!
j
you could keep it in the real check
you'd just also issue the check directly on 
super_admin
for the user
and if both come up true, you know they have super admin access (at least)
and log
if they have direct access too, well, that's probably ok
m
i would like to avoid a log in any case they have direct access
v
@mattw im working on exposing payloads via logs, that would expose the full CheckPermissionRequest payload. Would that work for you? since you mentioned all you want is to see the permission used
ah, sorry, Sounds like it does not work.
m
since the checks are not deterministic, probably no solution using spicedbs resolution directly will work
j
yeah; its in contention with performance
otherwise we'd have to run all branches always
which can make things slower
@mattw this might be an interesting problem for a GH issue discussion
because in theory, we could have a decorator that allowed you to mark a particular permission as "auditable"
and have it returned as part of the check BUT there is the contention still with the performance impact
you could also use caveats to hack around this
m
i can turn it into a github discussion, what is the caveat hack?
j
if you made the platform admin relationship caveated
and don't provide the value for the caveat
in the case where we find that branch, we still need to execute the standard branch
so you'd get HAS_PERMISSION if they have direct access
and MAYBE_HAS_PERMISSION for the caveated branch
m
oh i see
seems error prone, and precludes using caveats for anything else
but it might work, thanks for pointing it out
j
well, it is a hack
m
for sure 😄
j
it doesn't preclude using caveats elsewhere, since you could have that field be unique for that caveat
but yeah, hack
5 Views
PreviousNext
Powered by