I had a look at Casbin in the past, in search of a Go equivalent of Ruby's CanCanCan. But Casbin looks way too complicated to use. So in the end I wrote my own unreusable, poor man's version of CanCanCan in Go specifically for use in my app (with lots of boilerplate and duplication because Go has no generics).

Does anybody else have a better experience with Casbin, or have recommendations on a CanCanCan-like alternative for Go?

I’m currently building a service and I’m using casbin for authorization. So far so good, but my requirements at the moment are fairly simple. This will change in the future and it’s one of the reasons I picked it: it’s easy to evolve the permissions layer without changing almost any code.

In terms of my experience so far it was a bit tricky at first but once I grasped the concept it became easy to integrate.

Most of the blogs with examples I found were in Chinese and the documentation is sometimes confusing to read, so you may need to overcome that part.

A few weeks ago I learned about Oso[1] which looks really nice but I haven’t tried it yet. They publish some nice posts about the subject in their academy[2]

[1] https://www.osohq.com/

[2] https://www.osohq.com/developers/authorization-academy

Usually I’m not a detractor, but recently we evaluated Casbin and I would not recommend anybody to use it.

Some factors where merely psychological, such a mistrust due to misleading partners listed in the website that should use the lib.

For instance one logo is the one of SpaceX, which sadly is just a user group, nothing official. Another mention is Google which I didn’t find any relevant code that gives a hint that Casbin is used by Google in production.

Someone mentions shortcuts in codes; well didn’t got the time to find back all the notes.

But we find several bugs mainly in the implementations that lead us to look somewhere else.

We end-up with CASL.

That doesn’t mean that I don’t like to use Casbin, but already cost me to much time of debugging.

But let me leave with a disclaimer for a later me:

Code mutates like nature does, what it might be true today might be false tomorrow and viceversa, and if you got the time to improve it, just use it.

Don’t get bend by this merely opinion and just investigate and form your own, and always give a second chance, because times changes everything, and sometimes nothing changes.

Agree. I ended up going with https://www.openpolicyagent.org/ - it's way, way, way easier to use and integrate with. Policies read better. They're easier to write. They're individually unit testable. The API for OPA is better. Generally I'd recommend OPA over casbin in a heartbeat.

What other solutions did you look at?

OPA, Casbin, Keto (ORY), CEL from Google.

I also evaluated it and implemented an ABAC system for our Node.js app with Casbin in a day. The tooling wasn’t perfect and I probably took a shortcut or two, but I didn’t see any red flags that’d actively make me recommend others not use it, so I’m interested in what you found.

Can you enumerate why no one should use it?

We gave it a try, but got rid of it because we couldn't make it perform well for our usecase. This was quite specific to the implementation and matcher that we used (pycasbin + keyMatcher), having just a few thousand rules ruined our API response times.

I would like to know who uses this and how. It seems like deploying Ory Keto would be much better for web applications less you really need this like for a desktop application or something.

We're actively evaluating this, particular b/c: Open, dynamic acl+rbc = modern google-docs-style policies for regular webapps, postgres adapters = no change in operations (vs keycloak, orly, ..). That's been a fairly unique combo. However, we're still doing our own eval because we saw concerning issues in the gh around perf+correctness, and it's not obvious how to use it.

Curious on other experiences / alternatives. Ex: We're trying to keep the CMS parts of our stack especially boring, so django/postgres/casbin is surprisingly tight, while DB backing of a user's/org's custom ACL/RBAC sharing rules in say OPA seems more like a science project (despite looking like a great project when zoomed out), based on the docs (https://www.openpolicyagent.org/docs/latest/external-data/)

The casbin<>db integration decision was pretty wise, vs the continuing trend of policy engines bringing their own infra, and thus 'the tail wagging the dog'. I'd love to see someone figuring out RBAC/ABAC+ACLs as DB-native ~RLS, instead of having to introduce an extra moving piece of infra for every DB query, when the DB is right there!

