This message was deleted.

Hello Duarte, The short answer is that RBAC still requires some work to define for your use case. As Patrik states in this comment:

Yes, you can build RBAC using OPL, and configure it as needed. This issue is rather about having an “official” way to do RBAC.

So you are defining your “flavour” of RBAC as it fits your use case using the Ory Permission Language. It would be more ideal to have a “official flavour” of RBAC, hence the sign in the document. (we should probably change that to “info” since there is no danger involved) I will see to also get a comment from the devs on it.

Hey Vincent, good to hear from you 😉

It would be easier than implementing it yourself for sure. If you need very fine-grained permissions then Keto is well equipped for that, since tenants is a big part of your use case, you likely need a custom RBAC flavour anyway.

makes sense, but was trying to avoid having that inside the apps

Right, I remember talking about that with you.

trying to avoid having that inside the apps

for sure, Ory Permissions/Keto would act as your central permissions server handling all authz accross tenants. You will probably create a namespace for every tenant.

not sure we even need it, users can hop between different domains with the same account

Hmm in that case you might be able to get away with using public metadata in the identity service. So you could have a simple role in the public metadata and get it together with

/whoami

session check.

and the permissions on our side?