Call for Insights: Fine-Grained Authorization Needs
Hello everyone,
We're currently focusing on the growing need for fine-grained authorization among our customers. We've observed an increasing demand for more granular control over access to avoid potential security risks associated with providing users with overly broad permissions.
To better understand your specific use cases and needs in this area, and to explore how Zitadel can best address them, we'd love to hear from you. We are particularly interested in learning about:
- Specific scenarios where fine-grained authorization is critical for your organization.
- The challenges you currently face with managing access control.
- Your ideal requirements and expectations for a fine-grained authorization solution.
- Any existing tools or methods you are currently using or evaluating.
- Any regulations or compliance requirements that influence your authorization needs.
If you're interested in discussing your experiences and providing valuable feedback on fine-grained authorization, please share your insights below in this thread.
Your input is greatly appreciated and will be instrumental in shaping how Zitadel can empower you with more precise and secure access control.
Thank you!
18 Replies
Not got time to book a call but I can throw a vote behind the fact we had to use openFGA for authz because of the need to do hierarchical relationship based authorization decisions.
It’s worked well so far but having to run openFGA ourselves and having zitadel cloud running happily for us has been a pain point from an ops overhead perspective.
Hi @spicypixel Thanks for your input. Could elaborate a bit more on the specific use cases in regards of hierarchical relationship based authorization decisions?
Also, if Zitadel would eventually offer native support for this hierarchical approach, would you consider switching from openFGA to potentially reduce operational overhead. Or, given that you've already implemented your current solution with openFGA, would you likely stick with it?
Any insights you could share would be greatly appreciated!
Sure
So in our system we have clients (orgs in zitadel land), teams and users.
Documents can be uploaded to our software with a various matrix of permissions like google docs, either read/write for the user only, add additional write for the team and additional the org always has read but no write options on documents - so if a member of staff leaves the org still owns this document in our system
Very simplified view of course but it wouldn’t be possible as far as I can tell to have the granular control over which documents in our system are editable and which aren’t on a per document basis.
We do utilise role based access control from zitadel to give people the documents role as a sort of global access point into the system but from their it’s handed off into openfga for the granular read, write and delete access controls on entities in the system.
As to your question about migration, would need the ReBAC model openfga supports to be able to migrate.
But since the system is just an auth model for the rules and a lot of tuples in a database for the state, depending on how it’s implemented it wouldn’t be too hard to migrate fully.
Obviously it would be basically trivial if you operated your own openfga instance embedded in zitadel else it would take careful consideration to map any auth models we already have into any new system.
https://openfga.dev/docs/authorization-concepts#what-is-relationship-based-access-control
basically the Google Zanzibar model
Authorization Concepts | OpenFGA
Introduction to Authorization
given that you've already implemented your current solution with openFGA, would you likely stick with it?authZ system requires a lot of thoughts and efforts to make it right, i'd prefer sticking with existing systems. i'd recommend the potential integration with: https://www.topaz.sh/ https://github.com/Permify/permify other OSS solutions requires subscriptions or enterprise version for some essential features.
Topaz | Topaz
An open-source, self-hosted, fine-grained access control service for Cloud Native applications
GitHub
GitHub - Permify/permify: An open-source authorization as a service...
An open-source authorization as a service inspired by Google Zanzibar, designed to build and manage fine-grained and scalable authorization systems for any application. - Permify/permify
Thanks for all the insights, this is really helpful. 😃
Thanks for your input, do you already use one of those tools in combination with Zitadel?
One thing I’ll point out though is we’d be dead in the water with zitadel clouds API usage limits, just glancing at my openfga istio stats, we’re hammering our install with hundreds of requests of second as a soft baseline and thousands in peak times since by the nature of fine grained authz you do lots of checks, some multiple checks per endpoint, on nearly all our authorised endpoints.
So I’d be mindful of the traffic pattern side of this debate, any of the Zanzibar inspired solutions sounds good to me (with a soft preference for the one I’m using) on a technical level but it’ll be all for nought if the usage limits are not usable.
I have not yet, would be great if there is a guide on integrating Zitadel with existing authZ systems.
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
Please take my feedback with a grain of salt.
I have previously shared my strong opinions against ZITADEL becoming an authorization service with @FFO. It honestly concerns me. Primarily because every single IdP business ends up in the same mess. Authorization services are complex systems in their own right, and I would prefer to see ZITADEL collaborating with companies like Authzed, also known as SpiceDB, to create the best possible user experience through integration.
Delegation is not the same as Authorization. Scopes are not the same as Permissions.
I would love to deeply understand where ZITADEL is headed before it is too late. If ZITADEL is considering becoming a fine-grained metadata management service that can be integrated with systems like SpiceDB, then I am intrigued by the direction you may be taking. However, if ZITADEL becomes my authorization service, I am not particularly enthusiastic about that.
Lastly, even if you choose to become the authorization metadata service (not enforcement), keep in mind that this has very little to do with an IdP. Sometimes, though not always, only the User and Groups are utilized, just to mention what is currently available. In such cases, the authorization service could always communicate with these services through a shared API.
Which I am not saying that ZITADEL as a company and product couldn't target such market, just that, most products that want to force the whole situation without proper architecture end up being a nightmare and we move on to what one was the perfect situation :smileWshake: Setting the whoel cicle again as soon as a new ZITADEL product arrives.
I would even argue that existing token authorizations in ZITADEL could be moved to those services to take advantage of high-scaling situations where every
ms count and you need global replication and so on. Since the IdP traffic after providing the tokens could be reduced a lot but simply delegating the authorization of it. But I digress.
Side note, I've invested far too much time into Identity Provider (IdP) and Authorization services :sadcat: . Not everyone who labels themselves as Zanzibar is truly aligned with what the Google Zanzibar paper represents. Many have merely adopted the domain-specific language without adhering to the architectural principles. Apart from SpiceDB, most use the term merely for marketing purposes.
Unless you find a very very very strong reason NOT to just focus on SpiceDB, I wouldn't even bother until further notice.
I sunk years into finding the perfect full blown IAM, I found them both at the same time and I stopped: ZITADEL + SpiceDB. Both products are just unique, and amazing from the core up. Both companies are also badass.
My guest it to combine them both if you wonder, use ZITADEL for the enterprise-graded IdP, use SpiceDB for authorization. Then that service in between to manage policies.
The tricky, I found that adding fancy GUIs in front of JSON/YAML/TOML/[insert format here] is most of the time contra-productive. That GUI "becomes" your programming language. Difficult to understand, or sometimes slow. Or other time, you want GitOps so you do not want to commit directly into anything in the infrastructure in that GUI. Eventually, you question why you built it at all.
Then, since that authorization metadata can NOT enforce strong integrity of data because such data come and goes, and the validity of it vary without changint the authorization metadata still ... you realized that, again, fancy GUIs dont help.
Eventually, backtracking out of the whole situation in a sense.Can't fault that experience and feedback.
I'm entirely with you on this one. In my experience it's better when IdP vendors focus on IdP, and let authorization get handled either by the customers themselves in their app, or integrate with Authorization partners that focus on authorization. I hate yet to find a company that can do both competently, without making significant sacrifices to one or even both ends of the product.
Devils advocate; does imply there’s a niche in the market for the first company that can do it competently
So my 2 cents on this are:
Yeah we should focus on doing identity and authN related topics first and in a good quality.
I think though at one point our customers want to see "more" a platform approach for all things "identity".
Like GitLab that does multiple things in SLCM. But I see the risk of us loosing the focus here 😓
Esp. in Mid-Market it can be nice to have one set of APIs to get the job done instead of integration a bunch of different tools.
Whats your take on that?
If it works well I’d appreciate a single view over all of it, the worry is just it won’t feel very cohesively integrated and that comes with the additional risk of being abandoned later
Yeah, I get that risk. So we need to move carefully. To be clear there is no immediate pressure on our end but we have heard that customers would enjoy having a central place to store AuthZ informations.
Were in exactly the same boat - glad to hear there is some consensus with my scouring of the IDP and Authz landscape. ZITADEL with SpiceDB is a beautiful mix.
For smaller apps it could be convenient to have some autorization possibilities inside Zitadel. I've used the built-in roles at first but in my app, a user can have access to different resources inside of different tenants so I had roles like
"tenant:<tenantid>_read"
"resource:<resourceid>_read"
"resource:<resourceid>_write"
This became messy quickly that's why we i decided to do AuthZ on our end instead.
Roles (authorization) are not Scopes (delegation); this is where most people take the shortcut and pay the cost later, big time.
Which is why such word is problematic in the context of ZITADEL. Those “roles” unless I am wrong, is about ZITADEL and the projects when we speak in terms of authorization…
Again, after so many years I keep getting confused 😵💫