Is Orchid capable of implementing RBAC/ACL?

[matthewmorek]

One thing that I haven't found any info about (and that may be because Orchid is still a very young tool) is how to implement Role Based Access Control (RBAC) or Access Control List (ACL).

Specifically, I'm looking for ways to handle authentication and authorisation in my app using Orchid, for example with Auth.js (formerly known as Next-Auth) or Clerk, but I'm not sure where to even start. There are plenty of tutorials and adapters for ORMs such as TypeORM or Drizzle, but nothing for Orchid.

Would you @romeerez or anyone in the community have any ideas on how to tackle RBAC/authentication using Orchid with some basic examples? I'd appreciate any help, even if just a few pointers or links to things others have done in that area.

[romeerez]

That's right, the auth topic wasn't mentioned in the issues before this, and there is nothing specific for it in Orchid ORM.

For third-party providers such as Clerk, it should be simple enough. For Auth0 I just stored user_id and called it a day, nothing else isn't required to be stored, and RBAC is handled completely by the third party.

Regarding Auth.js (Next-Auth) - why not, it's a good idea to maintain integration with an open-source project. I looked at the drizzle integration with Auth.js and it doesn't seem like a big problem to implement. But only if you're going to use Next-Auth, it's not worth building an integration for Auth.js if it's not going to be used by anybody in the near future and you'll go with Clerk.

You can implement it without waiting for additional features, RBAC is basically a few tables with relations, and Orchid ORM is capable of handling tables and relations.

[romeerez]

Sounds great, thank you for kickstarting work in this direction, I have one in-progress feature for ORM but it can wait and I'll check out what to do for the auth adapter next. I'm on vacation until Mar 13, doing just a little bit of coding, you probably want to build auth for your website asap, I hope it's not a big trouble that it won't be ready soon.

[matthewmorek]

Don't worry about it and get some time off! I only started researching this today, and it's not immediately needed, so I'll continue digging and working on this while you're away.

[IlyaSemenov]

I actually considered the question deeper that it turned out to be (based on the discussion).

In one of my projects, I tried to come up with ACL on the ORM level, which I thought the question was about. That means, when a function runs with certain user in context (such as within API handlers), instead of working with the global db it works with a subclassed user-bound db, where db.table are automatically limited to objects that are "accessible" to the current user, with helper methods such as db.table.canWrite().update(...). This was supposed to reduce ACL copy/paste and prevent potential data leak in case a developer forgets to filter data.

I am not exactly happy with the resulting boilerplate and I'm not even convinced it makes much sense the way I implemented it, so I'm not sharing it; if I have time and energy I'll try to wrap it up and publish (to be honest, I would instead rather happily migrate to someone else's solution, or accept some kind of a recommended recipe).

[matthewmorek]

I think we all struggle with this issue at one point or another, and having even a bunch of simple guidelines for a given framework on how to implement it would be incredibly valuable. For example, how would you go about doing that in Orchid?

All I can think of is having multiple calls wrapped in convenience functions, or maybe using repo feature?

[romeerez]

In theory, ORM could expose some configs to run your functions when selecting, updating, creating, and deleting records for specific tables.

Something like that could be configured to throw an error if a user is not an admin and tries to manage some admin-only table, or if a user is in team A and tries to manage records of team B. But this depends so much on the specific use cases, that I'm not sure if and how it would be possible to make it flexible enough.

On the surface, it seems like you can define canDoX functions, current users with roles and permissions could be passed via AsyncLocalStorage or explicitly as an argument, and all can be done in such a manual way. But, the downside here is manual, so you can forget to add a condition for a user to manage data only inside the team they belong to.

This was supposed to reduce ACL copy/paste and prevent potential data leak in case a developer forgets to filter data.

These are good goals: reducing boilerplate and adding filters automatically based on current context.

I have no idea how it could be accomplished best, should look into powerful ORMs in other languages, do you guys know if this is gracefully handled on the ORM level in other languages?