Repository navigation
Replies: 2 comments 3 replies
|
We're not going to support storing this as an attribute on the user. Main reasons are performance as well as users are not the only thing you want to track usage of (clients, groups, etc. are also interesting from this perspective). An additional thing to note here is that it may be okay for you to only update the user when doing a login, but for others with long running sessions (i.e. a mobile app with a permanent login) that wouldn't help as users would not frequently login. My idea here, and I will share more about this at some point, is to introduce a central service for tracking usage and expiration around objects (users, clients, whatever). As it will store it separately we can skip things like worrying about caching. Additionally it opens up to also register listeners or policies that are executed when a resource expires. For example automatically disable or delete a user after a certain amount of inactivity, or send an email to an admin, maybe remove all sensitive roles, but leave it as sort of a non-sensitive less privileged user. That kinda thing would be much harder to do if it's stored as an attribute. |
|
Hi @stianst, have you shared anything about such a "central service for tracking usage and expiration around objects" somewhere yet? If not, is there anything on the roadmap? |
Uh oh!
There was an error while loading. Please reload this page.
There is an older discussion which requests functionality to clean up user accounts which were not used for a longer time: Automatically disable dormant users. #11800
As a prerequisite for such a thing, the last login of each users should be available, so that you could write your own extension or use the Admin API go over all users and process them. It would also be nice to show last login to the user later, as it could help to detect account takeover.
Custom Authenticator implementation
We have implemented an Authenticator which stores the last login in a user attribute. This works but is a bit cumbersime to setup, as you have to create the user attribute and add the Authenticator to the Keycloak browser flow as well as to the IdP post login flow.
In addition if you forget to have it in each flow which could be used, the last login information might miss some logins of specific clients.
Store last login by default as user attribute
So the idea is that Keycloak adds a "lastLogin" user attribute by default, readable by Admin and updated automatically after successful login.
This feature would be enabled by default and you could disable it as an admin, if you remove the user attribute definition.
All reactions