mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-25 08:42:16 +00:00
jmaretteandGitHub
f34cc45eac
# Which Problems Are Solved ZITADEL cannot currently be used as an OAuth 2.0 Authorization Server by clients that need to register themselves at runtime: - There is no [OAuth 2.0 Dynamic Client Registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) endpoint, and no `registration_endpoint` is advertised in the discovery document. - This blocks [Model Context Protocol (MCP)](https://modelcontextprotocol.io) clients (Claude Desktop, claude.ai, Cursor, the MCP SDKs), whose OAuth 2.1 authorization profile expects an Authorization Server that supports dynamic client registration. They self-register before any user context exists and only then start the authorization code + PKCE flow. # How the Problems Are Solved ## Control plane: instance security settings No feature flag and no runtime config. A `DynamicClientRegistrationSettings` message is nested under the instance `SecuritySettings` in `settings/v2`, next to `embedded_iframe` and `enable_impersonation`: | `enabled` | `allow_unauthenticated` | Behaviour | | --- | --- | --- | | `false` (default) | — | `POST /oauth/v2/register` returns `404`, `registration_endpoint` absent from discovery | | `true` | `false` (default) | Token-gated registration, client homed in the token's organization | | `true` | `true` | Open registration for MCP hosts, client homed in the instance default organization | Both values are carried on `authz.Instance` and loaded with the instance, exactly like `EnableImpersonation`, so the discovery document and the endpoint read them per request without an extra query. `allow_unauthenticated` implies `enabled` in both implementations, so a single setting closes the endpoint. Adding the two columns bumps the projection table to `projections.security_policies3`, following what the impersonation setting did for `security_policies2`. ## Authorization: a dedicated permission, not `project.app.write` - New org-scoped permission **`project.app.register_dynamic`**, granted by default to `ORG_OWNER`, `IAM_OWNER` and `IAM_ORG_MANAGER` — in both `InternalAuthZ` and `SystemAuthZ`, mirroring where `project.app.write` already lives. - New built-in role **`ORG_DYNAMIC_CLIENT_REGISTRAR`** carrying only that permission, so a service user can self-register clients without gaining write access to the organization's existing applications. - Open mode (`allow_unauthenticated = true`) requires no token and no permission: that is the MCP self-register path. - A valid token whose user lacks the permission is answered with **`403 insufficient_scope`** (RFC 6750 §3.1) rather than `401 invalid_token`, so a caller can tell "your token is bad" from "your token may not do this". `verifyAccessToken` also reports invalid tokens as permission denied, so the authorization failure is marked explicitly to keep the two apart. The check runs once, at the endpoint, right after the token is verified and before any state is created, so it also gates the auto-provisioning of the organization's DCR project. The permission itself lives in the command layer next to the others (`Commands.CheckPermissionRegisterDynamicClient`). As the OIDC endpoints are not behind the authorization interceptor, the caller identity is derived from the verified token, the way token exchange does for the impersonating actor. ## Registration itself - **Registered clients are ordinary OIDC applications.** The endpoint reuses the existing application-creation events (`NewApplicationAddedEvent` and `NewOIDCConfigAddedEvent`), so the whole token, authorization and introspection flow keeps working unchanged. They are stored in a dedicated, auto-provisioned project named `ZITADEL DCR` per organization (name lookup), so they do not pollute the `IAMProject` or other projects. - Input is validated with the existing `GetOIDCV1Compliance` rules; `private_key_jwt` and `jwks`/`jwks_uri` are rejected with `invalid_client_metadata`. - **Endpoint wiring without forking the library.** `NewServer` calls `op.RegisterServer` instead of `op.RegisterLegacyServer`, so the new route can be added through the same `op.WithSetRouter` hook as the authorize callback. `op.RegisterLegacyServer` appends a middleware after the caller options, which chi forbids once a route has been registered; `op.NewIssuerInterceptor` reproduces the issuer middleware it would otherwise add. The `/oauth/v2` routing prefix is unchanged. # Additional Changes - **`application_type` inference for custom-scheme redirects** (last commit, isolated). `application_type` is an OpenID Connect member; RFC 7591 does not define it, so clients that only implement RFC 7591 omit it. Native MCP hosts doing so register custom-scheme redirect URIs, which ZITADEL reserves for native applications, and the OIDC default of `web` rejected them with `invalid_redirect_uri`. Inference is limited to custom schemes and to an absent `application_type`, so every request accepted today keeps its current application type and auth method — an `http` loopback redirect still yields a web application. Happy to drop this commit if you would rather keep it out of this PR. - **Docs**: a Dynamic Client Registration integration guide, a `registration_endpoint` section on the OpenID Connect endpoints page, and the new role in the administrators table (plus its description in the Console translations). # Additional Context - Part of #9810. This is **Phase 1 (DCR)**; #12315 adds RFC 7592 and #12316 adds CIMD, both stacked on this branch and rebased once this lands. - Implements the control-plane and authorization model requested in the review of this PR, itself a refinement of the direction in https://github.com/zitadel/zitadel/issues/9810#issuecomment-4891176997. - **Out of scope (deliberately)**: RFC 7592, CIMD, persisting free-form metadata (`logo_uri`, `contacts`, and similar), and `private_key_jwt` / `jwks_uri` (rejected cleanly). No new event types. - Follow-ups explicitly left out, per the review: DCR client lifecycle and richer audit, consent and custom scopes, JWT / `aud` (RFC 8707), and RFC 8414 AS metadata (currently absent from both ZITADEL and `zitadel/oidc`).
75 lines
6.0 KiB
Plaintext
75 lines
6.0 KiB
Plaintext
---
|
|
title: ZITADEL Administrators
|
|
description: "Manage administrators and their roles within ZITADEL instances and organizations."
|
|
sidebar_label: Administrators
|
|
---
|
|
|
|
import AdministratorDescription from "../../../concepts/structure/_administrator_description.mdx";
|
|
import AddAdministrator from "./_add_administrator.mdx";
|
|
import PermissionTable from '@/components/PermissionTable';
|
|
import permissionData from "../../../../../../cmd/defaults.yaml";
|
|
|
|
<TerminologyUpdate
|
|
newTerm="Administrators"
|
|
oldTerms={["Members", "Memberships", "Managers"]}
|
|
/>
|
|
|
|
<AdministratorDescription components={props.components} name="AdministratorDescription" />
|
|
|
|
To configure administrators in ZITADEL, go to the resource where you like to add it (e.g., Instance, Organization, Project, GrantedProject).
|
|
In the right part of the management console you can find **ADMINISTRATORS** in the details part. Here you have a list of the current administrators and can add a new one.
|
|
|
|
<img alt="Administrators" src="/docs/img/guides/console/administrators.png" width="200px" />
|
|
|
|
<AddAdministrator components={props.components} name="AddAdministrator" />
|
|
|
|
## Roles
|
|
|
|
| Name | Role | Description |
|
|
|-------------------------------|-------------------------------|--------------------------------------------------------------------------------------------------------------|
|
|
| Instance Owner | IAM_OWNER | Manage the Instance, manage all organizations with their content |
|
|
| Instance Owner Viewer | IAM_OWNER_VIEWER | View the Instance and view all organizations with their content |
|
|
| Instance Org Manager | IAM_ORG_MANAGER | Manage all organizations including their policies, projects and users |
|
|
| Instance User Manager | IAM_USER_MANAGER | Manage all users and their authorizations over all organizations |
|
|
| Instance Admin Impersonator | IAM_ADMIN_IMPERSONATOR | Allow impersonation of admin and end users from all organizations |
|
|
| Instance Impersonator | IAM_END_USER_IMPERSONATOR | Allow impersonation of end users from all organizations |
|
|
| Instance Login Client | IAM_LOGIN_CLIENT | Get all permissions needed to implement your own Login UI. |
|
|
| Org Owner | ORG_OWNER | Manage everything within an organization |
|
|
| Org Owner Viewer | ORG_OWNER_VIEWER | View everything within an organization |
|
|
| Org User Manager | ORG_USER_MANAGER | Manage users and their authorizations within an organization |
|
|
| Org User Permission Editor | ORG_USER_PERMISSION_EDITOR | Manage user grants and view everything needed for this |
|
|
| Org Project Permission Editor | ORG_PROJECT_PERMISSION_EDITOR | Grant Projects to other organizations and view everything needed for this |
|
|
| Org Project Creator | ORG_PROJECT_CREATOR | This role is used for users in the global organization. They are allowed to create projects and manage them. |
|
|
| Org Dynamic Client Registrar | ORG_DYNAMIC_CLIENT_REGISTRAR | Register OAuth 2.0 clients through the [dynamic client registration](/guides/integrate/dynamic-client-registration) endpoint, and nothing else |
|
|
| Org Admin Impersonator | ORG_ADMIN_IMPERSONATOR | Allow impersonation of admin and end users from the organization |
|
|
| Org Impersonator | ORG_END_USER_IMPERSONATOR | Allow impersonation of end users from the organization |
|
|
| Project Owner | PROJECT_OWNER | Manage everything within a project. This includes to grant users for the project. |
|
|
| Project Owner Viewer | PROJECT_OWNER_VIEWER | View everything within a project. |
|
|
| Project Owner Global | PROJECT_OWNER_GLOBAL | Same as PROJECT_OWNER, but in the global organization. |
|
|
| Project Owner Viewer Global | PROJECT_OWNER_VIEWER_GLOBAL | Same as PROJECT_OWNER_VIEWER, but in the global organization. |
|
|
| Project Grant Owner | PROJECT_GRANT_OWNER | Same as PROJECT_OWNER but for a granted project. |
|
|
| Org User Self Manager | ORG_USER_SELF_MANAGER | Grants a user permission to read policies and delete their own account. |
|
|
| Self Management Global | SELF_MANAGEMENT_GLOBAL | Grants a user permission to create organizations, read policies, and delete their own account, in the global organization. |
|
|
|
|
## Configure roles
|
|
|
|
If you run a self-hosted ZITADEL instance, you can define your custom roles by overwriting the defaults.yaml
|
|
In the InternalAuthZ section you will find all the roles and which permissions they have.
|
|
|
|
Example:
|
|
|
|
```bash
|
|
InternalAuthZ:
|
|
RolePermissionMappings:
|
|
- Role: "IAM_OWNER"
|
|
Permissions:
|
|
- "iam.read"
|
|
- "iam.write"
|
|
```
|
|
|
|
## Administrator Permission Matrix
|
|
|
|
This table is generated dynamically from our settings file.
|
|
|
|
<PermissionTable data={permissionData} />
|