4 ms·
Why does it need to be checked on a per-request level? I'd expect you to be able to give short-lived capability tokens to clients that each machine can verify
by dietr1ch 3y ago
Why does it need to be checked on a per-request level?
I'd expect you to be able to give short-lived capability tokens to clients that each machine can verify down the stack without making new rpcs. This would avoid the fan-out of all the internal services.
Is it just to prevent abuse?
- AlphaSite 3y agoDoes the token identify every resource you have access to? I think is for multi tenant applications with fine grained access control.
- paulddraper 3y ago"Oh, you just [insert complex solution here]" You need one capability token per principal and resource and perhaps access right.
- akajla 3y agoYou can encode capabilities/permissions as scopes in distributed tokens (e.g. OAuth) but this can start to break down if you have very granular, fine-grained permissions (e.g. user:1 has 'editor' access to 1000s of documents/objects). This is similar to the problem that Carta ran into while building out their permissions[1]. In addition, yes - validating permissions on each request makes it so that you can revoke privilege(s) with immediate effect without needing a token to be invalidated. [1] https://medium.com/building-carta/authz-cartas-highly-scalable-permissions-system-782a7f2c840f https://medium.com/building-carta/authz-cartas-highly-scalab...
- deleted 3y ago[deleted]
- smarx007 3y agoI think it's best to refer to the Zanzibar paper: https://www.usenix.org/system/files/atc19-pang.pdf https://www.usenix.org/system/files/atc19-pang.pdf
- zcw100 3y ago... or the annotated one from the Authzed folks https://authzed.com/zanzibar https://authzed.com/zanzibar