https://authzed.com logo
Join Discord
Powered by
hey all. I have a question about gui.
# spicedb
p
hey all. I have a question about gui. Are there any best practices that I should be following? I've gone through the language primer. In my case, I don't have documents but rather features. I.e whether a user can CRUD on a specific feature. Would my thinking be correct that the GUI would generate a schema and then that schema is applied to the database? Thanks https://cdn.discordapp.com/attachments/844600078948630559/1200433082197606400/Screenshot_2024-01-26_at_13.30.22.png?ex=65c6296d&is=65b3b46d&hm=7baac2245ff1a19aa2fe85f8a9659634214976aef84241a3bf6b590ddc80f576&
y
generally no. whether a user can or cannot do something should be encoded in the relationships, not the schema itself.
here's a blog post that details how you might build a relatively flexible RBAC system that encodes the permissions in relationships: https://authzed.com/blog/google-cloud-iam-modeling
we're using something similar in our application and it's worked well for us so far
p
thanks for the link. I'm still new to all this. When I meant schema I was thinking of this.
Copy code
definition user {}

definition project {}

definition spanner_instance {
    relation project: project
}

definition spanner_database {
    relation instance: spanner_instance
}
What's the definition for this? Is it permission skeleton as in the article or something else?
y
like you're asking what that block of code is called?
that's a spicedb schema
it defines the kind of objects and relations that you can have in your graph
p
right, so that's what I meant in the OP. the spicedb schema not the db schema itself (if that's what you were thinking)
y
nope, i meant what i said - you wouldn't write a schema to spicedb as a result of user input
p
so i have to hand write out the schema then? 🤔
y
yes, that's typically the case
we treat the schema like any other code at my company
there are two parts of your UI that would be hard to encode into the schema referenced in the blog post
one is the name and description information - spicedb identifiers aren't very long and have restrictions on their charset, and you can't attach arbitrary metadata to a relationship
we approach the problem by having a separate service that manages the role definitions and then feeds them into spicedb using a kafka consumer
the other is having both "allow" and "deny"
the schema in the blog post really only supports "allow" logic out of the box
p
oh wait a second. that ui screen shot was just an example. it's not my use case.
y
oh lmao
p
my use case is generating a schema from a UI though. As my users generally are not technical enough to write schemas. So I will be presenting them with a narrow set of permissions and they will be creating the org -> groups -> users relationships though.
y
right - tha'ts still not information that would be encoded in a spicedb schema
the spicedb schema would encode the meta structure
and then you'd define the roles and which permissions they have entirely in relationships that you'd write within the context of that meta schema
at least if i'm understanding your use case correctly
you wouldn't be able to change things like permission inheritance without writing to your SpiceDB schema
but you'd absolutely be able to set up a user/group/role/object hierarchy
p
alright. i'll start by installing tomorrow and then will go through the language primer video again to gain a better understanding. I'll then build a gui and see where the rubber meets the road. I think I need to experience the problem so I can see where the gaps are. Am I'm trying to troubleshoot and conceptualise the problem that I have no experience in. 😅 thanks for the replies!
y
sure thing! and i'd very much recommend reading that blog post a couple of times
it took me a while to wrap my head around it
p
I will do, thanks for recommending it.
y
@paul7266 are you working on some open source project by any chance? I am trying to create a agnostic Permissioning System Management so I am curious to understand your data schema.
p
I'm working on a startup. It's a commercial application. I've completed the Authentication part and now trying to figure out the Authorization model. I've actually come across https://www.permit.io/ and will be taking inspiration from their UI/UX and then seeing how I can apply spicedb as my own "backend".
I am thinking of open sourcing it btw. Seeing as it relies on open source. To help others tread the same path.
y
Well, we are in the same route, and architecturally, what I am doing is not coupled to SpiceDB (but that will be my only focus***) since it is extremely event-driven, so you can project the relationship to any authorization engine!
We are after the same things here!
p
Only thing is. Right now this is me. 😅 I know nearly next to nothing about authorization. So I'm not going to be of much help. I don't even know what the schema should look like. But I'll have a much better idea once I start to play with spicedb and have a UI in-front of me and start working with both. I want to get to a stage where I implement my vision and I think from that I'll understand a lot of the core principles and complexities. Another thing is next week. I have to start a new project for about 2-3 weeks. But after that. I'll be dedicating my time for a short sprint on this. https://cdn.discordapp.com/attachments/1200433082394759269/1200554908496187412/Screenshot_2024-01-26_at_21.34.35.png?ex=65c69ae3&is=65b425e3&hm=ee56b44af45d064f78111c3dfa0453c5da416be9cf8201b3f125c3875054261f&
y
If it helps you, I messed up 3 full IAM systems, so I dont know what to do, but I can tell you what 
not
to do based on my experience LOL
p
That sounds good. How about we get together after I have reached a milestone of implementing, however poorly a GUI with spiceDB and then compare notes?
y
I am in your Slack channel now, I love to see others working on the same things
p
What Slack channel. I don't have one. 🤔
y
For sure, I already have one big concern looking on what you are doing, a minor one, but important, and it is around your 
check
function
p
I'm not affiliated with Permit in anyway.
y
aaahh
I am an idiot
p
I'm merely taking inspiration from them. for the UI
y
Well, do you want to work on something similar to them?
After 9 years in React and a decade+ long web, I do not want to do GUI anymore LOL, but I love doing backend stuff!
p
I love working on the front-end, even built my own UI library. So for me, knocking up something similar is a breeze. I'm full stack and devops btw 😄
y
Since you are learning from permit.io, here is the biggest architectural red-flag. that 
permit.check
function is extremely dependent of the Authorization Engine (SpiceDB), so the more abstract and "fit for all" you make it, the less valuable it is compared to use SpiceDB directly! Another word, that is not the way to go. This topic is splitted into two parts: - Permission Metadata Management (your GUI, API around the management and so on) - Authorization Check (SpiceDB, dont touch it, use SpiceDB directly IMO) https://cdn.discordapp.com/attachments/1200433082394759269/1200557739357786224/Screenshot_2024-01-26_at_4.46.04_PM.png?ex=65c69d86&is=65b42886&hm=bb558047abc3977f163e465473bc7865f64b099fe3a48283548f6909215443b9&
p
Ok. These things right now don't mean anything to me. 😅 Like I say, it's probably better to reconnect after I've spend some time with spicedb and have something working.
y
I sent you a friend request (your list of server you belong to is almost the same as mine LOOL) so feel free to reach out. Hopefully I can help you with your journey and connect the dots together!
p
Accepted and appreciated! Will definitely be doing so!
y
Nice
What are you using for the Frontend?
4 Views
PreviousNext
Powered by