hi all, I'm trying to buld a POC on how we could move on from keycloak + local spring-security ACL. It seems we have a more complex use case, especially hierarchy. I have the following problem: workspace -> unit. now the unit id is only local, meaning that in another workspace, we could have a unit with the same id. so how do I make sure that the access is only workspace:1 -> unit:abc and not workspace:2 -> unit:abc? is there anything I can do while checking or rather when architecting? this is what I have now: https://play.authzed.com/s/cape0z6EldLP/relationships (and this would also apply to bank accounts, documents, their statuses and categories 😉 ) PS: love the DX btw, I tried keto before, but wouldn't get answers or a sales cale lol. the tools to build it yourself and docs are awesome!

Hey there! I'm not sure if the resource IDs you are writing have any restrictions in your application, but one idea would be to concatenate the workspace ID.Something like:

unit:<workspace_id>_<unit_id>#parent_workspace@workspace:<workspace_id>

Would be curious to hear what was limiting about keycloak's authorization functionality that didn't support your use-case (I'm largely unfamiliar with how it works)

thank you! that's the solution I came up with, yes. we use keycloak for authn only actually, the authz is implemented with spring-security ACL and is a shit show (and local to the backend anyway)

@chrschu yeah feel free to book us via the website!

you mean "authzed introduction"?

you can book a call

yeah, that's what I meant, thank you! sounded like a really sales heavy call, but as I can provide a "play.authzed" link it could be enough! awesome