0

I have a REST API developed in IBM App Connect Enterprise v11 which is deployed on an integration server on CP4I on OpenShift, I have set this integration server (in server.conf.yaml) to use a security profile for authentication and authorization:

forceServerHTTPSecurityProfile: "{LDAP}:LDAP_Authentication"

Whenever I send a wrong username/password the broker returns this HTML response:

<html>
<head>
    <META http-equiv="Content-Type" content="text/html;charset=UTF-8">
    <title>401 Unauthorized</title>
</head>
<body>
    <h1>{LDAP}:LDAP_Authentication</h1>
    <h1>401 Unauthorized</h1> This server could not verify that you are authorized to access the document requested.<br>
</body>
</html>

Is there any way to catch this exception and override it with my own exception handler?

My current error handler catches any technical exception thrown by the nodes and maps its BIP codes to a custom defined error code and description and returns them as a JSON response, it does the same behavior with back-end business errors.

The problem with this specific error is that there isn't any thrown exceptions on the message flow level, so the error handler implemented in the REST API isn't aware of this exception at all and not able it to catch it.

Anas Ezz
  • 9
  • 6
  • Please describe your current error handling solution. – kimbert Jul 25 '22 at 08:55
  • My current error handler catches any technical exception thrown by the nodes and maps its BIP codes to a custom defined error code and description and returns them as a JSON response, it does the same behavior with back-end business errors. – Anas Ezz Jul 25 '22 at 13:16
  • Thanks. You should edit your question and include this information. I still do not understand why your error handler cannot process the HTTP 401 authentication error. Please explain what is special about this error, and why your error handler does not automatically handle it. – kimbert Jul 25 '22 at 13:54
  • Thank you for your suggestion, I edited the post with extra explanation. The problem with this specific error is that there isn't any thrown exceptions on the message flow level, so the error handler implemented in the REST API isn't aware of this exception at all and not able it to catch it. – Anas Ezz Jul 25 '22 at 15:06
  • Sorry, yet another clarification required. Are you trying to catch this error in the _client_ API (the API that is trying to authenticate itself with the server). Or are you trying to catch the error in the called API? If the latter, please explain why you need to catch the error before it gets sent to the client. – kimbert Jul 26 '22 at 11:39
  • Yes, the latter. The justification is that the _client_ calling the API has a requirement that all errors are returned in a certain JSON structure and is not expecting any HTML response. – Anas Ezz Jul 26 '22 at 14:06

2 Answers2

0

IIB/ACE error handlers can catch and modify application and technical errors. But I don't know of any way to trap authentication errors before they are sent to the client. You could implement a proxy API that catches the HTTP 401 from this API and returns an HTTP 401 with a JSON response. If you're using API Connect or some other API manager that would be a good place to do it. Otherwise, implement a separate API in ACE.

kimbert
  • 2,376
  • 1
  • 10
  • 20
0

I had a long explanation for why we didn't allow you to do this. Then I remembered we added support for it.

Simply tick the "Treat security exceptions as normal exceptions" in the "Security" tab of the HTTP Input Node properties for SecurityExceptions to flow down the Failure terminal.

Warning: Although we added the tick box, we had fierce discussions whether we should, it could be regarded as a Bad Idea. By allowing this you're allowing unauthorised users access to your flow, you better be very, very sure that your failure flow can't possibly divulge information to the user. Nor should it spend too much time and I/O or you'll be opening yourself up for DoS attacks.

andreasmartens
  • 96
  • 5