Multi tenant filtering protection
matt-psaltis opened this issue · comments
Picked up this library for the first time today - loving it!!! Great work to all involved. :) thank you!
When building a multi tenant solution it's easy to forget to manually apply the correct filters to all vertices and edges. The ability to apply global filters based on a specific key so that data is guaranteed to be limited to a specific tenant reduces that risk.
Is there a way to currently achieve this?
I would typically implement this by walking the ast and visiting the appropriate expression nodes. Is there a more elegant way that you could suggest? Would you be open to a PR for such a feature?
Cheers!
Can you elaborate ?
Sure! We store data into a shared Cosmos DB collection for multiple clients. We then have custom Vertex and Edge classes (implementing IVertex and IEdge) with a string TenantId property on them. This property denotes the particular client that the data belongs to. When doing a lookup, the developer must currently ensure they add a Where clause to constrain the search results to the specific tenant that the user is assigned to. For example g.V<Blog>().Where(x => x.TenantId == user.TenantId); As an example, Entity Framework implements this using Global Filters: https://docs.microsoft.com/en-us/ef/core/querying/filters
So what I'd like to be able to do is execute a query like g.V().Where(x => x.Age > 30days) and have the tenant where clause automatically applied based on some additional context coming from HttpContext.User for example. Additionally this would extend into more complex queries so when traversing edges to other vertices the tenant filter is also applied to anything that inherits from our Vertex and Edge classes (we do have some situations where the graph edges interconnect tenants because of company merges etc).
Any thoughts on how I might go about layering this into the ExRam.Gremlinq ecosystem? Is this something that would be a useful inclusion?
This sounds a lot like subgraph strategies. Unfortunately, neither does CosmosDB support subgraph strategies nor does Gremlinq currently support establishing strategies on queries. The latter has to with there not being a clean way to translate every subgraph strategy in bytecode to an appropriate groovy representation - and CosmosDB doesn't support bytecode yet.
So it would be could to tackle this somehow. I would definitely review a PR but the approach would have to be abstract and general enough to not just serve as a temporary workaround for the lack of CosmosDB features, but instead still provide value when these features are eventually established.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.