Hi everyone

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', 'xxxxx@yyyyy.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', 'xxxxx@yyyyy.com', '', '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?

@Trevor Dolby 

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).

Hi Trevor

Thanks for your feedback!

It seems there are 4 RFE's for similar data requests

https://integration-development.ideas.ibm.com/ideas/APPC-I-189

https://integration-development.ideas.ibm.com/ideas/APPC-I-409

https://integration-development.ideas.ibm.com/ideas/APPC-I-684

https://integration-development.ideas.ibm.com/ideas/APPC-I-518

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)

(duplicate post)

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.

------------------------------
joann salomon
------------------------------