10 years into this and I should already know this but:
What's the best way to enable logging on Author & Publish instances to capture all login/logout activity? One of course can enable loggers for any custom authentication not done against AEM's internal auth mechanisms, but how reliably track login/logout and failed login attempts for CRX users - like the `admin` account or other internal AEM accounts? These aren't logged by default to the error log, nor to the audit log.
@tadreeves Please refer below Community URL that highlights two approach of achieving the use case:
what do you mean with "CRX Users"? Every users which does have a valid JCR user? And what types of login?
As today the standard login is using the TokenAuthentication you can check for the creation/removal of the ".token" node in the user's home. That should be pretty reliable, unless someone logs via basic auth.
Sorry, should have been more complete in my question.
I'm looking to log to disk any login attempt (whether success or failure) for a JCR user.
Currently, if someone, say attempts to log on as `admin` to an Author instance, you do see a message like this in the logs if they enter a bad password:
23.02.2022 15:58:08.822 *INFO* [qtp1961517139-70] org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure: Unable to authenticate null: UserId/Password mismatch.
However, that doesn't tell you what user they attempted to log in with. Also, if they then SUCCEED at logging in as `admin`, it won't give you a message that they logged in. In the access.log you get the authenticated user that prints along with apache-combined log format, but it doesn't give you an entry that you can look for that is a unique "this user has just logged in" signal.
I didn't know if there was a class I could crank up logging on that would give me this sort of thing out of the box, or if (as others have suggested) I'll need to write a sling filter to do it.
For access auditing purposes, what I'm after is a log that I could log to disk and consume with Splunk that would give me the equivalent of a `last` and `lastb` in Linux, where you at least log every login event with what user logged in, and any bad login attempts with what user attempted it.
Do you really want to have all that stuff in the AEM logs? Of course you can implement all of that and also log everything. But it's not ootb.
If you want to implement a more thorough protection and detection against malicious attempts to login I would use a full-blown IDP, where this is more in focus.
Do you know of any shrink-wrapped IDP solutions for AEM? Failing that, I do realize that successful/failed logins would add some noise to logs, but given that this client already has some IDP capabilities already, they'd be unlikely to want to acquire another solution when the real problem is just that we don't have login success / failure being logged.
If you don't want to have an IDP, you probaly have to write your own custom logic to handle that. And I haven't thought about how to achieve that in the best way, most likely to you should hook into the authentication subsystem. Worst case is to write your own authentication handler which just logs success/failure along with the username.