I answered myself by reading https://authzed.com/docs/guides/writing-relationships; as soon as you mentioned CQRS, I got what I should do. But the question is. To what extent the Authorization layer WILL have to deal with loading dynamic data and lose being "Side-Effect" free? At some point, I do not have the memory of all the information, having to reach for more SQL/[insert service here] to load data. So in a

perfect

scenario, should somebody optimize for CQRS patterns and have a "centralized" (to some extent) service that has that extra data?

Hey @Yordis Prieto ! 👋I'm not sure I fully understand what you mean, but let me give it a go. I'm making the assumption that you are thinking of integrating SpiceDB in an architecture where Event Sourcing / CQRS is place. There is some information that as you mention, it's not stored anywhere. Think information that comes as part of the request path (HTTP headers, request path, source IP). For that kind of information SpiceDB supports the concept of

Caveats

, which allows you providing that request-specific context as input that guides the authorization decision. Keeping state around of such information wouldn't help, as it's specific to a request being performed. In an Event Sourcing / CQRS architecture, the events with all information needed would be available to various consumers. Consumers listen to those events, and emit other events based out of those, and if needed denormalize that in a way that meets their application access patterns. SpiceDB would be another denormalized form of those Events, and someone needs to build an event processing pipeline that feeds all necessary data into SpiceDB that drives authorization decisions. So in a Event Sourcing / CQRS architecture, the reason data relevant for authorization decisions is not available at request time is different to contextual information like HTTP request headers: it's because the application has decided that data wasn't relevant for their access patterns and did not denormalize it into their own database. It's a tradeoff, but everything that can be stored on the SpiceDB side should be stored there if possible as it's how the "Zanzibar magic" can really happen and unleash its scale. So your point, I don't think the "perfect" scenario is to have an intermediary service that provides data to SpiceDB: I think you make SpiceDB another consumer of Events in your architecture by building an Event processor that transform the relevant data into SpiceDB relationships.

(by the way, I am a horrible writer. I think in pictures; therefore, I do not see words. 😭 , so my apologies if I sound like I am speaking to myself or giving statements, I most likely doubt everything, just my mind speaking) Intent: Understanding decoupling between Authorization Layer and App Layer. I am in Event Sourcing land. For the sake of the conversation, let's assume nothing about Event Sourcing. I am trying to avoid it because it doesn't matter, except that event sourcing forces you to comprehend the situation a bit easier. > I think you make SpiceDB another consumer of Events in your architecture by building an Event processor that transform the relevant data into SpiceDB relationships. Most definitely, take it back from Event Sourcing. That relationship exists in the SQL (for the most part, more assumptions), relationships that you can not avoid having to understand at the application level, so you must make your Authorization layer aware of the "persistence data of such relationship." No other way around it, right?! Unless you strictly do it based on "roles/groups/permissions" and hard-coded policies in the code. But even if you try to be agnostic, the inputs aren't enough to have the relationship you want statically, so your Authorization systems need that data. Right?! So either OPA

data

directive (I think it is) or SpiceDB, where you do-do save the relationship, you need a system that understands such data or can "querying" such data to decouple the authorization from the service entirely. Right?

No need to apologize, everybody has a different way to express their ideas! But not everybody tries to help being understood, so I appreciate that 🙏 I understand the recurrent concern of how to decouple app from authz. And I'm with your, there are not many options unless you somehow come up with a blackbox that is able to infer semantics off your business domain and figure it all out, and even with that, somehow it has to learn how to fetch the data that drive authorization decisions. I personally don't put much energy into the decoupling ideal, even when providers claim they've solved it, because authorization emerges from your business domain and is intrinsic to it. What I really want is a system that really helps me capture that authz-side of my business domain as it evolves over time and help me deliver value to our customers, and it's why I felt in love with Zanzibar. That each time I have to implement a change it does not become a nightmare, but I can really say yeah, we got this. And to know that the system will keep up with the load as the business grows. It all comes with some cost, but I think it's a worthy investment. I'm biased, but being honest, I've built several authorization services in the past, and it all has brought me here.

