Create an authn lock-out stage
Description
Environment
Attachments
- 12 Oct 2016, 04:06 PM
- 10 Oct 2016, 07:38 PM
- 10 Oct 2016, 07:35 PM
- 10 Oct 2016, 07:04 PM
Activity
Scott Cantor October 18, 2016 at 6:28 PM
r8506
Admin flow that can unlock accounts, implemented as a general GET/DELETE REST API for any storage service.
e.g.
GET /idp/profile/admin/storage/StorageBeanID/context/key
DELETE /idp/profile/admin/storage/StorageBeanID/context/key
Scott Cantor October 14, 2016 at 2:48 AM
r8494
Default wiring. shibboleth.StorageBackedAccountLockoutManager parent bean defined backed in-memory and using username!clientIP as key function.
Commented bean in user config to turn on feature and illustrate defaults.
Scott Cantor October 14, 2016 at 2:42 AM
r8493
Not a major change, just needed to set record expiration to the larger of the two settings, and zero the counter if the record exists but the previous attempt is old.
Should allow for counterInterval > lockoutDuration or counterInterval > lockoutDuration.
Scott Cantor October 14, 2016 at 2:05 AM
This doesn't work quite right, since the records are expiring based on the counter interval, the counter disappears before a longer lockout duration can apply.
Need to rethink, but may be workable to set the expiration based on the lockout duration (and thus need to go back to storing both the counter and the attempt time).
Scott Cantor October 14, 2016 at 1:11 AMEdited
r8489, 8450
Lockout implementation.
Code aside, I believe the chief differences are:
optimized storage with usual trick of overloading the record expiration to store the timestamp by subtracting the counter interval, so the record data is just the counter
the previously unused lockout duration setting is used to control how long the lockout holds
the "extend lockout if further attempts made" behavior defaults off instead of on
Defaults currently are 5 attempts, 5 minute interval, 5 minute lockout.
An API to clear the lockout is implemented, but I may or may not get to actually building an admin API to clear it.
Details
Details
Assignee
Scott CantorReporter
Tom Zeller
Create an authentication stage that will "lock out" a particular remote host (identified by IP) after a given number of authentication failures within a give period of time. Such a lock out would be authentication mechanism and SP agnostic.
This stage would require that a proxy sitting in front of the container running the IdP properly pass in the correct X-Forwarded information, but that's a requirement the IdP already has.
A group of clients that are aggregated by a proxy (e.g., "the AOL problem") would cause issues for this stage. As such, one configuration option probably needs to be a list of IP ranges to ignore.