ibm-integration-busextended-sqlibm-app-connect

How to override the HTML authorization error for a REST API in IBM ACE


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.


Solution

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