Add a lambda function to allow the modification of the SCIM error response

[jaywood128]

Add a lambda function to allow the modification of the SCIM error response

Problem

The error response from a SCIM endpoint is not mutable. A specific example is when a webhook fails, and the following error is returned:

{
    "detail": "Request failed, see errors for additional details.",
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:Error",
        "urn:ietf:params:scim:schemas:extension:fusionauth:2.0:Error"
    ],
    "status": "400",
    "urn:ietf:params:scim:schemas:extension:fusionauth:2.0:Error": {
        "fieldErrors": {},
        "generalErrors": [
            {
                "code": "[WebhookTransactionException]",
                "message": "One or more webhooks returned an invalid response or were unreachable. Based on your transaction configuration, your action cannot be completed."
            }
        ]
    }
}

Solution

We could allow the errors object to be passed to a lambda function to allow for mutation or customization.

In a customer provided example, here is an ideal output for the above error.

{
    "detail": "Specific message generated dynamically by us and returned in the web-hook response.",
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:Error"
    ],
    "status": "409"
    }
}

Related

• Display localized error messages from webhooks #1725
• Allow webhooks to return data to be merged and persisted with FusionAuth data #1696

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[marianooriosplit]

Thanks for submitting this feature request @jaywood128

Since the rfc for SCIM error responses specifies only the status as required, and the scimType and detail as optionals, IDPs may be displaying only that information to their customers, hiding relevant information for troubleshooting or error understanding.

A way to manipulate that response will be really useful to display quality info on failures (from FA directly or web-hook's non-success responses).

[robotdan]

To accomplish this type of result, we would need to add another lambda to allow you to completely re-write the error response and remove our error extension.

[marianooriosplit]

Hi @robotdan, can this be prioritized? It will be really helpful to display real errors to end customers avoiding many interactions between them and our support team. Thanks!