Hi,
I’m working on an authorization system for my phoenix app, and I need some help designing it…
I want it to be based on roles and permissions, and I also want to be able to create, update and delete roles at runtime and have them persisted in the database.
Permissions wouldn’t change very often as they would imply changes to the codebase, so I think they can be hardcoded.
I’ve seen bodyguard, canary and policy_wonk but neither of them seem to suit my needs so I prefer to roll my own.
This is the approach I would follow:
Create roles and role_user tables for a many_to_many association between users and roles
As the permissions are hardcoded, the roles table would have a column for each of the permissions(ie: a boolean create_post column) or a comma delimited permissions string column. I don’t really know which is better, but I like the latter because I don’t need to run migrations if my permissions ever change.
Write an authorization module that exposes an API like BodyGuard's, for example: Authorization.can(:create_post, user)
Is this, in general, a good approach I should go for? How would you approach this?
Thanks!
Similar to what I wrote at work it sounds like (I really should generify it and put it out as a library someday…).
Essentially what I did was this:
A set of Permission structures (MyServer.Permissions.SomeBlahPermission for example), each of which has at least an ‘action’ field, among other (also a ‘default’ function for displaying in the UI for default values, which are different from default values when instancing it in code).
A can/can? set of functions (and others) that takes an environment (usually a conn or socket or so that grabs the information from a protocol).
I perform a test like:
conn
|> can(%Perms.SomeBlah{action: :list, id: :_})
~> case do conn ->
end
The can? returns a boolean (great for Enum.filter!), the can returns either the environment itself if it passes or an exception structure (not raising it, returning it, I use the Exceptional library a lot, that’s where ~> comes from, it pipes into if the value is ‘good’ otherwise returns it directly). The can's tend to be called many times in a single call so efficient cache’ing is pretty important (it can add an inline cache to the, for example, ‘conn’ for faster lookup on future calls as well so there is no ETS hit too via Cachex)
The permission test in can accesses a Cachex cache that calls into the database. All Cachex caches of a given account_id are wiped everywhere anytime the permissions are written.
The database side stores a json structure of the serialized permission structure, comparisons happen via my permissions_ex library on hex.pm.
Each account_id has an associated set of permissions as well as associated groups, each group has an associated permissions as well, all are combined for the person as well as from some other sources like LDAP and some other information in another database, this is why cache’ing is important as looking up all those sources can easily take a few hundred milliseconds to a second when the other sources like LDAP are being particularly slow.
One big change I’d make would probably make the format in the database a bit different, right now the permissions tables for account_id/group is the account_id/group_id, the structure name, and a jsonb of the structure data. I’d probably change it to allow for direct record comparisons more easily in ‘some’ cases in the database so I wouldn’t have to filter in-code so often, though sadly I wouldn’t actually be able to do that in ‘most’ of my cases because so much data comes from the Oracle and LDAP systems, but would be more useful for setups that are more usual.
But with this style I can test to the logged in user, I can test via a variety of other things, all with simple can/2/can?/2 calls. It’s efficient enough that even looping over 2k records for a report is still less than a second with the database lookup and all, which is significantly faster than the system it was replacing anyway.
On the admin side the permissions are taken a structure to display to the user based on the defaults call on each permissions module, so I can set permissions from the UI in detail. In addition there is a ‘matrix’ view for mass editing of many account permissions via some pre-built sets with ease, all dynamically generated based on the permission structures that are detected in the system (based on their @behaviour module attributes).
EDIT: Oh, also thanks to the permission_ex library there is an admin lookup for easy overriding and a blacklist key for deny’ing, even if other permissions would allow for it. It makes it very easy.
I took a look at your permission_ex, in essence it’s pretty similar to the module I was coding, and I also lookup for an admin permission for easy overriding too
So, if I understood correctly, you store the permissions per user and per group(what I call roles), serialized in a jsonb column, then retrieve every permission for a given user and match against them. As you match against a list of permissions, you can also get permissions from other sources(eg ldap). You also cache the permissions per user to improve performance.
Is this correct?
If so then I think I will go that way, your approach has enlightened me
Right now I’m storing the permissions per group and assigning groups to users, I also wrote a plug that checks in the conn struct for a perms assign and match the permissions list against it. Since the user is retrieved from the db on every request and by extension it’s permissions, I guess it’s a good idea to cache it as you do as an improvement, but I think that overall yes, we’re doing similar things
In essence. I just have Cachex with a fallback function do all the lookups when there is a cache miss, it’s a nice singular place to put it all.
If it’s just hitting the database once per connection it’s not really a big deal to not cache it, I’m mostly caching it because initial lookup can be crazy slow at times because of the way old servers I have to interact with. It’s still good to put it all behind a module API so you can always swap it out with a cache later if necessary without needing to change your API, that is why I pass the 'env’ironment in/out of each function so I can cache on it as well transparently without changing the API.
I just use Guardian.Permissions.Bitwise and add the roles into table hardcoded in a permission field in user table (probably should do many to many like yours). Since I’m using Guardian for token anyway mind as well use their Permissions functionality.
Interesting, I overlooked Guardian because I wasn’t interested in token based authentication and didn’t know it included an authorization module. I’ll take a closer look at it
Guardian is mostly a JWT-style wrapper over JWT or token auth. It’s permissions are simple boolean flags, last I checked (could be changed now) it didn’t support arbitrary permissions on things, like, per-account_id permissions or so, only simple boolean flags.
Well in my case my system far predates bodyguard. I did look at bodyguard when it was released but it was missing features I required so didn’t look further into it, I don’t remember what that was now as it was a while ago. So far I haven’t seen a system that allows the features that I require.
For note, my system easily can do hundreds if not thousands or even magnitudes more of permission checks on a single request in some instances, most systems I’ve seen absolutely crumble under such load (individual checks on students in a class and what access they are allowed on each and so forth).
Because bodyguard only provides an interface. I still need to fetch the permissions from somewhere and I still have to check for the permissions by myself inside a Policy. It seemed pointless to add a dependency that didn’t help at all.
My issue was the structure and storage of roles and permissions: should they hardcoded? stored in the db(like laravel’s Entrust)? How are people handling authorization in their apps?
