Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

User Lockout Possibility on Resource API #7967

Closed
5 tasks done
hifabienne opened this issue May 16, 2024 · 1 comment · Fixed by #8027
Closed
5 tasks done

User Lockout Possibility on Resource API #7967

hifabienne opened this issue May 16, 2024 · 1 comment · Fixed by #8027
Assignees
@livio-a
Labels
auth improvement released resources

Comments

@hifabienne
Copy link
Member

hifabienne commented May 16, 2024 •
edited by livio-a

As an administrator I want to have a user locked if I have set a lockout settings, if the failed attempts are reached.

Acceptance Criteria

  • If I have set lockout settings password attempts to 3, user should be locked after 3 failed password attempts (also works with otp attempts)
  • If I enter a wrong password on two different browsers (e.g mobile phone, mac), the user should be locked after 3 failed attempts in total (also works with otp attempts)
  • If lockout setting is set to 0 attempts, the user should not be locked at all
  • If I read the user after failed attempts, the user has the state locked
  • I am not able to create a session for a locked user
@livio-a livio-a mentioned this issue May 29, 2024
Merged
eliobischof added a commit that referenced this issue May 30, 2024
@livio-a @eliobischof
feat(session api): respect lockout policy (#8027)
aabefb9 
# 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>
@github-actions GitHub Actions
Copy link

🎉 This issue has been resolved in version 2.54.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@livio-a livio-a

Labels
auth improvement released resources
Projects
Product Management
Status: ✅ Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(session api): respect lockout policy zitadel/zitadel
2 participants
@livio-a @hifabienne