# Which Problems Are Solved
Adds support for returning CreateUser/UpdateUser action payloads from
RetrieveIdentityProviderIntent so Actions v2 can update user metadata
(and other fields) using the v2 user APIs, ensuring parity with user
creation using Actions v2.
# How the Problems Are Solved
By:
- deprecating `AddHumanUser` and `UpdateHumanUser` fields in
`RetrieveIdentityProviderIntentResponse`
- adding a oneof field called `UserAction` with `CreateUser` and
`UpdateUser` fields to support user creation/update
- setting `UserAction` in the `RetrieveIdentityProviderIntentResponse`
for user creation/update
# Additional Changes
N/A
# Additional Context
- Related to https://github.com/zitadel/zitadel/issues/11369
- Follow-up for PRs https://github.com/zitadel/zitadel/pull/11719,
https://github.com/zitadel/zitadel/pull/11747
- Actions V2 example docs will be updated in a follow-up PR
---------
Co-authored-by: Copilot <[email protected]>
# Which Problems Are Solved
Add integration tests for recovery codes event reducers in the RT model.
# How the Problems Are Solved
Added integration tests for recovery codes event reducers
# Additional Changes
N/A
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11707
- Todo: add tests for other reducers in the `users_relational`
projection.
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
Currently, metadata can be set/updated only for human users, but it
should be available also for service accounts (machine users).
# How the Problems Are Solved
This is achieved by:
- adding a metadata field at the root level in `CreateUserRequest`,
which makes it available for both `human` and `machine` user types
- returning an error when both the root level and human-level `metadata`
fields are set in the `CreateUserRequest`
- setting `human` and `machine` metadata from the root `metadata` field
in the server layer
- pushing `user.metadata.set` event during machine user creation in the
command layer
- adding integration tests
# Additional Changes
N/A
# Additional Context
- Related to https://github.com/zitadel/zitadel/issues/11369
---------
Co-authored-by: Vitor Bari Buccianti <[email protected]>
Co-authored-by: Silvan <[email protected]>
# Which Problems Are Solved
Adds a repository implementation to add/remove recovery codes to the
users relational table.
# How the Problems Are Solved
This is achieved by:
* adding the following columns to the users table: `recovery_codes`,
`recovery_code_last_successful_check`, `recovery_code_failed_attempts`
* adding the `RecoveryCodes` field to the `HumanUser` domain with fields
to set recovery `codes`, `lastSuccessfullyCheckedAt` timestamp, and
`failedAttempts`
* setting `recoveryCodes` in the `Get` user query statement to return a
json object with details related to the recovery codes
* adding the repository-layer implementation to add/remove recovery
codes and set fields related to recovery code checks.
* adding projection reducers to handle the following events:
`HumanRecoveryCodesAddedEvent`, `HumanRecoveryCodesRemovedEvent`,
`HumanRecoveryCodeCheckSucceededEvent`, and
`HumanRecoveryCodeCheckFailedEvent`
* adding unit tests
# Additional Changes
* fix the error message when the recovery is empty in
`internal/command/user_human_recovery_codes.go`
* add a new error message for empty recovery code during checks in
`en.yaml`
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11212
- Follow-up: integration tests for the reducers will be added in a
different PR after this
[PR](https://github.com/zitadel/zitadel/pull/11478) is merged
# Which Problems Are Solved
Update outdated screenshots in the docs.
# How the Problems Are Solved
By replacing the outdated ones with current screenshots
# Additional Changes
Replace the usage of "authorization" with "role assignments" in docs
where it was previously missed.
# Additional Context
- Follow-up for PR https://github.com/zitadel/zitadel/pull/11588
- there are some more docs to be updated, which will be done in a
following PR
---------
Co-authored-by: Copilot <[email protected]>
# Which Problems Are Solved
After a user is deactivated, their sessions are still valid. When the
user is redirected to login page, they're stuck in a loop on a blank
page on the `users/me` endpoint as the user's session is still valid.
# How the Problems Are Solved
By terminating a deactivated user's session. This is done by:
- Adding a new reducer in session projection to delete sessions for
`UserDeactivatedEvent`, `UserLockedEvent` and `UserRemovedEvent` events
- Adding a new reducer in the relation session projection to delete
sessions based on `UserDeactivatedEvent`, `UserLockedEvent` events
# Additional Changes
N/A
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/10307
- todo: add integration test cases for relational session reducers based
on user deactivated, locked, deleted events
# Which Problems Are Solved
This PR adds support for storing and retrieving refresh tokens from
external identity providers during the IDP intent flow.
# How the Problems Are Solved
* Updated `idp.proto` (v2 and v2beta): added an optional `refresh_token`
field to `IDPOAuthAccessInformation`, which, in turn, is used in
`RetrieveIdentityProviderIntentResponse`
* Added the `IDPRefreshToken` field to the IDP intent `SucceededEvent`
struct, and updated the corresponding constructor to set the refresh
token
* Added the `IDPRefreshToken` field to `IDPIntentWriteModel`, and
updated `reduceOAuthSucceededEvent` to populate refresh token from
events
* Updated `tokensForSucceededIDPIntent` function to extract and encrypt
the refresh token from IDP session, if set
* Updated `idpOAuthTokensToPb` function to decrypt refresh token before
returning to clients
* Updated unit and integration tests
# Additional Changes
Updated the link to the JWT IDP docs linked in the Console
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11047
# Which Problems Are Solved
As part of the naming consistency initiative, the terms Authorization,
User grants, internal authorization and other similar terms that are
used in the context of assigning project roles to users are replaced by
Role Assignments in the UI, API docs, and documentation.
# How the Problems Are Solved
By replacing the following terms with Role Assignments in API docs,
Console UI, and guides.
- Authorization
- internal authorization
- external authorization
- User Grant
- Roles and Authorizations
By adding a note in the API docs to make it clear that Authorization
within the context of Authorization Service API refers to role
assignments, not to OAuth authorization as it is still used in the APIs.
By updating some screenshots in documentation / guides to show "Role
Assignments" instead of "Authorizations" in the UI.
# Additional Changes
N/A
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11289
---------
Co-authored-by: Copilot <[email protected]>
# Which Problems Are Solved
As part of the naming consistency initiative, the terms `Manager`,
`Member` and other similar terms that are used in the context of an
administrator are replaced by `Administrator` in the UI and
documentation.
# How the Problems Are Solved
By replacing the following terms with Administrator / Administrator
Roles in docs, Console UI, and guides.
- Manager
- Add Manager
- Add a Manager
- Administrator (used as a person type)
- Membership
- Member grants
# Additional Changes
minor grammatical edits in the docs
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11291
---------
Co-authored-by: Marco A. <[email protected]>
# Which Problems Are Solved
As part of the naming consistency initiative, the term `Manager Roles`
is replaced by `Administrator Roles`
# How the Problems Are Solved
By replacing `Manager Roles` with `Administrator Roles` in API docs,
Console UI, and guides.
# Additional Changes
N/A
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11293
---------
Co-authored-by: Copilot <[email protected]>
# Which Problems Are Solved
Naming inconsistency w.r.t the usage of Given Name / Family Name instead
of First Name / Last Name
# How the Problems Are Solved
* By replacing given and family names with first and last names in UI
and docs (not in the API definitions)
* Updated translations in multiple languages to first and last names
instead of given/family names
# Additional Changes
* Add `internal/**/*.yaml` path to the nx sources input to rebuild the
binary upon changes to these files
* Fix failing unit tests in `user_notifier_legacy_test.go` by updating
`Passwordless` with `Passkey`
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11308
---------
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Wim Van Laer <[email protected]>
# Which Problems Are Solved
The config `DefaultInstance.LoginPolicy.IgnoreUnknownUsernames` is
ignored during application start.
# How the Problems Are Solved
Fix the typo in the field name `IgnoreUnknownUsernames` associated with
the config used while unmarshaling.
Previously: `IgnoreUnknownUsername`
# Additional Changes
N/A
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/11007
# Which Problems Are Solved
The current documentation on setting up a MockSAML IDP is
unclear/incomplete, and doesn't work with Login V2.
# How the Problems Are Solved
- Add a new section that explains mapping of MockSAML attributes to
Zitadel user fields (using Actions V2) in case of Login V2
- Update the Actions V1 script used to prefill user data in case of
Login V1
# Additional Changes
N/A
# Additional Context
- Related to https://github.com/zitadel/zitadel/issues/11078
# Which Problems Are Solved
Flaky integration tests related to authorizations RT.
# How the Problems Are Solved
By setting the `created_at` and `updated_at` timestamps based on event
timestamps while creating an authorization.
# Additional Changes
N/A
# Additional Context
https://cloud.nx.app/runs/ICj84SxEf0/task/%40zitadel%2Fapi%3Atest-integration
# Which Problems Are Solved
Comment out timestamp assertions to temporarily unblock CI pipeline
# How the Problems Are Solved
Comment out timestamp assertions to temporarily unblock CI pipeline
# Additional Changes
N/A
# Additional Context
# Which Problems Are Solved
This PR implements relational table and repository interface for the
authorizations feature as described in
https://github.com/zitadel/zitadel/issues/10767
# How the Problems Are Solved
By
* adding new `zitadel.authorizations` and `zitadel.authorization_roles`
tables
* implementing the `AuthorizationRepository` interface to create,
update, query, and delete user authorizations and roles
* implementing `authorization_relational.go` projection to update
`zitadel.authorizations` and `zitadel.authorization_roles` tables based
on events
# Additional Changes
N/A
# Additional Context
- Closes#10767
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
The `SecretGenerators` setting is missing among the instance settings in
the new relational model.
# How the Problems Are Solved
This PR adds:
* `SettingTypeSecretGenerator` type to the settings model
* `SecretGeneratorSettingsRepository` and
`secretGeneratorSettingsJSONChanges` interfaces to set, retrieve, and
delete `secret_generator` settings, and corresponding unit tests.
* projection reducers to reduce the following events:
* `SecretGeneratorAddedEvent`
* `SecretGeneratorChangedEvent`
* `SecretGeneratorRemovedEvent`
* integration tests to test that the events get reduced correctly
# Additional Changes
N/A
# Additional Context
- Part of https://github.com/zitadel/zitadel/issues/10207
---------
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Marco A. <[email protected]>
# Which Problems Are Solved
In actions v2, when the condition `all` is chosen, or a specific method
is not specified for a service action, the actions are not executed.
# How the Problems Are Solved
The wildcard suffix `.*` is used only for event groups. As global
`requests`, `responses` or `services with no specified method` do not
have this suffix, they were bypassing the prefix-match check. This check
therefore does not apply to action types other than `event`
This issue is fixed by removing the `e.ID == "event"` condition when
prefix-matching execution IDs to not exclude other action types
(`request`, `response`, etc).
# Additional Changes
N/A
# Additional Context
- Closes#10895
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
If the groups of a user is requested through a scope, details related to
the user's groups are added in the token claims.
# How the Problems Are Solved
By querying the user groups that the user is a part of, and setting them
in the token claims.
This PR introduces two scopes to request user groups: `groups` and
`urn:zitadel:iam:user:groups`
* `groups` returns an array of group names in the token claims with the
same name
* `urn:zitadel:iam:user:groups` returns an array of JSON objects with
information about the user groups in the token claims with the same name
# Additional Changes
N/A
# Additional Context
- Closes#9702
- Follow-up for PRs:
* #10455
* #10853
* #10758
* #10940
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
User profile updates were not propagated when using External OIDC IDP +
Login V2
# How the Problems Are Solved
* `UpdateHumanUserRequest` is added to
`RetrieveIdentityProviderIntentResponse`
* `UpdateHumanUserRequest` is returned in the
`RetrieveIdentityProviderIntentResponse` when the user already exists
during external IDP auth, which is then used in the frontend to update
the user info
# Additional Changes
* Moved integration tests related to user intent to a separate test file
* Fix redirection after external IDP user registration
# Additional Context
- Closes#10838
- Follow up: https://github.com/zitadel/zitadel/issues/11053
---------
Co-authored-by: Max Peintner <[email protected]>
# Which Problems Are Solved
This PR fixes the examples used in the actions v2 docs.
# How the Problems Are Solved
* By fixing the actions v2 import path used in the example
# Additional Changes
* Use actions v2 instead of actions v2beta in the examples
* Use v2 `CreateUser` instead of v2beta `AddHumanUser` in
`request-manipulation` example
# Additional Context
- Follow up for https://github.com/zitadel/zitadel-go/issues/523
# Which Problems Are Solved
1. Adding users to user groups and removing users from user groups.
2. Searching for users in user groups by group IDs or user IDs
# How the Problems Are Solved
By adding:
1. The API definitions to manage users in users groups
3. The command-layer implementation of adding users/removing users
to/from user groups.
4. The projection table group_users1
5. Query-side implementation to search for users in user groups
# Additional Changes
1. Remove debug statements from unit tests.
2. Fix removal of groups when orgs are removed
3. Add unit tests for groups projection
# Additional Context
* Related to #9702
* Follow-up for PRs
* https://github.com/zitadel/zitadel/pull/10455
* https://github.com/zitadel/zitadel/pull/10758
* https://github.com/zitadel/zitadel/pull/10853
# Which Problems Are Solved
A user from `org A` with `ORG_USER_MANAGER` role in `org B` is unable to
list user metadata for a user in `org B`.
# How the Problems Are Solved
The `auth.option` is set to a specific permission (`user.read`) in the
API definition of `ListUserMetadata`, which causes the interceptors to
check for this specific permission. In this case, there is no specific
check for org membership of a user (from org A) in a target organization
(org B), and hence the call fails even though the user has the necessary
permissions.
This has been fixed by setting the `auth.option` to `authenticated`, and
the necessary [permission checks are handled in the
query-layer](https://github.com/zitadel/zitadel/blob/main/internal/query/user_metadata.go#L173).
# Additional Changes
N/A
# Additional Context
- Closes#10925
---------
Co-authored-by: Marco A. <[email protected]>
# Which Problems Are Solved
Requests without errors were mapped being mapped to GRPC status code
`Unknown`, which were then being mapped as HTTP `500` status code.
# How the Problems Are Solved
By deriving the grpc status codes from the error only when there's an
error.
When the error is `nil`, the grpc status code is set to 0 (`OK`).
# Additional Changes
N/A
# Additional Context
- Closes#10884
# Which Problems Are Solved
Ensuring the user group resource is managed with appropriate
permissions.
# How the Problems Are Solved
By configuring and checking for the relevant permissions needed to
create, read, update, and delete the user groups resource.
# Additional Changes
N/A
# Additional Context
- Related to #9702
- Follow-up for PRs #10455, #10758
# Which Problems Are Solved
This is the second PR related to the backend implementation of
GroupService to manage user groups.
The first [PR](https://github.com/zitadel/zitadel/pull/10455) implements
the Command-side.
This PR implements the query side.
# How the Problems Are Solved
* Query-side implementation to search/list groups by
* a list of Group IDs
* by the Group name
* by the Organization ID
# Additional Changes
N/A
# Additional Context
- Follow-up for PR #10455
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
This PR adds API definition and backend implementation for GroupService
to manage user groups.
# How the Problems Are Solved
* API definition to create, update, retrieve, and delete groups is added
* Command-side implementation to create, update, and delete user groups
as part of the GroupV2 API is added
# Additional Changes
N/A
# Additional Context
- Related to #10089, #9702 (parent ticket)
- User contribution: https://github.com/zitadel/zitadel/pull/9428/files
- Additional functionalities to list/search user groups, add
permissions, manage users in groups, group scopes will be added in
subsequent PRs.
- Also needs documentation, which will be added once the entire feature
is available
---------
Co-authored-by: Livio Spring <[email protected]>
# Which Problems Are Solved
This PR adds functionality to propagate request headers in actions v2.
# How the Problems Are Solved
The new functionality is added to the`ExecutionHandler` interceptors,
where the incoming request headers (from a list of allowed headers to be
forwarded) are set in the payload of the request before calling the
target.
# Additional Changes
This PR also contains minor fixes to the Actions V2 example docs.
# Additional Context
- Closes#9941
---------
Co-authored-by: Marco A. <[email protected]>
# Which Problems Are Solved
When a SAML IDP is created, the signing algorithm defaults to
`RSA-SHA1`.
This PR adds the functionality to configure the signing algorithm while
creating or updating a SAML IDP. When nothing is specified, `RSA-SHA1`
is the default.
Available options:
* RSA_SHA1
* RSA_SHA256
* RSA_SHA512
# How the Problems Are Solved
By introducing a new optional config to specify the Signing Algorithm.
# Additional Changes
N/A
# Additional Context
- Closes#9842
An existing bug in the UpdateSAMLProvider API will be fixed as a
followup in a different
[PR](https://github.com/zitadel/zitadel/pull/10557).
---------
Co-authored-by: Stefan Benz <[email protected]>
# Which Problems Are Solved
When a user with an `ORG_PROJECT_CREATOR` role tries to create a
project, the request fails with `No matching permissions found
(AUTH-AWfge)` error. This is because `project.write` was set as the
required permission instead of `project.create` during project creation.
# How the Problems Are Solved
By setting the right required permission (`project.create`) while
creating new projects.
# Additional Changes
N/A
# Additional Context
- Closes#10399
# Which Problems Are Solved
When `Permission Check V2` is enabled, calls to the `ListPasskeys` and
`ListAuthenticationFactors` APIs fail with the following error:
```
ERROR: missing FROM-clause entry for table "users14"
```
# How the Problems Are Solved
By using the right UserID column
(`projections.user_auth_methods5.user_id`) in the permission clause in
the `userAuthMethod` query
# Additional Changes
N/A
# Additional Context
- Closes#10386
# Which Problems Are Solved
The deletion of expired sessions does not go through even though a
success response is returned to the user. These expired and supposedly
deleted (to the user) sessions are then returned when the `ListSessions`
API is called.
This PR fixes this issue by:
1. Allowing deletion of expired sessions
2. Providing an `expiration_date` filter in `ListSession` API to filter
sessions by expiration date
# How the Problems Are Solved
1. Remove expired session check during deletion
2. Add an `expiration_date` filter to the `ListSession` API
# Additional Changes
N/A
# Additional Context
- Closes#10045
---------
Co-authored-by: Marco A. <[email protected]>
# Which Problems Are Solved
In the SAML responses from some IDPs (e.g. ADFS and Shibboleth), the
`<NameID>` part could be missing in `<Subject>`, and in some cases, the
`<Subject>` part might be missing as well. This causes Zitadel to fail
the SAML login with the following error message:
```
ID=SAML-EFG32 Message=Errors.Intent.ResponseInvalid
```
# How the Problems Are Solved
This is solved by adding a workaround to accept a transient mapping
attribute when the `NameID` or the `Subject` is missing in the SAML
response. This requires setting the custom transient mapping attribute
in the SAML IDP config in Zitadel, and it should be present in the SAML
response as well.
<img width="639" height="173" alt="image"
src="https://github.com/user-attachments/assets/cbb792f1-aa6c-4b16-ad31-bd126d164eae"
/>
# Additional Changes
N/A
# Additional Context
- Closes#10251
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
Okta sends a random password in the request to create a user during SCIM
provisioning, irrespective of whether the `Sync Password` option is
enabled or disabled on Okta, and this password does not comply with the
default password complexity set in Zitadel. This PR adds a workaround to
create users without issues in such cases.
# How the Problems Are Solved
- A new metadata configuration called
`urn:zitadel:scim:ignorePasswordOnCreate` is added to the Machine User
that is used for provisioning
- During SCIM user creation requests, if the
`urn:zitadel:scim:ignorePasswordOnCreate` is set to `true` in the
Machine User's metadata, the password set in the create request is
ignored
# Additional Changes
# Additional Context
The random password is ignored (if set in the metadata) only during
customer creation. This change does not affect SCIM password updates.
- Closes#10009
---------
Co-authored-by: Marco A. <[email protected]>
# Which Problems Are Solved
The SAML session (v2 login) currently does not push a
`AuthenticationSucceededOnApplication` milestone upon successful SAML
login for the first time. The changes in this PR address this issue.
# How the Problems Are Solved
Add a new function to set the appropriate milestone, and call this
function after a successful SAML request.
# Additional Changes
N/A
# Additional Context
- Closes#9592
---------
Co-authored-by: Stefan Benz <[email protected]>
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
1. The sorting columns in the gRPC endpoint
`ListInstanceTrustedDomains()` are incorrect, and return the following
error when invalid sorting options are chosen:
```
Unknown (2)
ERROR: missing FROM-clause entry for table "instance_domains" (SQLSTATE 42P01)
```
The sorting columns that are valid to list `instance_trusted_domains`
are
* `trusted_domain_field_name_unspecified`
* `trusted_domain_field_name_domain`
* `trusted_domain_field_name_creation_date`
However, the currently configured sorting columns are
* `domain_field_name_unspecified`
* `domain_field_name_domain`
* `domain_field_name_primary`
* `domain_field_name_generated`
* `domain_field_name_creation_date`
Configuring the actual columns of `instance_trusted_domains` makes this
endpoint **backward incompatible**. Therefore, the fix in this PR is to
no longer return an error when an invalid sorting column (non-existing
column) is chosen and to sort the results by `creation_date` for invalid
sorting columns.
2. This PR also fixes the `sorting_column` included in the responses of
both `ListInstanceTrustedDomains()` and `ListInstanceDomains()`
endpoints, as they now point to the default option irrespective of the
chosen option in the request i.e.,
* `TRUSTED_DOMAIN_FIELD_NAME_UNSPECIFIED` in case of
`ListInstanceTrustedDomains()`, and
* `DOMAIN_FIELD_NAME_UNSPECIFIED` in case of `ListInstanceDomains()`
# How the Problems Are Solved
* Map the sorting columns to valid columns of `instance_trusted_domain`
- If the sorting column is not one of the columns, the mapping defaults
to `creation_date`
* Set the `sorting_column` explicitly (from the request) in the
`ListInstanceDomainsResponse` and `ListInstanceTrustedDomainsResponse`
# Additional Changes
A small fix to return the chosen `sorting_column` in the responses of
the `ListInstanceTrustedDomains()` and `ListInstanceDomains()` endpoints
# Additional Context
- Closes#9839
