Repository navigation
Disable inactive users after n number of days. #9348
Replies: 6 comments 6 replies
|
I agree with the need for this functionality, but would make sure that the deleting of users functionality would be disabled by default. |
|
Definitively something worth adding, but may be a bit tricky to do from a performance perspective. We would not want to update the user in the database every time the login for example, as that would be expensive. One idea I had for this in the past is to have a separate "keep-alive" capability that can be used for many purposes and not just users, in addition also have a separate service that handles disabling/deleting/etc, which in the future should be possible to run on separate nodes to the nodes handling requests. |
|
We've got a similar requirement, but its auto-deletion after x days for GDPR compliance reasons. My employer might be willing to sponsor implementation and I might be able to work on this full time. Since you have concerns regarding performance if, on every login, a db call would have to be made to update the last_login attribute of a user, how about if the granularity is only date, not time? Thus, the update would only happen once a day. |
|
What I had in mind a while back was that instead of having "keep-alive" features on individual entries in the database, we'd have a separate entry in the database for this, with a service responsible for handling it. That could then be used for tokens, users, clients, sessions, etc. without having to update the actual entity itself. |
|
I guess it makes sense to have this be a separate concern. The database call is ok as long as it is not slowing down the login, if I got you right? |
|
@keycloak/storage-x FIY |
|
The linked STIG requirement asks for accounts to be disabled, it doesn't mandate for pruning of accounts. To prevent the re-use of an account name or to be able to re-activate it later, there are valid scenarios to keep the account and only disable it. Even in the light GDPR, deleting a user is just one option. GDPR mandates that data that is no longer used should be removed, and auditing might be a good reason to keep the data. Depending on the scenarios instead of deleting a record, it could be anonymized. With the existing Event SPI, the functionality can already be added without changing any existing code. It offers the implementer to store the data about the last login in an efficient store of their choice, and it can be a lot more efficient than the general purpose storage options we currently offer and are about to offer with the new storage API. If user information is stored externally (like LDAP), one might not be able to store that information in the external store. I briefly considered deferring the event processing for performance reasons ... at the same time Keycloak shouldn't miss a login event of a user and then disable the account despite a recent login. If it would be added to the core of the Keycloak distribution, it would need to be configurable which accounts would be disabled, and what strategies to apply (disable account, scrub data from account, delete account; possibly staged and with an email notification). Regarding a general keep-alive functionality, the configuration UI and the triggered functionality sounds quite specific for users for me. |
|
I do think this is a capability that Keycloak should offer out of the box, and should extend to other entities such as sessions and clients as well. I agree that it has to be configurable, and for users that could be "disable after X months", "anonymize after Y months", but I also see it being useful to "delete after Z months". Auditing is not usually kept indefinitely, and a well designed system doesn't rely on mutable things like usernames, but rather immutable IDs. I do think this is something we should consider only in the scope of the new store, and we should consider it as something more generic than just handling users, so created a follow-up discussion here: #10370 |
|
When you say you "should consider only in the scope of the new store" - I suspect that means this topic is part of a long-term refactoring of your persistent storage layer? I'm trying to figure out what to do - should we implement custom functionality for ourselves to satisfy this GDPR compliance issue, and if so what approach would you recommend? Or do you think this feature is implemented soon enough so that we can just wait? I also suspect that this is not a clear-cut design that I could help you implement, but requires more upfront discussion and exploration? |
|
I don't think this is something we can introduce anytime soon to be honest, as a basic implementation on our end would have a pretty big impact on performance. If I needed this short-term myself I would have built a custom event listener that sends events externally when a user logs in, etc.. Then have an external service that calls back to Keycloak Admin APIs to disable the user, etc. It might be possible to do something similar in the core Keycloak, but that would require more discussion, and at least agree on how it would look like both for the old and the new store. |
|
Anyone has a solution to this. I am 8000 very new to keycloak. Please share if any one has simple solution for this. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There is a STIG requirements that require account pruning after a set number of days. Keycloak should have the ability built in to automatically disable accounts after a set amount to satisfy STIG requirement:
https://www.stigviewer.com/stig/application_security_and_development/2018-12-24/finding/V-69301
Furthermore, account deletion after an addition n number of days would also be useful in managing accounts and increasing security.
All reactions