If this isn't what you mean, please just give me a little more detail on what you are trying to do and I'll help the best I can.

This is an open issue. To see when this is resolved, you can follow along with the github issue here: https://github.com/FusionAuth/fusionauth-issues/issues/3439

Yes, there's currently no support for using a certificate.

Here's an open tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/3083

Please comment and/or upvote this with any other details that would help the product team prioritize this.

Again, depending on what you want to do and what version you are running, there is the idea of the Tenant Manager applicaiton. This will still not help you with MFA settings thought.

The other option is using the APIs. Since everything in The FusionAuth admin UI is API first, you could create your own application that would allow users you choose to edit them.

Hope this is useful.

I’ve been investigating the issue over the last few weeks.

Having taken a JVM dump while the issue was occurring, here is the stack trace for the thread causing the deadlock

I enabled trace logging in io.fusionauth.http.server.internal to analyse the process in HTTPWorker

The HTTPWorker begins the process of reading and writing the response for the request, and continues for 2.6 minutes until the HTTPServerThread terminates it because the minimumWriteThroughput (16KB/sec) threshold has not been met.

HTTPServerCleanerThread kills the server-side connection mid-response due to a write throughput check that measures average bytes/sec since the first socket write.
The client is waiting for data that the server is generating very slowly.

Analyzing why the server is writing so slowly (16271 bytes/sec):
The call is http://localhost:9012 — FusionAuth calls itself. Client and server virtual threads share the same JVM's carrier thread pool.
With Kubernetes CPU limit = 1000m, JDK 21 uses UseContainerSupport (default), so availableProcessors() = 1 → only 1 carrier thread.

com.inversoft.rest.JSONResponseHandler$BetterBufferedInputStream.read(byte[], int, int) is synchronized — causes virtual thread carrier thread pinning in JDK 21.

BetterBufferedInputStream.read() pins that single carrier thread while blocking on ChunkedInputStream.fastRead(), leaving no carrier thread for the server to write more data. The resulting ping-pong limits throughput to ~16 KB/sec on a 2.5MB response.

HTTPServerCleanerThread computes average throughput since the very first write (not a recent window). With 2.5MB written at 16271 bytes/sec average, that's ~156 seconds (2.6 min) before the average decays below the 16384 bytes/sec threshold.

With 9 themes, the response is small enough to fit entirely within the kernel’s socket buffer (~128KB). The server writes the entire content in one go without blocking on socket.write() (the buffer does not fill up), transitions to the KeepAlive state, and the cleaner can no longer terminate the connection due to write throughput.

As a workaround, I resolved the issue increasing the Kubernetes CPU limit from 1000m to 1050m.
Kubernetes translates the CPU limit into the container’s cgroups, setting 2 carrier threads instead of 1.

With that CPU limit, all themes are recovered properly, also with 35 themes (~6.2 MB response).

Can you reproduce it setting Kubernetes CPU limit to 1000m (1 core) in your environment?

https://github.com/FusionAuth/fusionauth-issues/issues/3082

Best regards.

Anyone here familiar with these numbers?

It may also make sense for you to open an issue with FusionAuth as it is not clear to me if these numbers are coming from FusionAuth or HikariCP.

FusionAuth is very customizable. You should check out things like Lambdas, Webhooks and other various options.

FusionAuth can be self-hosted or can be hosted for you.

FusionAuth handles SAML, SCIM and other various integrations.

FusionAuth is very scalable and gives you great control with api acess and other mechanisms.

Depending on your needs, FusionAuth can be as easy to self host as spinning up a docker image to a full blown complex K8s deployment. It should fit your needs there.

While there is no direct migration guide for the product you are talking about, there are several other migration guides for you to look over that should give you an idea on how to do it.

The problem with putting all the responsibility on the proxy is that it creates another layer of complexity and a single point of failure. If FusionAuth is going to support enterprise-level security use cases, shouldn’t mTLS be handled natively instead of relying on external workarounds?

Upvoting the issue is fine, but depending on a proxy feels more like a patch than a real fix. Curious to hear if others think this approach is sustainable, or if we should be pushing harder for first-class support directly in FusionAuth.

@mark-robustelli said in Is there away to provide error message data from a webhook via either Webhook or Event logs?:

@edschlough If you take a look at the example code from the webhook documentation, it shows how to return errors. Is this what you are after?

Thank you so much
Wow! This is what I need, thank you for sharing

It will be interesting to see if others chime in.

I need a way of validating that a specific step-up auth is bound to a specific operation. I have seen the description of a use case of using trustChallenge and trustToken to validate a FusionAuth change password request. This is kind of what I need to do, but on my API endpoints. I'm wondering if it's possible to validate trustToken using a trustChallenge on my own API.

e.g.
a. call a sensitive request triggering step-up with trustChallenge=1234
b. bind operation with trustChallenge
c. complete step up and receive trustToken
d. validate trustToken using the trustChallenge (this is what I would need to know) and confirm/finalize sensitive operation.