It’s a very interesting idea. How does it perform compared to a regular data warehouse?
41 karma · joined May 19, 2020
If the transaction fails, you should delete the malformed relation tuple from Permify to maintain consistency.
Here's an example of how this might look in code:
```
func CreateDocuments(db *gorm.DB) error {
tx := db.Begin()
defer func() {
if r := recover(); r != nil {
tx.Rollback()
// if transaction fails, then delete malformed relation tuple
permify.DeleteData(...)
}
}()
if err := tx.Error; err != nil {
return err
}
if err := tx.Create(docs).Error; err != nil {
tx.Rollback()
// if transaction fails, then delete malformed relation tuple
permify.DeleteData(...)
return err
}
// if transaction successful, write relation tuple to Permify
permify.WriteData(...)
return tx.Commit().Error```
Although this is an anti-pattern, this approach ensures that if the transaction in the application database fails and is rolled back, the corresponding data in Permify is also deleted, preventing inconsistencies.
Therefore, customizing complex permission logic (such as hierarchical relationships, user group, etc.) can be challenging in IAMs. As an example, Keycloak's Authorization Service supports RBAC and ABAC it does not support ReBAC.
Another point is that authorization as a service solutions are focused entirely on authorization. This means they provide not only fine-grained permissions but also tooling and functionality to ease testing and observability of the authorization system.
Also Permify leveraging Google’s Zanzibar scalable data model and unified ACL (Access Control List) approach, enables the creation of a centralized authorization service capable of handling high volumes of data and access checks across your microservices stack.
Still, it's worth mentioning that if you have a basic authorization system or need, it makes total sense to use the solutions you mentioned for handling the authorization part as well. However, if you want to scale your authorization, especially in a microservices environment, I would suggest trying one of the authz providers instead.
Assuming that you apply pagination to the search results, you can send the results to Permify one by one, as you'll only be displaying a limited number to the user. Permify is designed to handle millions of requests per second, so this approach won't cause any issues for your specific case.
While this solves the issue, sending multiple checks at once could create a problem as the number of items on the page increases, though it shouldn't be much of a problem even 500 items.
[0] https://permify.notion.site/Differentiation-Between-Zanzibar...
Permify provides a Permission Database[0] that unifies the authorization data (as a collection of Access Control Lists - ACLs) in a database of your choice, serving as the single source of truth for all authorization queries and requests via the Permify API.
Multi Tenancy: Our architecture is tenancy-based, which means you can create custom authorization models and relation tuples accordingly for different tenants and manage them in a single place. https://docs.permify.co/use-cases/multi-tenancy
Contextual Permissions: we have a functionality that permissions can be dynamically added to access check requests. When you send these relations along with your requests, they get processed alongside existing relations in the database and will return a result: https://docs.permify.co/operations/contextual-tuples
Schema Management: We're taking an approach that help engineering teams to ease and streamline the management and collaboration of their authorization logic. We have features like:
- Schema Staging: Handle authorization model (schema) changes at different stages and deploy schemas with our GitOps workflow, specifically designed to approve, merge, and monitor schema changes.
- Partial Schema Update: Gives you the ability to update a schema partially without needing to change the entire schema.
- Data Bundles: Handle multiple data creation and deletion actions in your applications.To learn more, refer to our docs[0]
Regarding multi-region deployment, we offer PostgreSQL as the production database option. We support multi-region databases that share the same interface as PostgreSQL, such as Amazon Aurora. CockroachDB is also on our roadmap
Libraries was designed to operate directly on an application’s existing data structures without imposing a standardized model for how that data should be organized.
Direct interaction with diverse data structures can lead to inefficiencies and performance bottlenecks. Without a standardized model, the library might not optimize data access and manipulation as effectively as it could with a uniform data structure.
Additionally, they struggle in microservices architectures, creating challenges in maintaining consistent security policies across services. In a microservices architecture, each service might require access to the authorization library, but replicating this library across services can lead to maintenance, synchronization, and consistency challenges.
Here are the major differences,
- Better Performance: Observed guess, not necessarily a fact: Many folks have come to us from OpenFGA due to latency and performance issues. We’re implementing various levels of caching mechanisms to meet the required performance. We have also documented the differences in caching between us and OpenFGA in the following document: https://permify.notion.site/Cache-Differences-Between-Permif....
- Schema Management: We're taking an approach that help engineering teams to ease and streamline the management and collaboration of their authorization logic. We have features like:
- Schema Staging: Handle authorization model (schema) changes at different stages and deploy schemas with our GitOps workflow, specifically designed to approve, merge, and monitor schema changes.
- Partial Schema Update: Gives you the ability to update a schema partially without needing to change the entire schema.
- Data Bundles: Handle multiple data creation and deletion actions in your applications.About the diffs, right now there are some approach differences on some features such as modeling, data filtering, auditing, etc but the main difference is we’re a fully tenancy-based solution, which gives the ability to customize the authorization for each tenant's specific needs.
Particularly, in Permify you can create custom authorization schema and relation tuples accordingly for the different tenants and manage them in a single place. We're highly invested in building and managing custom roles and permissions as a part of fine-grained access control.
Permify stores authorization data as relations in a database you prefer and perform access checks (and other queries as well) according to stored relations/authz data. And since user identities exist/stored in providers, they should be mapped Permify to store necessary authorization data/relations. So providers can feed Permify but not vice versa.
For more information about how we're managing authorization, check our docs: https://docs.permify.co/docs/getting-started/sync-data
- 1. Which integration is your most heavily used right now?
Currently, we don't have any official integration. But we're seeing use cases with popular authentication or identity providers to map user identities, roles, groups, etc.
- 2. Classic premature optimization question, but how easy is it to scale out Permify?
You can horizontally scale Permify Service with positioning Permify instances behind of a load balancer, also we have an internal cache mechanism that follows MVCC (multiple version concurrency control) pattern & Snap tokens to scale in terms of performance. Lastly, we’ll add consistent hashing with Hash Rings (https://itnext.io/introducing-consistent-hashing-9a289769052...), it’s in our roadmap.
- 3. Could Permify be used to do something like switch between Auth0 and OneLogin for example?
Actually can’t, Permify doesn’t handle authentication or identity management. As I stated in the first question, you can use them only to feed/map Permify with user information (attributes, identities, etc) to provide end-to-end access control structure across your stack.
We have both worked with fortune 500 companies to small businesses [1], and every authorization system was unique. Yet we always tackle the same problems.
- Modeling the authorization logic was hard. As the product grows things get complicated very fast. So, it’s challenging to design a model that’s both easy to start with and future-proof. [2] - Designing the architecture was a dread. It’s not a huge problem when you have a monolith. But when it comes to micro-services it’s a nightmare since authorization data is a subset of application data. [3] - Authorization checks occur in so many places; like user interfaces, routers, API endpoints, database queries… So, choosing where to enforce authorization, and loading the authorization data is hard.
So, Permify syncs your authorization data as relation tuples with CDC(Change Data Capture) from Databases you want to a DB you point at.[4] And based on this data you can get boolean returns for your access control checks.
I know many alternatives had launched at HN over the course of time. So what’s the twist. What we concurrently encountered was orchestrating the authorization data was a nightmare.
What you can except from Permify in following months;
- Message broker to support more Databases. - Redis Cache support. - Better debugging and auditing tools such as transparency logs. - More compatibility with the Zanzibar paper.
[0]: https://research.google/pubs/pub48190/
[1]: https://www.permify.co/post/why-decouple-authorizations
[2]: https://medium.com/building-carta/authz-cartas-highly-scalab...
[3]: https://medium.com/airbnb-engineering/himeji-a-scalable-cent...
[4]: https://dbconvert.com/blog/postgresql-change-data-capture-cd...
It's Ege from Permify. We're building an Plug-&-Play API for Authorizations and Open-source tools for access control.
We have interviewed bunch of developers, and as developers we know how hard authorizations can get.
But there are 2 evident reasons that makes Authorizations hard.
1. Since it happens so many places, it's hard to make a unified decision and enforce them. 2. When authorization logic is in your business logic or code, it clutters your so much that it becomes impossible to change both decision architecture and code.
But we know not everyone needs a powerful authorization system, or our dashboard. Sometimes just a few simple roles are enough at the beginning.
Things got messy pretty quickly. You ship new features that require more granularity, and your users start asking for more reliability on the access control part.
And boom! You’re in a technical depth that makes development 10x slower.
That’s why we built the React Roles library. It keeps your authorizations in line until you need more complex authorizations and decoupled logic.
React Role is lightweight role based access management solution which provides components, hooks, and helper methods for controlling access checks and user permissions throughout your entire React application without any backend connection.
So, It's easy to just create few tables and connected to roles. But when you start adding more features, and eventually more dependence things tend to get out of control. You create tons of "if"s, your code turn into spaghetti and developement cycles becomes frustrating just because of this chores which is even not your core product.
Been there done that. We have build dozens of product like that, and once you get over certain point technical debt is crazy. It turns joyful code into a hell.
That's why we build Permify.
Permify is a developer API for access control. We decouple authorzation logic from your code so you can ship faster without interfering with access control.
And once you need access control; you can granularly build, modify, and test your authorizations through a dashboard and simple API calls.
We’re taking policy as code approach powered by OPA and REGO. We make it simple to create complex access control policies with simplified policy as code approach by using our policy enforcer that turns our code into REGO policies and eventually validate through OPA rule engine?
And this is our Developer Playground designing your granular access control system. It makes sense to share this since it's something you can play and experiment with without any commitment.
I'll be around to answer any questions.