Posts made by dan

dan

@kasir-barati Hiya, welcome to FusionAuth. Sorry, just ran across your forum post today.

There is no way to assign constraints to user.data fields within FusionAuth, but there is an open issue that I encourage you to upvote.

You can require usernames to be unique in a tenant, using the Unique usernames setting. It is, however a feature which requires a paid plan.

Another alternative, rather than

fetching all users and then looping over users
would be to search for the username before creating the user. Using the search functionality that wouldn't require scanning all the users. You can use a transactional webhook to fail user creation if your uniqueness rules are not met.

dan

This is due to a bug in the openjdk java library that the docker image uses. You can learn more about the bug here and track our fix (which looks like upgrading the java image our docker file users) by following this bug.

Until then, the workaround is to pass this java argument at start time:

-XX:UseSVE=0

This argument disables the use of the SVE extension, which is provides "better data parallelism for HPC and ML".

You can do that with the FUSIONAUTH_APP_ADDITIONAL_JAVA_ARGS environment variable in your Dockerfile. Here's an example:

  fusionauth:
    # ...
    environment:
      # ...
      FUSIONAUTH_APP_ADDITIONAL_JAVA_ARGS: -XX:UseSVE=0

dan

When running FusionAuth in Docker on an m4 mac, I see this error:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x0000ffff8d33fc5c, pid=1, tid=21
#
# JRE version:  (21.0.4+7) (build )
# Java VM: OpenJDK 64-Bit Server VM (21.0.4+7-LTS, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# j  java.lang.System.registerNatives()V+0 java.base
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  S U M M A R Y ------------

Command Line: -Dfusionauth.home.directory=/usr/local/fusionauth/fusionauth-app -Dfusionauth.config.directory=/usr/local/fusionauth/config -Dfusionauth.data.directory=/usr/local/fusionauth/data -Dfusionauth.log.directory=/usr/local/fusionauth/logs -Dfusionauth.plugin.directory=/usr/local/fusionauth/plugins -Djava.awt.headless=true -Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true --add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.util=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED -DfusionAuthApp87AFBG16 -Xmx512M -Xms512M io.fusionauth.app.FusionAuthMain

Host: AArch64, 14 cores, 7G, Ubuntu 24.04.1 LTS
Time: Wed Jan 22 12:35:29 2025 UTC elapsed time: 0.025614 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread (0x0000ffff9802c010):  JavaThread "Unknown thread" [_thread_in_native, id=21, stack(0x0000ffff9e152000,0x0000ffff9e350000) (2040K)]

Stack: [0x0000ffff9e152000,0x0000ffff9e350000],  sp=0x0000ffff9e34e000,  free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
j  java.lang.System.registerNatives()V+0 java.base
j  java.lang.System.<clinit>()V+0 java.base
v  ~StubRoutines::call_stub 0x0000ffff8d337144
V  [libjvm.so+0x8338d8]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x218
V  [libjvm.so+0x80f488]  InstanceKlass::call_class_initializer(JavaThread*)+0x284
V  [libjvm.so+0x8101a8]  InstanceKlass::initialize_impl(JavaThread*)+0x528
V  [libjvm.so+0xdc7138]  Threads::initialize_java_lang_classes(JavaThread*, JavaThread*)+0xe8
V  [libjvm.so+0xdc9104]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x3f4
V  [libjvm.so+0x8c68d4]  JNI_CreateJavaVM+0x80
C  [libjli.so+0x8bac]  JavaMain+0x7c
C  [libjli.so+0xc20c]  ThreadJavaMain+0xc
C  [libc.so.6+0x8597c]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  java.lang.System.registerNatives()V+0 java.base
j  java.lang.System.<clinit>()V+0 java.base
v  ~StubRoutines::call_stub 0x0000ffff8d337144

siginfo: si_signo: 4 (SIGILL), si_code: 1 (ILL_ILLOPC), si_addr: 0x0000ffff8d33fc5c

Registers:
R0=0x0000000000000000
R1=0x0000000000000000
R2=0x0000000000000000
...

What can I do?

dan

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

dan

Hiya @maciej-wisniowski !

We do not use Apache Struts in FusionAuth.

Hope that helps.

dan

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.

dan

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?

dan

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.

dan

Does FusionAuth work with resend, the email provider?

dan

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

dan

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?

dan

Here's the PR making the doc better:

https://github.com/FusionAuth/fusionauth-site/pull/3371

dan

Also, why doesn't FusionAuth expose the default signing key, HS256, at http://localhost:9011/.well-known/jwks.json?

@fusionauth-qhj5e We don't publish the HMAC key to JWKS.json because if we did, anyone would be able to find it, and sign JWTs as your FusionAuth installation. HMAC keys should only be used when both parties can share a secret.

I'll update the docs to make that clearer. Sorry!

https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/endpoints#json-web-key-set-jwks

dan

@sspinn Hiya, I'm in the admin console pretty regularly and haven't seen this behavior.

Can you narrow down the replication steps so we can try to recreate?

Which version of FusionAuth you are running and what database you are using will also be helpful.

dan

Another option that works as of today is to set up a tenant to tenant connector.

Add a connector to the new tenant. Point it at the /api/login endpoint of the old tenant, including an API key as a header.

Change your app to send everyone to a new application in the new tenant.

When the user logs in to the new application, if it is the first time they've been seen, the old tenant data, including password, will be queried. The password hash will be transparently migrated to the new tenant.

This slow migration takes time, but is another option.

dan

Hi @jamesbaxter . Sorry, just saw this now. I don't have the example app available. Sorry!

dan

When I navigate to the Reactor page, it shows that it's licensed with a Community Edition license.

Custom form fields require a starter license, and because you modified the form field names, FusionAuth thinks you are trying to use a custom form field. (Note, I'm not suggesting you buy a license--this functionality should work in community edition--but I wanted to explain why you are getting the message.)

With the move to 1.53.2 did you upgrade or use a new instance? If the former, does the issue still appear in a new install?

dan

FusionAuth Cloud instances may or may not have static egress IP addresses; please open a support ticket with your instance name to learn more.

VPC peering is not currently supported, though that issue is the right one to follow for future developments.

You can also use an LDAP proxy to solve this issue.

FusionAuth -> LDAP proxy -> AD

where the LDAP proxy is in the DMZ and AD is configured to only talk to internal network values or the LDAP proxy.

Here's a StackOverflow post with more details.

dan

I want to lock down access between ActiveDirectory and FusionAuth running in the cloud. What is the best way to do that? Can I use VPC peering? It appears to not be supported: https://github.com/FusionAuth/fusionauth-issues/issues/1147

dan

The best way to see this is to visit the theme history github repo.

It is mentioned in the theme upgrade documentation.