I tried this too. lots of flexibility (that we never needed. then had to fiddle with DB adapters, docs weren't great so had to step with debugger to sort it.

its a neat design, its a nice promise but more of a reference for building the tightly integrated RBAC (or whatever) that you need.

It seems there are a number of emerging solutions to this problem. Casbin, Ory, and Keycloak come to mind. Has anyone tried multiple of them? I guess the nature of the beast is you probably only use one...

My main concern is stability, e.g. will this project be around in three years, and if not, is it grokkable and stable enough that the community could understand and maintain it?

We ended up rolling our own authn (kind of regrettable, but at least gives us some predictability and one less thing to update) but have not yet implemented authz.

Would be curious to hear from anyone who's recently chosen between these options (or others) and is happy with their choice.

Keycloak isn’t really for authorization. It’s an openid connect provider so it really does authentication (identifying who the user is). Maybe they’ve been adding features to make it better or you can shoehorn some authorization into the jwt token that your app uses, but that’s generally not a great way to use it.

That's incorrect. Keycloak comes with UMA2 implementation which is for authorization. There is the whole concept of authorization services in there. I have written about it here: https://gruchalski.com/posts/2020-09-05-introduction-to-keyc....

Keycloak is developed by Red Hat and is the safest bet (with the best documentation)

And works really well!!!

I had a nice experience in building a multi tenant system in which RBAC was done by Openpolicy Agent(OPA)[0].

Our data model was N Level hierarchies of entities for each tenant and these hierarchies followed inheritance for roles.

We made some policies in OPA and the membership data was present in the DB which was sent to OPA at startup. Then any diff made in membership was subsequently also sent to the OPA as well.

[0] https://www.openpolicyagent.org/docs/latest/

Did you use OPA as a sidecar or a separate service? I have a similar setup but with a separate service the "diff pushing" approach adds quite some complexity, due to OPA and the data source having separate lifecycles.

It was a separate service. The other service, that was using it, was a monolith.

We used Casbin at my previous company where we needed to implement RBAC on top of our API that was written in Go. What we liked about it was that it could be embedded directly in our main application without needing to administer an external system. It also helped that we were using Postgres and redis as part of our stack as the casbin plugins for those tools made policy storage and enforcer updates dead simple across our API nodes.

This looks appealing as a framework for using in IAM for applications with federated auth. Given historic legacy alterantives are lower level policy frameworks like RADIUS/TACACS, SAML, XACML and UMA2, what are the objections to Casbin?

A library you can build into your application for doing policy AuthZ without having to deal with a centralized policy repository, while moving AuthN to your IAM gateway is a huge deal in enterprise envirionments.

I wish people would stop saying authz instead of authorization.

Since it tends to be used in the same sentence as authentication, and the differeces are both subtle and hugely important, the visual Z vs. N is helpful, and even pronouncing it is helpful to maintain the distinction.

They are so easy to conflate that it can create a lot of confusion whereby a semantic difference quickly becomes a category error.

I don't find the two words easy to mix up at all. Does anyone, really?

Auth-oriz-ation

Auth-entic-ation

You give one glance to the middle of the word and it's clear. Maybe an ergonomic argument could be made like the case of internationalization/i18n and localization/l10n

I think the price is too steep though, for auth[NZ] and [il]1[08]n. Maybe I'm just old and curmudgeonly.

“Permission” vs “identity” while not perfect is at least more distinguishable...

I'd tend to agree, though since they are terms of art that are technical concepts instead of business level permission and identity, we haven't been able to do much better in the field. IDPs, RPs, PDP/PEP's define them a bit more as architectural terms, but the security field has a convention of creating stupid and unnecessary abstractions.

The reason is twofold. The first is that the field claims origin in compartmentalized military intelligence culture where code words were used to manage compartmentalization, and in-effect, maintain a necessary level of ignorance between projects, which is as tediously bureaucratic and immensely irritating as it sounds. The second is the business runs on stories, so if you can abstract a dynamic into a new quirky name, you can claim to have discovered it.

So yes we should have better words for things, but being better at what we do would risk solving a problem that too many people make a living managing, and so, here we are. An industry of internet duct cleaners.

graphs solve all these problems