02/27/2023, 3:21 PM
We're thinking about adding entitlements-like functionality next to our existing H-RBAC setup that we implemented with SpiceDB. We have an "organization" resource that is pretty central, and entitlements will be available per-org, not per-user. I'm currently trying to figure out if it's more reasonable to model entitlements simply as permissions on that main "organization" resource that we have ("org->use_premium_feature") or as instances of a new "entitlement" definition, have which a relation to the organization and are then queryable via a "entitlement->use" permission on the entitlement resource. The latter feels more dynamic (you can manage the entitlements that exist at runtime) while the former seems more obvious ("entitlement" and "permission" seems like basically the same concept). Any pointers are appreciated if someone has experience with this
After some thought, leaning towards doing it via many explicit self-relationships on the organization, possibly combined with caveats when a feature involves keeping a count of something


02/28/2023, 1:41 AM
what count are you keeping?


02/28/2023, 9:55 AM
E.g. number of users with a certain role (relation to the org), number of certain other kinds of resources created (in a hierarchy below the org, generally)


02/28/2023, 1:01 PM
What authorization decision are you trying to implement with the count? A "seats" feature?


03/01/2023, 3:24 PM
I am curious on this kind of modeling, what if I have to access all the entitlement of user under specific organizations, How do we do that efficiently, lookup APIs returns all the entitlement under all organizations:(