spicypixel
ZZITADEL
•Created by fabienne on 5/5/2025 in #product-feedback-requests
Call for Insights: Fine-Grained Authorization Needs
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.
10 replies
ZZITADEL
•Created by fabienne on 5/5/2025 in #product-feedback-requests
Call for Insights: Fine-Grained Authorization Needs
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
10 replies
ZZITADEL
•Created by fabienne on 5/5/2025 in #product-feedback-requests
Call for Insights: Fine-Grained Authorization Needs
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.
10 replies
ZZITADEL
•Created by fabienne on 1/27/2025 in #product-feedback-requests
Token Exchange / Impersonation - Beta Feature
True that, given physical access is nearly as far as a keylogger
I’ll have a think about the risk tolerance here
8 replies
ZZITADEL
•Created by fabienne on 1/27/2025 in #product-feedback-requests
Token Exchange / Impersonation - Beta Feature
Interesting - lots of rough edges to consider
8 replies
ZZITADEL
•Created by fabienne on 1/27/2025 in #product-feedback-requests
Token Exchange / Impersonation - Beta Feature
Having read the security warnings I’m kinda stuck as to how I’d handle token exchange on a PKCE React app
I’d like to have a superuser grant that can impersonate any user in an org and see the app as they would but don’t really know where to start,
ZITADEL allows any application to use Token Exchange, however we strongly recommend to only configure confidential clients (using either client credentials or JWT assertion) with the Token Exchange grant type. This is because there is some trust placed in the application when it comes to defining scope and that it obtained tokens in a legitimate way. For example, if the app possesses a token of an admin user with impersonation permissions it can obtain tokens for any other user in your instance. It is your responsibility to make sure the application can be trusted with this kind of powers. If you configure a public client with the Token Exchange grant, you risk a leaked token can be used by an attacker who knows the client ID of a granted public client.But then the guide talks about a portal app having token exchange enabled?
8 replies
ZZITADEL
•Created by spicypixel on 11/8/2024 in #questions-help-bugs
Uniqueness of resource Ids across multiple object types (orgs, users, projects...)
That’s good to know, was worried I’d get overlap of users and orgs!
5 replies
ZZITADEL
•Created by spicypixel on 11/8/2024 in #questions-help-bugs
Uniqueness of resource Ids across multiple object types (orgs, users, projects...)
@FFO while we're trading answers, can I get this one answered? it's going to let me decide if I need to store
org/orgid and user/userid in my database outside of zitadel to reference the id, or if the global uniqueness is ensured, I'll just have the id and not need to differentiate with a prefix in the primary key5 replies
ZZITADEL
•Created by spicypixel on 10/29/2024 in #questions-help-bugs
Instance level introspection and how to do it?
2 replies