When we defer an authentication decision to a connector, we have traditionally assumed that all attributes of the user would be managed by that connector. There are several areas where this can become problematic if a user does not migrate and they still are logging into FusionAuth consistently. One of these areas is related to repeated login attempts by an end user.
Current State
If we have rate limiting enabled (Tenants > your Tenant > Security > Rate Limit Settings) for Failed login
or
If a user has configured a User Action that would prevent login (a la this tutorial)
If the user still has not migrated and still lives in a connector, then these actions and rate limits will not be applied to the user. Part of the reason for this, is that we expect the user "state" will be managed in the Connector.
Solution
We should allow an integrator of FusionAuth to have a user that lives in a connector have their rate limiting and account locking behavior be managed by the Connector or have policy configuration that allows this behavior to be managed by FusionAuth.
Alternatives/workarounds
Accounting for User State within your connector -- including users that should be locked.
Additional context
Add any other context or screenshots about the feature request here.
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
Problem
Historical State
When we defer an authentication decision to a connector, we have traditionally assumed that all attributes of the user would be managed by that connector. There are several areas where this can become problematic if a user does not migrate and they still are logging into FusionAuth consistently. One of these areas is related to repeated login attempts by an end user.
Current State
If we have rate limiting enabled (
Tenants > your Tenant > Security > Rate Limit Settings) forFailed loginor
If a user has configured a User Action that would prevent login (a la this tutorial)
If the user still has not migrated and still lives in a connector, then these actions and rate limits will not be applied to the user. Part of the reason for this, is that we expect the user "state" will be managed in the Connector.
Solution
We should allow an integrator of FusionAuth to have a user that lives in a connector have their rate limiting and account locking behavior be managed by the Connector or have policy configuration that allows this behavior to be managed by FusionAuth.
Alternatives/workarounds
Accounting for User State within your connector -- including users that should be locked.
Additional context
Add any other context or screenshots about the feature request here.
Related
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.