> really helps me capture that authz-side of my business domain as it evolves over time and help me deliver value to our customers Wooooord > I personally don't put much energy into the decoupling ideal, even when providers claim they've solved it The primary reason I care "to some extent" is because I am trying to provide SDKs for a "serverless" computing style. So picture Message-Passing (Jets Stream) + Middlewares (SpiceDB) where you get to focus on your function that does not care about authz to some extent. The information came from the Message + the relationship created behind the scene. The loose coupling allows me to delegate such policies to whatever the system wants to do, without rearchitecting or redoing the app code.

yeah we have a GCP IAM example in fact: https://authzed.com/blog/google-cloud-iam-modeling

I built one IAM system and I do not want to do it again, back then, I didn't know about Event Sourcing, Event-Driven, and whatnot, I lacked the experience ... so this try, I am falling in love with SpiceDB ...

> The primary reason I care "to some extent" is because I am trying to provide SDKs for a "serverless" computing style. So picture Message-Passing (Jets Stream) + Middlewares (SpiceDB) where you get to focus on your function that does not care about authz to some extent. > > The information came from the Message + the relationship created behind the scene. > > The loose coupling allows me to delegate such policies to whatever the system wants to do, without rearchitecting or redoing the app code. I see, it's an interesting use-case. So you want to build serverless functions that act as a authz middleware so that "business functions" don't have to deal with any of that?

right!

I guess it all boils down to the state carried in the message. That state could be provided in the request payload as

Caveats

, but there could be other state that has been already provided to SpiceDB offband

Right, just wondering about "I dont know what I dont know" and some potential "horrible" architectural problems

I'm unfortunately don't have practical experience with Serverless architectures, but I don't see a fundamental problem a first glance.

(btw, feel free to ignore me, I am trying to search in the docs what I am looking for as we speak, trying my best to find it)

well, it depends on where that data resides. If the ip allowlist comes in the message, then you provide it as part of the Caveat request. But I assume that the most likely scenario is that some previous event was emitted and stored into the Event Store DB, and then via CQRS the corresponding consumers have denormalized that info into their own datastores if needed.

Right, but what about that "Cache/DataStore" that the AuthZ component needs? Could I push the data into SpiceDB so you have access to it? (I am OK with eventual consistency, I love it actually 🙂 )

so no, I don't think you have to load at the app level that ip_allowlist, because somewhere in the streaming pipeline, someone would have written that to SpiceDB

Got it got it, so

When(IpAllowed as e) -> SpiceDB.Write("ip_allowlist, e.ip)

FWIW you can push data into SpiceDB and read from it as any other datastore

(I am gonna end up writing about CQRS, Event Sourcing and AuthZ patterns out of this conversation, I need everyone to strongly understand what I am talking about)

right, it looks like something like that, except that information is added as a "caveat" to some relationships. So it looks more like

WriteRelationships( resource: my_organization, relation: allowlist, subject: user:*, caveat "ip_allowlist", caveat_context(ip = e.ip)

I need to read more about the syntax, for sure. My brain can't tell what is from the cached

data

in SpiceDB and what is pass it. Since you said it is possible, I am gonna ignore the topic until I must deal it it too much info

no problem! happy to help. I can see how it may not be straight when all you have is events. But I think the same basic principle applies as if you were modeling with object-orientation in mind: try to model your business in the SpiceDB schema, and then go from there

https://chat.openai.com/share/e1e7ee7e-ae0d-4fc1-9ba8-1eb7248c5ee5 Also that! I am not sure if you are familiar with Diátaxis documentation framework, but it is extremely helpful.

I'm definitely not familiar with it, and anything that helps us written better docs for the community def helps 😍

nah, it is easier for me to deal with event-driven than not, just needed to know precisely how to answer the question of the "Data Cache" for the sake of AuthZ.

in that case I'd definitely recommend the mantra "write as much as you can to SpiceDB, and only use caveats when data hasn't been previously persisted"

Think about it! I was in the "Task-Oriented" aspect, because the "Understanding" and "Information" is not THAT valuable. Since I have "some" experience I know more and less what the systems do, but I want to know if I can do precisely what I want to do

that's awesome, this looks really valuable, thanks for sharing and being so engaged 🙏

yeah yeah, hopefully I could help even more by collaborating, but such things are probably to talk it out at the project level

just having these conversations is already valuable for us to better serve the community, so once again, thank YOU