Hey all! We are doing research on implementing a S...
# spicedb
b
Hey all! We are doing research on implementing a SpiceDB as our Authorization system. We have encountered some specific challenges that we'd appreciate guidance on. As an example, let's say we have a database with with 100 million records. Each record contains multiple attributes - some are default (built-in) and others are custom (user-defined), with a maximum of 512 attributes per record. The core requirement is to implement access control that allows users to list and view records based on specific attribute values. For example, one user might need access to records where country=NL, while another user needs access to records where foo=bar and baz=3. We initially considered implementing this using relationships with caveats, similar to the approach outlined in the Netflix paper. However, this presents two significant challenges. First, we would need to create individual tuples for all 100 million records with all of their potential 512 attribute, and since this data constantly changes, maintaining these tuples would create substantial overhead. Second, we need to have our own search functionality, and it would be difficult to efficiently compute the intersection between records matching search criteria and records the user has permission to access. As an alternative solution, we're considering creating a single relationship with a caveat per user that contains their allowed attribute filters. Our service would query SpiceDB for the relationship/resource and its attributes (ReadRelationshipsRequest?), then use these attributes to augment search queries (for example, by adding AND country=NL to the search criteria). We're curious whether this architectural approach seems viable, and if there might be better solutions we haven't considered. This seems like a common use case, but we haven't found much discussion about handling attribute-based access control with your own search with SpiceDB. We would greatly appreciate any insights or alternative approaches :-)
5 Views