Repository navigation
Replies: 9 comments 5 replies
|
@keycloak/storage-x FIY |
|
There is now Currently it is only implemented by session-type objects, but nothing prevents adding implementations to other object types, e.g. realms. When adding new object type, each storage implementation has to be inspected if it supports expiry in the given storage area. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@kkcmadhu - reading you comment it seems unrelated to this thread, and it doesn't contain information about your environment. Please create a new thread in the Q&A section: https://github.com/keycloak/keycloak/discussions/categories/q-a |
|
I have a scenario to consider: For e.g.: |
hi @ahus1 ,thanks, not sure why i posted it here.. I am pretty sure, i have pasted it in some wrong tab/window. |
|
@stianst I think it is a good idea to provide a generic way for expiration tracking and notification for different entities. The expiration strategy Expire if entity not used for x days should be supported. The following needs to be customizable Entity: The entity which should be handled if not used (e.g. User) A complete use caseA user should get a notifcation email if the account wasn't used for login for 120 days. When this email was sent, the account should be deleted after 30 days if there wasn't a login during these days. Implementation proposal
Data model(entity, id, action, ts, handled) is stored and should also be accessible via Admin API. |
|
@stianst has there been any movement on a feature like this? I would be very interested in this capability. |
|
Hi guys, not sure if this is appropriate here, but nevertheless: |
|
@pselvini : bad luck then ! I'm sure they will find a way to create a new account if they miss the deadline. |
|
During Keycloak Dev Days we talked a bit about this. Our discussed use cases are both security and GDPR compliance. A user with some access permission who didn't log in for some time should probably not have these permissions anymore. If they do need them, the notification(s) remind them to log in. The scenario is quite simiiar to the one @jbman outlined before. To reduce load, it might be a good idea to not store any new login, but only if it's significant enough. That means that it might be interesting to only save a new login date to the database when "now" differs to the stored value by a (small) percentage of the expiration threshold. However this also needs to respect how long a session lives. E.g. when a session lives for 2 months without relogin and the user should be deleted soon after, they might still be quite active. There seem quite a few people who implemented a simple but poorly performing solution by using user attributes. Another consideration is that a user should also be markable as "never expired", for example some people use emergency admin or technical (tho not technical enough for a client) accounts |
|
Do you really think that updating a lastlogin_timestamp on each login (I mean login events not refresh token) really hurts? If user events are enabled you anyway store someting in the database on every login. We also implemented this using user attributes and an event listener, but we would prefer something out-of-the-box. Besides that we faced two issues:
|
Uh oh!
There was an error while loading. Please reload this page.
A number of entities such as users, clients, and sessions should have the ability to be disabled or removed when they are not in use. Sessions for example already have the ability to be kept alive, while this should also be extended to users and clients at least.
For clients and users there may be different requirements for what should happen if a user expires. It may be the user is disabled after 6 months of inactivity, then deleted (or anonymized) after 12 months.
For sessions today the sessions are removed when they idle-out, which will cause all associated tokens to be invalid, but at the same time it would be beneficial to trigger front/back-channel logouts.
We may also want some generic event mechanism to listen to the above, such as the event listener mechanism we have, but in the future something more robust.
One issue with expiration is having to regularly update entities as they are being kept alive, which can be problematic from a performance perspective.
I'm wondering if it would make sense to create some sort of expiration service, that would store an expiration time for other entities in a separate table in the database (or separate database altogether). This expiration service would also be responsible for running background tasks to trigger actions on the expiration of entities.
All reactions