1602 Commits

Author SHA1 Message Date
Livio Spring
5f90cdbfc4
fix: correctly check user state (#8631)
# Which Problems Are Solved

ZITADEL's user account deactivation mechanism did not work correctly
with service accounts. Deactivated service accounts retained the ability
to request tokens, which could lead to unauthorized access to
applications and resources.

# How the Problems Are Solved

Additionally to checking the user state on the session API and login UI,
the state is checked on all oidc session methods resulting in a new
token or when returning the user information (userinfo, introspection,
id_token / access_token and saml attributes)

(cherry picked from commit 5b40af79f0d74c2d475cb74930c80e768f975bce)
2024-09-18 08:06:15 +02:00
Livio Spring
1b39d71921
fix: user grants deactivation (#8634)
# Which Problems Are Solved

ZITADEL's user grants deactivation mechanism did not work correctly.
Deactivated user grants were still provided in token, which could lead
to unauthorized access to applications and resources.
Additionally, the management and auth API always returned the state as
active or did not provide any information about the state.

# How the Problems Are Solved

- Correctly check the user grant state on active for tokens and user
information (userinfo, introspection, saml attributes)
- Map state in API and display in Console

(cherry picked from commit ca1914e235df8eb62189cec07eb0de2cdad29629)
2024-09-18 08:03:21 +02:00
Livio Spring
461f6bf3d3
fix: correctly check app state on authentication (#8630)
# Which Problems Are Solved

In Zitadel, even after an organization is deactivated, associated
projects, respectively their applications remain active. Users across
other organizations can still log in and access through these
applications, leading to unauthorized access.
Additionally, if a project was deactivated access to applications was
also still possible.

# How the Problems Are Solved

- Correctly check the status of the organization and related project.
(Corresponding functions have been renamed to `Active...`)

(cherry picked from commit d01bd1c51aa41ead46edc6760e18782f8e656d87)
2024-09-18 08:00:53 +02:00
Livio Spring
1189a17b70
fix: check if pw login allowed (#8584)
# Which Problems Are Solved

When checking for the next step for the login UI and a user did not yet
have an IdP linked, they would always be presented the password check
screen, even if the local authentication was disabled.

# How the Problems Are Solved

- Correctly check the login policy for the `Allow Username Password`
option
- In case the user has no IdP linked yet, fallback to the organizations
configuration (and redirect if possible)
- the user can be auto-linked based on the username / email after
successfully authenticating at the IdP

# Additional Changes

None

# Additional Context

- closes https://github.com/zitadel/zitadel/issues/5106
- closes https://github.com/zitadel/zitadel/issues/7502

(cherry picked from commit 650c21f18af91b0056f1e337e5d3aa21946e84b6)
2024-09-10 14:45:22 +02:00
Livio Spring
3289698d4c
fix: return 401 instead of 403 on expired tokens (#8476)
# Which Problems Are Solved

The access token verifier returned a permission denied (HTTP 403 / GRPC
7) instead of a unauthenticated (HTTP 401 / GRPC 16) error.

# How the Problems Are Solved

Return the correct error type.

# Additional Changes

None

# Additional Context

close #8392

(cherry picked from commit cbbd44c303c6a06a5ef3d6c8fecd6fca63ec8705)
2024-09-04 13:03:24 +02:00
Livio Spring
40f6205486
fix: automatically link user without prompt (#8487)
# Which Problems Are Solved

There were UX issue with the autolinking prompt page and users were not
able to link their account or would not understand what to do. Since the
trust to the IdP is already bound by the configuration, the user can
directly be linked without any user input.

# How the Problems Are Solved

- remove the prompt page and directly link the user if possible
- remove corresponding customization texts from the API and Console

# Additional Changes

None

# Additional Context

- relates to https://github.com/zitadel/zitadel/issues/7977
- discussed with customers
- created as a `fix` to be able to backport

---------

Co-authored-by: Max Peintner <max@caos.ch>
(cherry picked from commit ca8f82423a056e6f6f6ddc07fde174f9c832cca4)
2024-08-28 15:56:46 +02:00
Livio Spring
0ab0c645ef
fix: prevent error reason leakage in case of IgnoreUnknownUsernames (#8372)
# Which Problems Are Solved

ZITADEL administrators can enable a setting called "Ignoring unknown
usernames" which helps mitigate attacks that try to guess/enumerate
usernames. If enabled, ZITADEL will show the password prompt even if the
user doesn't exist and report "Username or Password invalid".
Due to a implementation change to prevent deadlocks calling the
database, the flag would not be correctly respected in all cases and an
attacker would gain information if an account exist within ZITADEL,
since the error message shows "object not found" instead of the generic
error message.

# How the Problems Are Solved

- Proper check of the error using an error function / type and
`errors.Is`

# Additional Changes

None.

# Additional Context

- raised in a support request

Co-authored-by: Silvan <silvan.reusser@gmail.com>

(cherry picked from commit a1d24353db4d27136da54a494a09595c04121320)
2024-07-31 15:10:54 +02:00
Livio Spring
c1a3fc72dd
fix: sanitize output for email (#8373)
# Which Problems Are Solved

ZITADEL uses HTML for emails and renders certain information such as
usernames dynamically. That information can be entered by users or
administrators. Due to a missing output sanitization, these emails could
include malicious code.
This may potentially lead to a threat where an attacker, without
privileges, could send out altered notifications that are part of the
registration processes. An attacker could create a malicious link, where
the injected code would be rendered as part of the email.

During investigation of this issue a related issue was found and
mitigated, where on the user's detail page the username was not
sanitized and would also render HTML, giving an attacker the same
vulnerability.

While it was possible to inject HTML including javascript, the execution
of such scripts would be prevented by most email clients and the Content
Security Policy in Console UI.

# How the Problems Are Solved

- All arguments used for email are sanitized (`html.EscapeString`)
- The email text no longer `html.UnescapeString` (HTML in custom text is
still possible)
- Console no longer uses `[innerHtml]` to render the username

# Additional Changes

None

# Additional Context

- raised via email

---------

Co-authored-by: peintnermax <max@caos.ch>
(cherry picked from commit 189505c80fa639108488f5979fe52967df9729fa)
2024-07-31 15:06:54 +02:00
Zach H
1b84c1dff7
fix: always use pgxpool config if MaxOpenConns isn't set (#8328)
# Which Problems Are Solved

- `pgxpool -> pgx` dependency throws "MaxSize must be >= 1" on init if
`postgres.MaxOpenConns` isn't set in the ZItadel config

# How the Problems Are Solved

Only override the `MaxConns` with the Zitadel configured `MaxOpenConns`
if greater than 0 (default value). The default `MaxConns` [is derived by
`pgxpool`](ea9610f672/pgxpool/pool.go (L309-L324))
itself in a sensible way, but somewhat undocumented: checks for explicit
config in connection url or config and falls back on max(num_cpus, 4).

# Additional Changes

Applied same check in cockroach config

# Additional Context

This is likely a regression from the changes in
https://github.com/zitadel/zitadel/pull/8325

(cherry picked from commit e009ed9fe41ad84324677c3db74c8aadf16e5740)
2024-07-22 15:33:18 +02:00
Silvan
c2521ebe0c
refactor(database): exchange connection pool (#8325)
# Which Problems Are Solved

The connection pool of go uses a high amount of database connections.

# How the Problems Are Solved

The standard lib connection pool was replaced by `pgxpool.Pool`

# Additional Changes

The `db.BeginTx`-spans are removed because they cause to much noise in
the traces.

# Additional Context

- part of https://github.com/zitadel/zitadel/issues/7639

(cherry picked from commit 99c645cc60628db9abf1c92688b6010a4066f5a6)
2024-07-22 15:01:25 +02:00
Livio Spring
7f6ecca040
fix: multiple nil pointers 2024-07-04 16:52:28 +02:00
Livio Spring
d04f208486
fix: correctly set user agent / fingerprint id on user sessions (#8231)
# Which Problems Are Solved

When we switched to V2 tokens (#7822), the user agent was incorrectly
set for sessions created though the login UI.
Additionally, when calling the ListMyUserSessions from the AuthService,
any session without the fingerprint ID (e.g. created through the session
API) would be listed.

# How the Problems Are Solved

- Use the intended ID of the user agent (fingerprint)
- Ignore empty user agent IDs when listing the user sessions

# Additional Changes

None.

# Additional Context

- relates #7822
- closes #8213

(cherry picked from commit 08a75635d2165fabf909032e8fd6293769a40393)
2024-07-03 09:55:20 +02:00
Livio Spring
9a9753a911
Merge branch 'main' into next
# Conflicts:
#	go.mod
#	internal/query/user_auth_method_test.go
2024-06-21 13:30:08 +02:00
Miguel Cabrerizo
3635320ce8
feat: send test mail (#7968)
# Which Problems Are Solved

- Zitadel doesn't have a way to test SMTP settings either before
creating a new provider or once the SMTP provider has been created.
- Zitadel SMTP messages can be more informative for usual errors

# How the Problems Are Solved

- A new step is added to the new/update SMTP provider wizard that allows
us to test a configuration. The result is shown in a text area.
- From the table of SMTP providers you can test your settings too.
- The email address to send the email is by default the email address
for the logged in user as suggested.
- Some of the SMTP error messages have been changed to give more
information about the possible situation. For example: could not contact
with the SMTP server, check the port, firewall issues... instead of
could not dial

Here's a video showing this new option in action:


https://github.com/zitadel/zitadel/assets/30386061/50128ba1-c9fa-4481-8eec-e79a3ca69bda

# Additional Changes

Replace this example text with a concise list of additional changes that
this PR introduces, that are not directly solving the initial problem
but are related.
For example:
- The docs explicitly describe that the property XY is mandatory
- Adds missing translations for validations.

# Additional Context

- Closes #4504
2024-06-20 19:51:42 +00:00
Livio Spring
00b5e55565
fix: set certificate validity for SAML IdPs (#8170)
# Which Problems Are Solved

Certificates created for a SAML IdP (used for metadata and request
singing) did not have any validity set. While it's not required for
SAML, when trying to import the certificate into a (keychain) tool it
might fail.

# How the Problems Are Solved

The validity is set based on the `CertificateLifetime` set in the
runtime config.

## After the fix:
If an IdP was created with a certificate without validity, an admin can
regenerate the certificate:
- for instance wide IdPs:
https://zitadel.com/docs/apis/resources/admin/admin-service-regenerate-saml-provider-certificate#regenerate-saml-identity-provider-certificate
- for organization specific IdPs:
https://zitadel.com/docs/apis/resources/mgmt/management-service-regenerate-saml-provider-certificate#regenerate-saml-identity-provider-certificate

Due to the new certificate, the metadata will change and will need to be
updated at the external IdP.

# Additional Changes

Additionally the `CertificateSize` instead of the `Size` (used for keys)
is used for generating the certificate, resp. the underlying key pair.

# Additional Context

- noted by a customer
- needs backports

---------

Co-authored-by: Elio Bischof <elio@zitadel.com>
2024-06-20 14:09:20 +00:00
Tim Möhlmann
669ac6bda2
perf(import): do not check for existing grant ID (#8164)
# Which Problems Are Solved

Improve the performance of the `admin/v1/import` API endpoint.
Specifaclly the import of large amount of project grants.

# How the Problems Are Solved

`AddProjectGrantWithID` and `AddProjectGrantMember` methods of
`Commands` used to get the current state of the Writemodel to check if
the current GrantID or the combination of GrantID & UserID wasn't
already used. However, the Added events already have protection against
duplication by the `UniqueConstaint` methods.

The queries become very slow when there is a great amount of project
grants. Because all the events are pushed to the aggregate ID of the
project, we had to obtain all related project events, including events
of grantIDs we do not care about. This O(n) duration for bached import
jobs adding many organization granted to a single project.

This change removes the unnecesary state query to improve performance.

# Additional Changes

- Add integration tests for import

# Additional Context

- reported internally
2024-06-20 13:31:58 +00:00
Tim Möhlmann
f9742a58f4
fix(import): add tracing spans to all import related functions (#8160)
# Which Problems Are Solved

This fix adds tracing spans to all V1 API import related functions. This
is to troubleshoot import related performance issues reported to us.

# How the Problems Are Solved

Add a tracing span to `api/grpc/admin/import.go` and all related
functions that are called in the `command` package.

# Additional Changes

- none

# Additional Context

- Reported by internal communication
2024-06-19 12:56:33 +02:00
Livio Spring
fb8cd18f93
feat: password age policy (#8132)
# Which Problems Are Solved

Some organizations / customers have the requirement, that there users
regularly need to change their password.
ZITADEL already had the possibility to manage a `password age policy` (
thought the API) with the maximum amount of days a password should be
valid, resp. days after with the user should be warned of the upcoming
expiration.
The policy could not be managed though the Console UI and was not
checked in the Login UI.

# How the Problems Are Solved

- The policy can be managed in the Console UI's settings sections on an
instance and organization level.
- During an authentication in the Login UI, if a policy is set with an
expiry (>0) and the user's last password change exceeds the amount of
days set, the user will be prompted to change their password.
- The prompt message of the Login UI can be customized in the Custom
Login Texts though the Console and API on the instance and each
organization.
- The information when the user last changed their password is returned
in the Auth, Management and User V2 API.
- The policy can be retrieved in the settings service as `password
expiry settings`.

# Additional Changes

None.

# Additional Context

- closes #8081

---------

Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
2024-06-18 11:27:44 +00:00
Stefan Benz
04fc59f538
fix: empty custom text changes push no events (#8054)
# Which Problems Are Solved

If there is no custom text given, the call ends in an internal error as
no events have to be pushed.

# How the Problems Are Solved

If no events have to be pushed, no trying to push an empty list of
events.

# Additional Changes

No additional changes.

# Additional Context

Closes #6954
2024-06-17 12:47:38 +00:00
Tim Möhlmann
1aa8c49e41
fix(oidc): store requested response_mode (#8145)
# Which Problems Are Solved

Zitadel never stored or returned the requested `response_mode` in oidc
Auth Requests. This caused the oidc library to fallback to the default
based on the response_type.

# How the Problems Are Solved

- Store the `response_mode` in the Auth request repo
- Store the `response_mode` in the Auth request v2 events
- Return the `resonse_mode` from the Auth Request v1 and v2
`ResponseMode()` methods. (Was hard-coded to an empty string)

# Additional Changes

- Populate the `response_modes_supported` to the oidc Discovery
Configuration. When it was empty, the standard specifies the default of
`query` and `fragment`. However, our oidc library also supports
`form_post` and by this fix, zitadel now also supports this.

# Additional Context

- Closes #6586
- Reported
https://discord.com/channels/927474939156643850/1151508313717084220

---------

Co-authored-by: Livio Spring <livio.a@gmail.com>
2024-06-17 09:50:12 +00:00
Livio Spring
85d7536d44
fix(oauth): ensure client error is prioritized over token error (#8133)
# Which Problems Are Solved

Introduced with #6909, the authentication check (API client) and the
token verification on the introspection endpoint where parallelized to
improve performance. Only the first error would be considered and
returned (and the second completely ignored).
This could lead to situations where both the client authentication and
token verification failed and the response would result in a 200 OK with
`active: false`.

# How the Problems Are Solved

- The client authentication check error will always be prioritized.
- An error in the token check will no longer terminate the client
authentication check.

# Additional Changes

None.

# Additional Context

- reported in Discord:
https://discord.com/channels/927474939156643850/1242770807105781760
2024-06-17 09:09:00 +00:00
Jesper We
18222008b6
feat: Contribute i18n swedish language (#8105)
# Which Problems Are Solved

- Swedish speakers cannot use their beautiful native language ;-)

# How the Problems Are Solved

- Contributes Swedish language for Login, Console, common texts and
Emails


# Additional Changes

- none

# Additional Context

- The PR currently provides all translation files according to
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#contribute-internationalization.

---------

Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
Co-authored-by: Livio Spring <livio.a@gmail.com>
2024-06-15 13:45:19 +00:00
Silvan
8b4531c28d
fix(v2): correct eventstore query (#8124)
# Which Problems Are Solved

Postgres versions < 16 require an alias for subqueries. The query
executed in the new eventstore didn't add this alias.

# How the Problems Are Solved

Added the alias to the subquery
2024-06-15 16:12:21 +03:00
Tim Möhlmann
120ed0af73
feat(oidc): organization roles scope (#8120)
# Which Problems Are Solved

An admin / application might want to be able to reduce the amount of
roles returned in the token, for example if a user is granted to many
organizations or for specific cases where the application want to narrow
down the access for that token to a specific organization or multiple.
This can now be achieved by providing a scope with the id of the
organization, resp. multiple scopes for every organization, which should
be included.

```
urn:zitadel:iam:org:roles🆔{orgID}
```

**Note:** the new scope does not work when Introspection / Userinfo are
set to legacy mode.

# How the Problems Are Solved

The user info query now has two variants:

1. Variant that returns all organization authorization grants if the new
scope wasn't provided for backward compatibility.
2. Variant that filters the organizations based on the IDs passed in one
or more of the above scopes and returns only those authorization grants.

The query is defined as a `text/template` and both variants are rendered
once in package `init()`.

# Additional Changes

- In the integration tests `assertProjectRoleClaims` now also checks the
org IDs in the roles.

# Additional Context

- Closes #7996
2024-06-14 10:00:43 +02:00
Tim Möhlmann
869ebceac6
fix(oidc): upgrade zitadel/oidc to allow scope without openid (#8109)
# Which Problems Are Solved

Drop the requirement of the `openid` scope in all auth and token request
types.

# How the Problems Are Solved

This change upgrades the oidc package to include
https://github.com/zitadel/oidc/pull/613.

# Additional Changes

- Fix a typo in a go doc string
- upgrade otel modules to match the version from oidc.

# Additional Context

- https://github.com/zitadel/zitadel/pull/7822 started doing scope
validation for machine user authentication on the token endpoint.
- https://github.com/zitadel/zitadel/discussions/8068 reports breakage
of machine authentication without `openid` scope.
- Merge after https://github.com/zitadel/oidc/pull/613 is released.

(cherry picked from commit 81cc7c62cbe0c256261de2d2576410e2c3a2c3be)
2024-06-13 13:55:05 +02:00
Yxnt
2450736a34
fix(login): ldap login page js file not found (#8101)
# Which Problems Are Solved
* fix ldap login page js file not found

![image](https://github.com/zitadel/zitadel/assets/10323352/47640ae9-3aa2-4a62-aa95-e23750cb8eb7)

Signed-off-by: Yxnt <jyxnt1@gmail.com>
Co-authored-by: Livio Spring <livio.a@gmail.com>
(cherry picked from commit 1374f17c8de7403c13ee998b8b2c421cf79b2bd2)
2024-06-13 13:55:05 +02:00
Livio Spring
a3fcf6431a
fix(oidc): remove MFA requirement on ZITADEL API based on user auth methods (#8069)
# Which Problems Are Solved

Request to the ZITADEL API currently require multi factor authentication
if the user has set up any second factor.
However, the login UI will only prompt the user to check factors that
are allowed by the login policy.
This can lead to situations, where the user has set up a factor (e.g.
some OTP) which was not allowed by the policy, therefore will not have
to verify the factor, the ZITADEL API however will require the check
since the user has set it up.

# How the Problems Are Solved

The requirement for multi factor authentication based on the user's
authentication methods is removed when accessing the ZITADEL APIs.
Those requests will only require MFA in case the login policy does so
because of `requireMFA` or `requireMFAForLocalUsers`.

# Additional Changes

None.

# Additional Context

- a customer reached out to support
- discussed internally
- relates #7822
- backport to 2.53.x

(cherry picked from commit fb2b1610f9ada78cdfe4b2aed4129c96658ff27e)
2024-06-13 13:55:05 +02:00
Livio Spring
e927eeaaed
fix(oidc): only return state in access token response for implicit flow (#8108)
# Which Problems Are Solved

Introduced with #7822 the access token response incorrectly returned the
`state` parameter.

# How the Problems Are Solved

The `state` will only be returned for access token responses in an
implicit_flow.

# Additional Changes

None.

# Additional Context

- relates to #7822
- relates to
https://github.com/zitadel/oidc/issues/446#issuecomment-2144999644
- backport to 2.53.x

---------

Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
(cherry picked from commit fb95f4a8a21476944d8af107a06c2ce434ce92b1)
2024-06-13 13:55:04 +02:00
Joakim Lodén
2cbcdf4ba9
fix: remove duplicate otel span processors (#8104)
(cherry picked from commit 1d13d41139eed8d5ecb4b1b106e8d2cd8752d695)
2024-06-13 13:55:04 +02:00
Livio Spring
9361a7f0dd
perf(authZ): improve oidc session check (#8091)
# Which Problems Are Solved

Access token checks make sure that there have not been any termination
events (user locked, deactivated, signed out, ...) in the meantime. This
events were filtered based on the creation date of the last session
event, which might cause latency issues in the database.

# How the Problems Are Solved

- Changed the query to use `position` instead of `created_at`.
- removed `AwaitOpenTransactions`

# Additional Changes

Added the `position` field to the `ReadModel`.

# Additional Context

- relates to #8088
- part of #7639
- backport to 2.53.x

(cherry picked from commit 931a6c7ccef71f8626ff8285d360d98a17e720b1)
2024-06-13 13:55:04 +02:00
Tim Möhlmann
81cc7c62cb
fix(oidc): upgrade zitadel/oidc to allow scope without openid (#8109)
# Which Problems Are Solved

Drop the requirement of the `openid` scope in all auth and token request
types.

# How the Problems Are Solved

This change upgrades the oidc package to include
https://github.com/zitadel/oidc/pull/613.

# Additional Changes

- Fix a typo in a go doc string
- upgrade otel modules to match the version from oidc.

# Additional Context

- https://github.com/zitadel/zitadel/pull/7822 started doing scope
validation for machine user authentication on the token endpoint.
- https://github.com/zitadel/zitadel/discussions/8068 reports breakage
of machine authentication without `openid` scope.
- Merge after https://github.com/zitadel/oidc/pull/613 is released.
2024-06-13 09:32:27 +00:00
Yxnt
1374f17c8d
fix(login): ldap login page js file not found (#8101)
# Which Problems Are Solved
* fix ldap login page js file not found

![image](https://github.com/zitadel/zitadel/assets/10323352/47640ae9-3aa2-4a62-aa95-e23750cb8eb7)

Signed-off-by: Yxnt <jyxnt1@gmail.com>
Co-authored-by: Livio Spring <livio.a@gmail.com>
2024-06-13 07:05:59 +00:00
Livio Spring
fb2b1610f9
fix(oidc): remove MFA requirement on ZITADEL API based on user auth methods (#8069)
# Which Problems Are Solved

Request to the ZITADEL API currently require multi factor authentication
if the user has set up any second factor.
However, the login UI will only prompt the user to check factors that
are allowed by the login policy.
This can lead to situations, where the user has set up a factor (e.g.
some OTP) which was not allowed by the policy, therefore will not have
to verify the factor, the ZITADEL API however will require the check
since the user has set it up.

# How the Problems Are Solved

The requirement for multi factor authentication based on the user's
authentication methods is removed when accessing the ZITADEL APIs.
Those requests will only require MFA in case the login policy does so
because of `requireMFA` or `requireMFAForLocalUsers`.

# Additional Changes

None.

# Additional Context

- a customer reached out to support
- discussed internally
- relates #7822 
- backport to 2.53.x
2024-06-12 12:24:17 +00:00
Livio Spring
fb95f4a8a2
fix(oidc): only return state in access token response for implicit flow (#8108)
# Which Problems Are Solved

Introduced with #7822 the access token response incorrectly returned the
`state` parameter.

# How the Problems Are Solved

The `state` will only be returned for access token responses in an
implicit_flow.

# Additional Changes

None.

# Additional Context

- relates to #7822 
- relates to
https://github.com/zitadel/oidc/issues/446#issuecomment-2144999644
- backport to 2.53.x

---------

Co-authored-by: Tim Möhlmann <tim+github@zitadel.com>
2024-06-12 11:53:56 +00:00
Joakim Lodén
1d13d41139
fix: remove duplicate otel span processors (#8104) 2024-06-12 10:18:48 +00:00
Livio Spring
931a6c7cce
perf(authZ): improve oidc session check (#8091)
# Which Problems Are Solved

Access token checks make sure that there have not been any termination
events (user locked, deactivated, signed out, ...) in the meantime. This
events were filtered based on the creation date of the last session
event, which might cause latency issues in the database.

# How the Problems Are Solved

- Changed the query to use `position` instead of `created_at`.
- removed `AwaitOpenTransactions`

# Additional Changes

Added the `position` field to the `ReadModel`.

# Additional Context

- relates to #8088
- part of #7639
- backport to 2.53.x
2024-06-12 09:11:36 +00:00
Livio Spring
fb5b4cff58
fix(oauth2): correctly return an error on client_credentials and jwt_profile (#8092)
# Which Problems Are Solved

When an error occurred during the oidc session creation from
client_credentials or jwt_profile, the error was ignored.

# How the Problems Are Solved

Return the error.

# Additional Changes

None.

# Additional Context

- relates to #7822
- noticed internally
- backport to 2.53.x

(cherry picked from commit 448f8f2c116d474a5a3e486eda5bbde380ac9890)
2024-06-12 08:43:48 +02:00
Livio Spring
663484e1fb
fix: consider oidc session events for authN milestones (#8089)
# Which Problems Are Solved

After migrating the access token events in #7822, milestones based on
authentication, resp. theses events would not be reached.

# How the Problems Are Solved

Additionally use the `oidc_session.Added` event to check for
`milestone.AuthenticationSucceededOnInstance` and
`milestone.AuthenticationSucceededOnApplication`.

# Additional Changes

None.

# Additional Context

- relates to #7822
- noticed internally

(cherry picked from commit b6c10c4c83ce05c5de10e9193503327eef3c2a88)
2024-06-12 08:43:48 +02:00
Livio Spring
4552fe7d99
fix: potential panics in login and return proper http 405 (#8065)
# Which Problems Are Solved

We identified some parts in the code, which could panic with a nil
pointer when accessed without auth request.
Additionally, if a GRPC method was called with an unmapped HTTP method,
e.g. POST instead of GET a 501 instead of a 405 was returned.

# How the Problems Are Solved

- Additional checks for existing authRequest
- custom http status code mapper for gateway

# Additional Changes

None.

# Additional Context

- noted internally in OPS

(cherry picked from commit 26c7d95c882295a012dbdd2963b13dbad6272527)
2024-06-12 08:43:47 +02:00
Livio Spring
448f8f2c11
fix(oauth2): correctly return an error on client_credentials and jwt_profile (#8092)
# Which Problems Are Solved

When an error occurred during the oidc session creation from
client_credentials or jwt_profile, the error was ignored.

# How the Problems Are Solved

Return the error.

# Additional Changes

None.

# Additional Context

- relates to #7822 
- noticed internally
- backport to 2.53.x
2024-06-12 06:42:50 +00:00
Livio Spring
b6c10c4c83
fix: consider oidc session events for authN milestones (#8089)
# Which Problems Are Solved

After migrating the access token events in #7822, milestones based on
authentication, resp. theses events would not be reached.

# How the Problems Are Solved

Additionally use the `oidc_session.Added` event to check for
`milestone.AuthenticationSucceededOnInstance` and
`milestone.AuthenticationSucceededOnApplication`.

# Additional Changes

None.

# Additional Context

- relates to #7822 
- noticed internally
2024-06-12 06:49:14 +02:00
Elio Bischof
b055d1d9e6
feat(init): configurable existing postgres db (#8045)
# Which Problems Are Solved

The init job fails if no database called *postgres* or *defaultdb* for
cockroach respectively exists.

# How the Problems Are Solved

The value is now configurable, for example by env variable
*ZITADEL_DATABASE_POSTGRES_ADMIN_EXISTINGDATABASE*

# Additional Context

- Closes #5810
2024-06-10 10:49:30 +00:00
Livio Spring
26c7d95c88
fix: potential panics in login and return proper http 405 (#8065)
# Which Problems Are Solved

We identified some parts in the code, which could panic with a nil
pointer when accessed without auth request.
Additionally, if a GRPC method was called with an unmapped HTTP method,
e.g. POST instead of GET a 501 instead of a 405 was returned.

# How the Problems Are Solved

- Additional checks for existing authRequest
- custom http status code mapper for gateway

# Additional Changes

None.

# Additional Context

- noted internally in OPS
2024-06-07 07:30:04 +00:00
Livio Spring
33235a5cbe fix(oidc): make sure id_token does not contain any info from access token actions (#8053)
# Which Problems Are Solved

During tests of 2.53.3 we noticed that in cases where the
`idTokenRoleAssertion` was disabled, claims set in the
preAccessTokenTrigger where also set in the id_token.

# How the Problems Are Solved

The userinfo of the id_token now uses a correct copy of their own.

# Additional Changes

None.

# Additional Context

- relates to #7822 
- relates to #8046
2024-05-31 15:08:00 +02:00
Livio Spring
4fa9de4314
fix(oidc): make sure id_token does not contain any info from access token actions (#8053)
# Which Problems Are Solved

During tests of 2.53.3 we noticed that in cases where the
`idTokenRoleAssertion` was disabled, claims set in the
preAccessTokenTrigger where also set in the id_token.

# How the Problems Are Solved

The userinfo of the id_token now uses a correct copy of their own.

# Additional Changes

None.

# Additional Context

- relates to #7822 
- relates to #8046
2024-05-31 13:06:59 +00:00
Livio Spring
50e0e7d564
Merge branch 'main' into next 2024-05-31 12:12:02 +02:00
Livio Spring
f065b42a97
fix(oidc): respect role assertion and idTokenInfo flags and trigger preAccessToken trigger (#8046)
# Which Problems Are Solved

After deployment of 2.53.x, customers noted that the roles claims where
always present in the tokens even if the corresponding option on the
client (accessTokenRoleAssertion, idTokenRoleAsseriton) was disabled.
Only the project flag (assertRolesOnAuthentication) would be considered.

Further it was noted, that the action on the preAccessTokenCreation
trigger would not be executed.

Additionally, while testing those issues we found out, that the user
information (name, givenname, family name, ...) where always present in
the id_token even if the option (idTokenUserInfo) was not enabled.

# How the Problems Are Solved

- The `getUserinfoOnce` which was used for access and id_tokens is
refactored to `getUserInfo` and no longer only queries the info once
from the database, but still provides a mechanism to be reused for
access and id_token where the corresponding `roleAssertion` and action
`triggerType` can be passed.
- `userInfo` on the other hand now directly makes sure the information
is only queried once from the database. Role claims are asserted every
time and action triggers are executed on every call.
- `userInfo` now also checks if the profile information need to be
returned.

# Additional Changes

None.

# Additional Context

- relates to #7822 
- reported by customers
2024-05-31 10:10:18 +00:00
Livio Spring
bc885632fb
fix(logging): reduce log level of errors in introspection and login UI (#8047)
# Which Problems Are Solved

Introspection errors such as invalid audience and errors in the login UI
such as invalid user agents where all logged as severity error.

# How the Problems Are Solved

Log level for both general loggers is changed to `info`.

# Additional Changes

None

# Additional Context

- internal discussion
2024-05-31 08:11:32 +00:00
Livio Spring
aabefb9382
feat(session api): respect lockout policy (#8027)
# Which Problems Are Solved

The session API was designed to be flexible enough for multiple use
cases / login scenarios, where the login could respect the login policy
or not. The session API itself does not have a corresponding policy and
would not check for a required MFA or alike. It therefore also did not
yet respect the lockout policy and would leave it to the login UI to
handle that.
Since the lockout policy is related to the user and not the login
itself, we decided to handle the lockout also on calls of the session
API.

# How the Problems Are Solved

If a lockout policy is set for either password or (T)OTP checks, the
corresponding check on the session API be run against the lockout check.
This means that any failed check, regardless if occurred in the session
API or the current hosted login will be counted against the maximum
allowed checks of that authentication mechanism. TOTP, OTP SMS and OTP
Email are each treated as a separate mechanism.

For implementation:
- The existing lockout check functions were refactored to be usable for
session API calls.
- `SessionCommand` type now returns not only an error, but also
`[]eventstore.Command`
  - these will be executed in case of an error

# Additional Changes

None.

# Additional Context

Closes #7967

---------

Co-authored-by: Elio Bischof <elio@zitadel.com>
2024-05-30 22:08:48 +00:00
adlerhurst
e3523ea0f2 Merge branch 'main' into next 2024-05-30 11:42:47 +02:00