Hello, thanks for your answer.
> What are the data types? When are they updated? What about meta-realms > such as LockOutRealm? How should they behave? Taking example on counters that I see else where (GlobalRequestProcessor->errorCount) integers should be enough, one of the counters would be incremented on each authentication respectively the success or the failure depending on the result. I'm not talking about counting each request, this is already done by GlobalRequestProcessor->requestCount, but counting requests following a 401 ( OK, you can send Basic credentials directly, but at one moment in the processing the credentials are checked and will increment the right counter) The LockOutRealm is an active element, while I'm just suggesting counters for passive monitoring (with the idea of aggregating data from different Tomcats on a SIEM for example, and give knowledge to people who need before taking a decision instead of anything automatic). For this reason I think LockOutRealm is not related to my problem. However, the realm name might be difficult to know in advance, either you need to discover it by parsing the MBeans, or you can add all similar counters values at a higher level (GlobalRequestProcessor ?) if you have several realms ? This would give a quick overview on what's going on, and an automate would easily find the data. > Do you want to be able to set/reset them? I don't see reason to set them, although resetting could be used. That's not important for me. > I'm (slowly) working on a scheme where you can register a listener for > authentication failed/succeeded events. Would that work for you as > well, or is JMX a lot more convenient for you? Everything would work but we don't know exactly what uses will do other people with that. After installing/administering thousands of Tomcats I'm more likely to expect simple solutions, and log files seem simple enough until you cannot write them (FS full, FS went to read-only, bad permissions, logging.properties configuration that no one completely understands ..) while JMX has its own pros & cons. To think further, I would ask you if the JMX notifications that are still not used in Tomcat could start being used. For example on a LockOut event, this could make sense to notify towards a monitoring tool or a SIEM. With all that in mind, I would rather go through JMX. best regards Eugene Le mar. 4 juin 2019 à 18:59, Christopher Schultz <ch...@christopherschultz.net> a écrit : > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Eugéne, > > On 6/4/19 08:03, Eugène Adell wrote: > > Hi guys, > > > > I started to investigate how I could add 2 new JMX attributes, and > > that doesn't look very difficult even for someone who doesn't look > > at Tomcat's source code often. > > > > My suggestion would be to add these 2 new attributes > > (authenticationSucceeded and authenticationFailed) to all Realms, > > then one could monitor suspicious activity without any access to > > the log files. It is just in a monitoring perspective, not to > > change the behavior for any user as the LockOutRealm is doing. > > > > What do you think ? > > What are the data types? When are they updated? What about meta-realms > such as LockOutRealm? How should they behave? > > Do you want to be able to set/reset them? > > I'm (slowly) working on a scheme where you can register a listener for > authentication failed/succeeded events. Would that work for you as > well, or is JMX a lot more convenient for you? > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlz2o4EACgkQHPApP6U8 > pFhXcQ/+OG93S1MtqMmRRzlsyuz4DQauAVi9BZ9K8HAcPfnYTympS3BnjGkWBIcv > 8zctQbqntMDfHfLjvM3n5FHhf9CO+x2lIKZQ3HFPnfL+FiGMhfassm/u9RDy7zub > Io4MnvrEUhAqRTp5NqNTlh6VWVt88EywYOC3HhsA6w6Y584z+v7i9S+Orp9iuFiV > /PaolzwaCNK6ZQurUs5lZo58uc8ByC/yJAuB1TysHhtNzFK90kakUQN8TJRZIzk8 > lQcyJvS88vZhx46oJ/pt5nkpaAdcIQtp7+OolkEaYVF+ei75aYYVtJ+LZLSldc2u > 6wvFMjUwBf5o6A/mQBmNyGb39aWUwROouszr8cg4IAJ/5MHi+oV6bkD/KAk3jW67 > eKAg/bRdRDQnQoOYzCVdTiL9XPI5eY8kw2uTbZ/DwdSTJ6rJKLjmzNdM37aCWWww > C6PVIoBDH6TrcVxOwq/xmZqkkJ6NMgpFp+EWRFQHYAXKHC/hS9nCAWTMGQ0Pw8QC > ei5RdTQs0S66wZd0SupXTx4kmBmYmtxLPUmXS6qTVUi+0h0xDToNwYb+pPKS048t > D4Oyrn7zoKXJwLL2Zm1TY8g9xsAtXKOvi9kA5ITgZL3eBKHydwjYZxUXiw1mlo5v > QZaLpLPIyEbqxQCHlqStCNRi91jRr7ACFoWz3xwgBu4gmEhDosw= > =NTij > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
