Hello, Is it possible to integrate SpiceDB permission checks into an HTTP middleware layer within the business system, without modifying any existing business logic or code

👋 yes, it should be. Are you looking for support for a particular framework? What's your stack?

Thank you for the response! The challenge I'm currently facing is how to integrate SpiceDB for permission checks with minimal changes to the existing business code.  If this is possible, what would be the best practices for the interaction between the frontend and backend

It depends on your application. But you can't expect a few one liners. Can you tell me more about the architecture and stack you are using? You can put this as an API middleware in your backend, which issues a

CheckPermissions

call against SpiceDB. You also need to feed SpiceDB with the relationship data needed to compute permissions. So you need to model your schema after your business domain, and decide how you are going to feed that data.

Thank you for your insights! Currently, our architecture is structured into three layers: 1.API Layer: This layer consists of gRPC and GraphQL, which forward actual queries to the second layer. 2.Service Layer: Built using the Service Weaver framework, this layer contains microservices that call functions generated by SqlC to handle the actual queries and return results to gRPC and GraphQL. 3.DB Layer: This layer interacts with the database using SqlC. I'm uncertain about where to integrate SpiceDB's permission checks. Based on the documentation regarding CheckBulkPermissions (https://authzed.com/docs/spicedb/modeling/protecting-a-list-endpoint), it seems like the checks should be implemented in the second layer. However, this may require significant modifications to the existing business logic. Could you please provide any recommendations or best practices? I would greatly appreciate your guidance!

IMO the ideal place to implement this is the Service Layer, as it gives you the guarantee that nothing from the API Layer can bypass authorization. It's always important to build authorization checks as "centralized choke points". Doing it at the API Layer could lead to different callsites accessing the same data potentially diverging. Some companies have even done the authz checks at the DB Layer: you must be authorized to retrieve the business objects. That is also a good approach although it may relevant context needed for the authorization check. I don't have hands-on experience with Service Weaver and it highly depends on how you architecture the application, but I think it would be safe to suggest that authorization checks should be strategically laid in the public interfaces of those services, as pressumably this is built as a "modular monolith" and each component will have a API. That's where I'd put the checks. You could come up with some reusable component that all teams should built upon to automatically enforce checks. E.g. if you define a new API interface, you can define it using these reusable components that automatically wire up the authorization scaffold, which you then customize. Or you could infer the authorization check transparently out of the API signature. For example if you have a

Book

type, and that type has a

view

method, then you can transparently turn that into a SpiceDB

CheckPermission book:my_book#view:user:current_user

. If you have something like

book:all

then you can use SpiceDB

LookupResources

to return all books the user has access to. Unfortunately there is no magic spell I can give you right now to transform your application into a SpiceDB-enabled application. That's why it's always a good idea to start thinking about authorization early, as the costs of migrating explode later on with the size of the application and engineering teams involved.

@meifannao you're also going to run into the issue that it's hard to dissociate the authorization for list endpoints from the logic of those endpoints

Yes, this issue seems unavoidable. As it stands, the only viable solution appears to be combining authorization with data retrieval.

i'll point out that that's already true - in a list endpoint where authorization is managed by the application database, you're doing JOINs to determine which things a user is allowed to see

Another point for not putting authorization checks in the API gateway is that it only secures the API when you really want to secure any data egress. A common example that I’ve seen is you may end up with some service for emailing out account updates or reports. In this scenario you would still likely want to make sure the recipient has access to the data you are sending them. If you make the data-owning service responsible for checks then you’re less likely to miss this.

I understand how to integrate SpiceDB into my system now. Thank you all for the guidance!