As of 1.51.1, we now have a dedicated health check API endpoint:

https://fusionauth.io/docs/apis/system#retrieve-system-health has more details

Hiya @maciej-wisniowski !

We do not use Apache Struts in FusionAuth.

Hope that helps.

@pacheco-eaguiar maybe you can use the Login API in the backend to verify user's credentials: https://fusionauth.io/docs/apis/login

Hi

We have an ongoing PCI DSS certification of our system and Qualys scanner reports issue with Apache Struts2 on the (self-hosted) FusionAuth 1.54.0 instance. I think it is a false positive but anyway, they want me to provide them with the Apache Struts version in use. So my question is if FusionAuth uses Apache Struts2 at all and if so, which version is this?

Issue details:

Apache Struts2 Multiple Vulnerabilities (S2-008).

Scanned URL:

GET /index.action?debug=command&expression=%23_memberAccess["allowStaticMethodAccess"]=true,@java.lang.Runtime@getRuntime().exec('0jWw997Z') HTTP/1.1

Validation logic:

QID Detection Logic (Unauthenticated): This QID sends specifically crafted payload with a random string command in the request to check for command execution in .action files. Vulnerable targets are expected to return string "null" in the respond.

As seen in the scanner logs, FusionAuth returns the login page for the above URL, with the JavaScript code containing 'null' text - which seems to trigger the false positive:

Prime.Document.query('.alert').each(function(e) {
var dismissButton = e.queryFirst('a.dismiss-button');
if (dismissButton !== null) {
new Prime.Widgets.Dismissable(e, dismissButton).initialize();
}

No perfect options, but a few workarounds possible

• a connector-like proxy which would intercept Client Credentials requests from their customers and use business logic to validate the client secret against the stored Duende hash.
• stand up a simple proxy in front of the Duende that logs the plaintext client secrets for a period of time before migration (protect these logs of course)
• go to each client and ask them to use a new FusionAuth specific client secret (analogous to resetting user passwords)

More details on the first option. It requires these steps/prereqs:

FusionAuth Entities Setup

• The customer should create new FusionAuth Entities that correlate to the Client ID of all APIs and services currently associated with Duende. For now, let FusionAuth generate a random Client Secret.
• Custom Attribute for Migration: Store a custom attribute such as migration: false on entity.data for all newly created Entities.

Migration Steps

• API/Service Requests Token: The API or service calls Duende's token endpoint.
• Proxy Interception: The customer's proxy intercepts the client credentials request and searches FusionAuth Entities to find the matching Entity by Client ID.
• Migration Check: Use an if/else logic to check if migration: false exists for this client ID. If so, the proxy service proceeds with the client credentials request to Duende using the Client ID and Secret (in plain text).
• JWT Validation: If Duende responds with a JWT, this confirms the Client Secret is correct. The proxy service discards Duende's JWT and then calls the Entity API to update the correct Client Secret and set migration: true on the entity.data object.
• Complete Migration: The proxy service calls FusionAuth's token endpoint to complete the Client Credentials grant. The proxy service then returns a JWT to the end customer’s API/service, migration is complete.

Which of these make sense depend on how many clients you have, your dev teams bandwidth, and your security posture.

We're migrating from an identity provider (Duende) that hashes the client secret when the client credentials grant is used.

How can we migrate these secrets to FusionAuth entities?

While I have not tested it, this documentation shows how to use an SMTP integration to send an email with resend.

This should work fine with FusionAuth's email settings.

Does FusionAuth work with resend, the email provider?

It's a subtle difference, but one-time use refers to the value of the refresh token, which you use against the /oauth2/token endpoint to get a new access token via the refresh grant.

A sliding window refers to the refresh token itself, which has a unique id which stays the same, even as the value of the refresh token changes.

So if you had a refresh token with a lifetime of 4 hours, a sliding window and one time use configured, you might end up with something like this:

• at creation: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value RNhY5yE39t1o2FXKxgyH, lifetime 4 hours
• when the RT is presented to the /oauth2/token endpoint 3 hours after creation: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value Fh95KZLfSMjMNxpR5B4c, lifetime 4 more hours
• when the RT is presented to the /oauth2/token endpoint 3 hours later: id 09cfb961-291a-420f-b5cf-48c5c87a67cc, value baHneP4s0hBHPEk88GPC, lifetime 4 more hours

More details here: https://github.com/FusionAuth/fusionauth-issues/issues/2925

If you have one-time use refresh token, then every time it is used, you get a new refresh token.

If you have a refresh token with a sliding window, every time you use it, its lifetime is extended.

How are these settings compatible?