policy-aona
peoplefinder
| policy-aona | peoplefinder | |
|---|---|---|
| 1 | 1 | |
| 2 | 1 | |
| - | - | |
| 0.0 | 0.0 | |
| over 1 year ago | about 1 year ago | |
| Open Policy Agent | JavaScript | |
| - | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
policy-aona
-
Aserto, the developer API for permissions and RBAC, is open to all
RBAC is simple to get started with, but indeed pretty limited. We tend to use the term because it's more recognizable than ABAC or ReBAC.
The {subject,relation,object} tuples do provide a convenient way to express an ACL-based system.
Most real-world systems we've encountered tend to have a combination of user-centric and resource-centric aspects to them. With an ABAC-style policy, you can easily enforce relationships like "user X can edit objects in project Y, and can read objects in project Z". In fact, the Aserto policy for Aserto [1] uses this style of authorization, without going "full-tuple".
In fact, for many use-cases, the prospect of creating an ACL for every resource feels like a management nightmare for the folks we've talked to, and they typically have a "resource group" construct or hierarchy that they want to treat the same from an authorization perspective.
Finally, in addition to the user model, Aserto has a resource model, and we're exploring evolving it more towards the tuple approach.
[1] https://github.com/aserto-dev/policy-aona
peoplefinder
-
Aserto, the developer API for permissions and RBAC, is open to all
That's indeed why authorization is a harder problem than authentication - because much of it is domain-specific.
Still, there are many things an authorization system can help with. For example, the service/organization affiliation of the user is easily expressed as a set of attributes / properties / roles on the user. If that's stored in a central directory, and the authorizer has a cached copy, you can use this context as part of your policy for making authorization decisions.
Lifting the authorization policy into a central repo allows you to consolidate authorization logic, and also enables separation of concerns. SecOps can evolve the authorization policy of the application without having to ask developers to revisit the logic in all the places it exists. In fact, we have customers that have their secops team deploy new versions of the authorization policy without having to redeploy the application.
Another example is having front-end code that can dynamically render component state (visible or enabled) based on the same authorization rules that the back-end / API uses. We have nice examples of this in our "peoplefinder" demo [0], which you can launch as a quickstart [1].
[0] https://github.com/aserto-demo/peoplefinder
[1] https://www.aserto.com/quickstarts
What are some alternatives?
spicedb - Open Source, Google Zanzibar-inspired permissions database to enable fine-grained access control for customer applications