IBM Integration Community Come for answers. Stay for best practices. All we’re missing is you. Join / Log in Ask a question
I'm currently looking for authentication logs of REST API's hosted on ACE. Let's assume that we have an API that is secured with basic authentication, then I want to see the authentication attempts. More specifically I'm interested in the failed authentication attempts.
If you check the activity log, you see logs like this:
Thread ID 10092 (the bottom one) indicates a successful login since there is date going to mq, but thread ID 27332 and 10092 (top one) indicate failed attempts since there is no data being passed on.
This does not give me info on the failed login attempts.
Also the eventviewer/syslog don't give any relevant info.
Next I've enabled the ExceptionLog for the integration server hosting the API (using embedded listener)
And this one is giving me info on the failed login attempts:
...2023-02-15 11:30:13.410 11504 THROWN BIP2702W SecurityException getUserDNFromBrokerBind 'User does not exist' ['Username and password', 'email@example.com', '', 'ldaps://zzzz.com:636'] APSecurityProvider.java:1348...2023-02-15 11:31:40.856998 296 THROWN BIP2703W SecurityException authorize 'User is not in Broker authorization group' ['Username and password', 'firstname.lastname@example.org', '', 'ldaps://zzzz.com:636', 'gen.HTTP_LDAP_MQPUT'] APSecurityProvider.java:1348...2023-02-15 11:32:24.061001 11504 THROWN BIP2702W SecurityException authenticate 'javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090447, comment: AcceptSecurityContext error, data 52e, v3839' ['Username and password', 'CN=XXXXX (Admin),OU=YYY,OU=XXX,OU=AAA,OU=USERS,DC=xxxx,DC=xxxx,DC=com', '', 'ldaps://zzzz:636'] APSecurityProvider.java:1348 ...
(first line = non existing user, second line = unauthorized user, third line = wrong password)
But it also gives a lot more information :)
Is there any other way of retreiving these attempts, maybe in a more readable format?
Do you have some magic knowledge on hidden properties to enable logging on the underlining web server for both the embedded and the node-wide listeners?
The above property is not visible in the node config, so not sure how to get that information from the node listener.
We also experience delays between a client sending a rest call and logging in the flow after the http input.
Thanks in advance
Hello - I've checked a few things to see if user trace would work or if any other logging mechanism would help, but haven't managed to find anything useful. MQ's streaming queues could be used to monitor per-broker listener traffic, but that would be more work.
ACE v11/v12 aren't really using a "web server" the way IIB v10 and earlier did, which is why there isn't an obvious equivalent to the access log. The C++ HTTP code used in ACE is much more stripped-down, so I think this would have to be new development work. There's an idea at https://integration-development.ideas.ibm.com/ideas/APPC-I-189 and another at https://integration-development.ideas.ibm.com/ideas/APPC-I-684 that would be worth pushing along by voting on them and/or mentioning them whenever opportunity arises (such as at TechCon office hours this week).
As far as the original question goes, I believe the assumption was that the authentication server (LDAP in this case) would log the authentication failures and so a log on the ACE side was considered less helpful: if there were many ACE servers, then having one central auth log would be much easier to work with than having the logs spread across the various servers. It sounds like this might not be the case here, so another idea might be good (didn't see one when I looked).
Thanks for your feedback!
It seems there are 4 RFE's for similar data requests
Maybe they could be picked up together? I voted for all 4.
Currently we have nginx running in from of ACE just to have the access logs so at least we know how much time it takes between receiving the calls and getting the messages inside the flows.
(something went wrong posting it, so it ended up posting 3 times)
In the context of optimizing your approach to B2B API integration, it's advisable to explore the utilization of log analysis and visualization tools such as ELK Stack (consisting of Elasticsearch, Logstash, and Kibana) or Splunk. These tools are designed to facilitate the aggregation, parsing, and visual representation of logs in a manner that's highly intuitive and user-friendly. With their capabilities, you can construct customized dashboards and execute tailored queries that zero in on instances of failed authentication attempts within your B2B API integration.
In addition, crafting custom scripts can prove invaluable for parsing the log files and extracting pertinent information related to these authentication failures. This undertaking involves the composition of code specifically designed to interpret the logs, identifying lines that signal unsuccessful authentication endeavors. Subsequently, you have the flexibility to format this extracted data into a more coherent and legible structure or export it into formats like CSV, JSON, or other structured layouts, which in turn facilitates more in-depth analysis and evaluation.