Question about validating a user's roles within an organization
Hey everyone, appologies if there is already a similar thread about this. I looked quite hard but I wasn't able to find anything.
My company is currently investigating Zitadel as a potential shared solution for product auth. From our perspective, is has a lot of clear benefits over the usual suspects like Keycloak.
One thing that's got me a bit concerned is how our product teams will be able to validate the roles assigned to a user by a specific organization. As per the docs, with the
urn:zitadel:iam:org:project:id:zitadel:aud scope, the userinfo endpoint will return roles in a structure like:
In this example, the user has been assigned the "cfo" role by the "corporate" organization, and the "corporate member" role by both the "org-a" and "org-b" organizations. This makes perfect sense. But I want to ask about how a particular application actually goes about using this information.
There are a number of examples Zitadel gives (zitadel-nextjs, zitadel-vue, zitadel-nextjs-b2b, etc.), where the equivalent of Object.keys(userinfo["urn:zitadel:iam:org:project:roles"]) is used to demonstrate getting a user's role... This seems like an extremely dangerous practice, because obviously you also need to consider the organization tied to the granted role.10 Replies
It seems to me that this approach would only work if you could prohibit organizations from granting roles to a user from another organization.
So what I'd like to ask is:
1. Is there a way to prohibit an organization from being able to grant roles to members from another organization?
2. Is this the wrong way to be validating roles in the first place?
As a hard example:
Company A has purchased our product which uses Zitadel. They grant roles to some members from their own company. One of these users "alice@company-a.com" is a bad actor, but she's only been given low-level permissions.
Alice reaches out to us separately and requests a trial of our product under a fake identity and unrelated email address. The sales team okays this, and she has admin access to her own trial organization.
Within this trial organization, she grants high-level permissions to "alice@company-a.com" from the Company A organization.
Because the app is only performing a shallow check of the roles the user has associated with them, Alice now has high-level permissions in Company A.
Hi there @lbm! Thanks for reaching out! Let me go ahead and tag in an engineer who can provide more insight based on the context you've provided. ☺️ @fcoppede
I just realized that the zitadel-nextjs-b2b example I linked actually does address this by checking the org id 🙂 But the other two seem to be valid.
👋 hello @lbm thanks for reaching out to our community, this is Federico Coppede, happy to help you!
Roles live inside a project (projects live inside organizations), and to be able to grant roles defined in organization A to users that belong to organization B, first you need to grant the project that defines that roles in organization A to organization B. If this is possible, this means that an admin within the instance made this possible. You could also create "fake" roles with the same name in organization B, this is why you not only need to validate the role name, also the organization ID (as you pointed out)
Please see the following:
- https://zitadel.com/docs/concepts/structure/granted_projects
- https://zitadel.com/docs/guides/manage/console/roles
Let me know if that helps, thank you!
ZITADEL Docs
Organization Grant
ZITADEL Docs
If you would build out the POS use case example you would probably need an application for administration.
Thanks for that info @fcoppede, that makes sense to me and matches what I'd expect! So then I suppose my main concern is really just with the example repos. I'm worried about how the code they present may be used in the wild...
I wish it were safe to make the assumption that most developers would think this through and not simply copy-and-paste, but obviously auth is not a simple topic to wrap your head around, especially for less skilled engineers.
Would these types of repos be open to contributions? If I could prevent even one project from making this kind of mistake, I think it would be worth the time 🙂
Hey there @lbm! To clarify, are you asking if you can contribute to the nextjs-b2b example? ☺️
Actually, that repo looks fine. I meant nextjs, vue, etc. 🙂
All of these repos should be open to contribution! Just ensure you check out our contribution guidelines prior to opening a new issue ☺️
GitHub
zitadel-nextjs/CONTRIBUTING.md at main · zitadel/zitadel-nextjs
This is our ZITADEL Next.js template. If shows how to authenticate as a user and retrieve user information from the OIDC endpoint. - zitadel/zitadel-nextjs
🎉 Looks like you just helped out another community member! Thanks for being so helpful <@854908558415495188>! You're now one step closer to leveling up—keep up the amazing peer support! 🚀
As a quick note @lbm, I reached out to you via DM regarding your evaluation process with some additional information that might be useful at this point! ☺️