We currently authenticate a user and they receive ...
# spicedb
s
We currently authenticate a user and they receive a jwt token. The claim has a "permissions: [ $namespace:$role ] " which is populated by whatever group memberships you are in. WIth SpiceDB our app / operator would use WriteRelationships() to create groups and put users into groups and in our app only need to pass the User to CheckPermission to authorize or not ? Trying to make sure I understand that instead of putting folks into Groups in our Authentication system, we'd do that in Spice. The only thing needed then in CheckPermission would be the users identity, not their groups / roles or anything from outside system?
v
That'd be correct. You need to store in SpiceDB all information necessary to perform authorization decisions, and if you business domain includes the concept of group, then that needs to be part of SpiceDB's schema. Your application would be responsible of calling
WriteRelationships
to SpiceDB, and then when an authorization decision needs to be made, you only need to provide the resource ID, the permission to check, and the subject ID (in this case your user ID). If you application need to to know if a user was member of a group, you can also do that with SpiceDB
s
Do I need to Sync my group memberships from LDAP / External Systems into SpiceDB or is there some pattern for using that data at Check Time?
v
you need to sync it. SpiceDB is designed to follow Zanzibar's architecture to scale, and for that data needs to be persisted. We do support dynamic policies using a new functionality called
caveats
that allows you to provide context at request time, but is not the right tool for LDAP group membership.
s
I'll read some more about Caveats, https://authzed.com/blog/caveats/
Interesting, so this would be useful for things like evaluating tags? for example
Maybe another "Modeling AWS IAM in Authzed" would help demonstrate Caveats 🙂
those 2 videos were very helpful
v
yeah, tags would be a potential use-case
3 Views