Aserto, the developer API for permissions and RBAC, is open to all

• spicedb

  38 4,518 9.7 Go

  Open Source, Google Zanzibar-inspired permissions database to enable fine-grained access control for customer applications

  

Disclaimer: I am a founder of Authzed (W21).

Generally, this problem is called ACL-Filtering[0][1] and can be done in two ways: "pre-filter" and "post-filter". A filter for selecting the entities from your database or as a filter after the entities have been returned from the database. Sometimes you might even have to do both.

If you decide to use a specialized database for permissions, similar to SpiceDB[2], there are often specialized APIs for directly listing the entities a subject has access to in various ways. You can take these results and feed them into a database query to select only the authorized content. This doesn't have to just be a list of IDs, but can also be datastructures like bitmaps, effectively providing your database with a custom index for your query.

Filtering you've queried all possible results from your database can also be more performant than you'd think, because you can use lazy loading and perform permission checks in parallel. We have some pretty large systems that are purely using this strategy.

[0]: https://docs.authzed.com/reference/glossary#acl-filtering

[1]: https://authzed.com/blog/acl-filtering-in-authzed/

[2]: https://github.com/authzed/spicedb

• peoplefinder

  1 1 0.0 JavaScript

  PeopleFinder demo

  

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

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• policy-aona

  1 2 0.0 Open Policy Agent
  

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

Suggest a related project