3f6ea78c87
# Which Problems Are Solved Currently ZITADEL defines organization and instance member roles and permissions in defaults.yaml. The permission check is done on API call level. For example: "is this user allowed to make this call on this org". This makes sense on the V1 API where the API is permission-level shaped. For example, a search for users always happens in the context of the organization. (Either the organization the calling user belongs to, or through member ship and the x-zitadel-orgid header. However, for resource based APIs we must be able to resolve permissions by object. For example, an IAM_OWNER listing users should be able to get all users in an instance based on the query filters. Alternatively a user may have user.read permissions on one or more orgs. They should be able to read just those users. # How the Problems Are Solved ## Role permission mapping The role permission mappings defined from `defaults.yaml` or local config override are synchronized to the database on every run of `zitadel setup`: - A single query per **aggregate** builds a list of `add` and `remove` actions needed to reach the desired state or role permission mappings from the config. - The required events based on the actions are pushed to the event store. - Events define search fields so that permission checking can use the indices and is strongly consistent for both query and command sides. The migration is split in the following aggregates: - System aggregate for for roles prefixed with `SYSTEM` - Each instance for roles not prefixed with `SYSTEM`. This is in anticipation of instance level management over the API. ## Membership Current instance / org / project membership events now have field table definitions. Like the role permissions this ensures strong consistency while still being able to use the indices of the fields table. A migration is provided to fill the membership fields. ## Permission check I aimed keeping the mental overhead to the developer to a minimal. The provided implementation only provides a permission check for list queries for org level resources, for example users. In the `query` package there is a simple helper function `wherePermittedOrgs` which makes sure the underlying database function is called as part of the `SELECT` query and the permitted organizations are part of the `WHERE` clause. This makes sure results from non-permitted organizations are omitted. Under the hood: - A Pg/PlSQL function searches for a list of organization IDs the passed user has the passed permission. - When the user has the permission on instance level, it returns early with all organizations. - The functions uses a number of views. The views help mapping the fields entries into relational data and simplify the code use for the function. The views provide some pre-filters which allow proper index usage once the final `WHERE` clauses are set by the function. # Additional Changes # Additional Context Closes #9032 Closes https://github.com/zitadel/zitadel/issues/9014 https://github.com/zitadel/zitadel/issues/9188 defines follow-ups for the new permission framework based on this concept.
| Community Meeting |
|---|
| ZITADEL holds bi-weekly community calls. To join the community calls or to watch previous meeting notes and recordings, please visit the meeting schedule. |
Are you searching for a user management tool that is quickly set up like Auth0 and open source like Keycloak?
Do you have a project that requires multi-tenant user management with self-service for your customers?
Look no further — ZITADEL is the identity infrastructure, simplified for you.
We provide you with a wide range of out-of-the-box features to accelerate your project, including:
✅ Multi-tenancy with team management
✅ Secure login
✅ Self-service
✅ OpenID Connect
✅ OAuth2.x
✅ SAML2
✅ LDAP
✅ Passkeys / FIDO2
✅ OTP
and an unlimited audit trail is there for you, ready to use.
With ZITADEL, you are assured of a robust and customizable turnkey solution for all your authentication and authorization needs.
🏡 Website 💬 Chat 📋 Docs 🧑💻 Blog 📞 Contact
Get started
Deploy ZITADEL (Self-Hosted)
Deploying ZITADEL locally takes less than 3 minutes. Go ahead and give it a try!
See all guides here
If you are interested to get professional support for your self-hosted ZITADEL please reach out to us!
Setup ZITADEL Cloud (SaaS)
If you want to experience a hands-free ZITADEL, you should use ZITADEL Cloud. Available data regions are:
- 🇺🇸 United States
- 🇪🇺 European Union
- 🇦🇺 Australia
- 🇨🇭 Switzerland
ZITADEL Cloud comes with a free tier, providing you with all the same features as the open-source version. Learn more about the pay-as-you-go pricing.
Adopters
We are grateful to the organizations and individuals who are using ZITADEL. If you are using ZITADEL, please consider adding your name to our Adopters list by submitting a pull request.
Example applications
Clone one of our example applications or deploy them directly to Vercel.
SDKs
Use our SDKs for your favorite language and framework.
Why choose ZITADEL
We built ZITADEL with a complex multi-tenancy architecture in mind and provide the best solution to handle B2B customers and partners. Yet it offers everything you need for a customer identity (CIAM) use case.
- API-first approach
- Multi-tenancy authentication and access management
- Strong audit trail thanks to event sourcing as storage pattern
- Actions to react on events with custom code and extended ZITADEL for you needs
- Branding for a uniform user experience across multiple organizations
- Self-service for end-users, business customers, and administrators
- CockroachDB or a Postgres database as reliable and widespread storage option
Features
Authentication
- Single Sign On (SSO)
- Passkeys support (FIDO2 / WebAuthN)
- Username / Password
- Multifactor authentication with OTP, U2F, Email OTP, SMS OTP
- LDAP
- External enterprise identity providers and social logins
- Device authorization
- OpenID Connect certified => OIDC Endpoints
- SAML 2.0 => SAML Endpoints
- Custom sessions if you need to go beyond OIDC or SAML
- Machine-to-machine with JWT profile, Personal Access Tokens (PAT), and Client Credentials
- Token exchange and impersonation
Multi-Tenancy
- Identity Brokering with templates for popular identity providers
- Customizable onboaring for B2B and their users
- Delegate role management to third-parties
- Domain discovery
Integration
- GRPC and REST APIs for every functionality and resource
- Actions to call any API, send webhooks, adjust workflows, or customize tokens
- Role Based Access Control (RBAC)
- Examples and SDKs
- Audit Log and SOC/SIEM
- User registration and onboarding
- Hosted and custom login user interface
Self-Service
- Self-registration including verification
- Self-service for end-users, business customers, and administrators
- Administration UI (Console)
Deployment
- Postgres (version >= 14) or CockroachDB (version latest stable)
- Zero Downtime Updates
- High scalability
Track upcoming features on our roadmap and follow our changelog for recent updates.
How To Contribute
Find details about how you can contribute in our Contribution Guide. Join our Discord Chat to get help.
Contributors
Made with contrib.rocks.
Showcase
Quick Start Guide
Secure a React Application using OpenID Connect Authorization Code with PKCE
Login with Passkeys
Use our login widget to allow easy and secure access to your applications and enjoy all the benefits of Passkeys (FIDO 2 / WebAuthN):
Admin Console
Use Console or our APIs to setup organizations, projects and applications.
Security
You can find our security policy here.
Technical Advisories are published regarding major issues with the ZITADEL platform that could potentially impact security or stability in production environments.
License
here are our exact licensing terms.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See our license for detailed information governing permissions and limitations on use.