enforceSync & loadPolicySync for non async sources.

Hello, thank you very much for this powerful piece of software. I read the PML paper with pleasure. It does describe the concept very clear and by doing that even helps to explain the main differences of ABAC/RBAC/ACL. I’m impressed, thank you! 💪

I would like to use the core parts (Enforcer & Model) for a frontend project. For this I don’t need any async handling yet. The model is defined in code and the policy is loaded from a string. That’s it. I expected to find sync variations for enforcer.enforce or for enforcer.loadPolicy. This would reduce the runtime complexity as I don’t have any async sources involved.

The underlying fs supports sync file access, so a generalized loadPolicySync and enforceSync should be possible. The DB adapters could have the same but I don’t have the bigger picture to judge this.

What do you think?

[georgiee]

I just wanted to give a perspective how we proceeded as our business needs did not magically disappear with the knowledge that casbin will not work as a sync library. I also see and respect the maintainers decision not to support real sync usage. We are currently not able to opensource our solution but we want to go that direction with our client. Until then this is maybe a motivation to build your own engine. Yes it was a lot of work and a lot of reading but it was a fun journey with great success. Trust your cherry picking skills to extract the parts from casbin you need to get started pretty quickly into a sync world of policy evaluation before being stuck 💪

I’m still very thankful to casbin that they opened up the world of ABAC, ACL & friends to me with the code base being open source and very readable.

---

Here our story so far:

1. We cherry picked the crucial parts from casbin and build our own minimal engine with it but being sync in the core (parser, enforcer) and expose (optional) async capabilities only in the querying API (for sync or async canShow, canEdit etc, see https://github.com/casbin/node-casbin/issues/152#issuecomment-625063934). I wrote this myself within a few days. I could not find any valid alternative to casbin. I encourage you to go this route if you feel being stuck with some async/sync workaround or searching for too long for another solution.

2. We relied on the enforcer, the policy parsing and we cherry picked only those parts from the flexible casbin model/policy building we needed. We have no interest in changing our policy model frequently. This solution worked good enough to validate that we are going into the right direction of having a ABAC-like policy in the frontend to orchestrate our business needs (mostly view & edit capabilities).

3. Fast forward 6 months. People happily adapted our small library. We improved it on the API/consuming side and also offered some great policy editing UI to modify the policy during development like add/remove or disable/enable rules, change actions & resources or change the order of rules.

4. The casbin legacy code begun to stand in our way. We decided to ditch it entirely and use our gained knowledge to provide a proper rewrite without any leftovers from casbin. We did that on the basis of the XACML standard outlined here: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html.

It’s such a great document. It’s very readable and it helped us to shape our library with a naming system people can following just by understanding the written standard.

• We have incoming “Decision Requests” from anywhere in the applications.
• We introduced a central PDP (Policy Decision Points) which holds our policy and is the central point to evaluate those requests and transform it into Decisions
• We have an expression engine (as defined in XACML) to define expressions in the policy that are evaluated during runtime. This opened up the world for conditional rules depending on some application context values or state changes ( to offer ABAC-like capabilities)

Keep in mind: We are shaping the policy usage to use it in the frontend exclusively. This means our policy is not about security (never trust the client) but more about shaping the frontend based on a fixed set of rules in a policy. This also means we can omit many abstractions and generalizations. No policy in policy (like in XACML) or static evaluation model (not semi-configurable as in casbin or as defined in the XACML standard). No XML-based configuration of properties as we can expose what we need directly in code to our developers or even hard-code some decisions.

I hope that helps & motivates you 🙏

[fgblomqvist]

@georgiee Wow thank you for the detailed write-up, sounds like quite the adventure! I do feel quite motivated to do something about the situation, but I’m leaning towards aiding Casbin in offering support for a sync API alongside their async API. Doing that in the proper fashion should be a fun little project that I hope to have time for sometime in the near future. Unfortunately we don’t have the capacity or big enough need to where we’d build a custom engine completely from scratch just yet, but I’m sure your post and its references will be found useful by many more people that end up here 😄