Topics created by dan

Yes.

A few options. Let's assume you have a FusionAuth instance hosted in your cloud (the cloud instance) and that you'll be running an instance on the cruise ship (the cruise ship instance). The cloud instance contains all user data. The cruise ship instance is going to be set up fresh for each cruise, with a copy of data from the cloud instance. It'll contain just the users on the cruise ship, and applications on the cruise ship will be set up to authenticate against it.

Overview Table Option Use When Notes Works With FusionAuth Cloud Use The Cloud Instance You have connectivity. Included for completeness. Yes Cruise Ship FusionAuth With QR Codes You only want to let the user modify their profile, are okay with the risk of the QR code being stolen and the user being impersonated. Need to use the API/SDKs to fully implement. Yes Cruise Ship FusionAuth With Existing Passwords You want the cruise ship instance to be the source of truth for users on the ship. No Cruise Ship FusionAuth With Existing Passwords And Changes Allowed to Cloud FusionAuth If accounts of cruise ship users need to be modifiable by people on the cruise ship and on land. Requires careful profile and credential merge logic. No Use The Cloud Instance

Use the cloud FusionAuth instance for all requests. This is the simplest solution, though it may be costly or lead to degraded functionality.

This is mentioned for completeness, but doesn't really address the core issue of missing or intermittent internet connectivity.

Cruise Ship FusionAuth With QR Codes

Here you are migrating the source of truth for these users to the cruise ship instance, excluding passwords, and then syncing the profile data back.

The main reason to choose this option is because it works with a FusionAuth Cloud hosted cloud instance, where you do not have access to the password hashes.

Steps: Copy user profile data to the cruise ship instance using the User API. Create a QR code that is associated with each user and add it to the ticket (or provide it separately). The user can then log in by scanning their phone. The QR code should include the user's login Id. Implement using the passwordless API, starting the passwordless login with the users id, and completing the login by catching the code and using the complete login API call. Mark the accounts as 'on-cruise' in the user.data field. By doing this, you can clearly differentiate between the users on the cruise and anyone else in your CIAM system. This makes it easier to merge their profile data after the cruise. Set up a webhook to disable any updates to these user accounts in the cloud FusionAuth instance while on the cruise. You can do this by setting up a transactional webhook on user.update that fails when the user being updated has the 'on-cruise' attribute set. When on the ship, users can log in with these credentials and access applications, as well as update their profiles. After the cruise is done, compare the profile update timestamps for all users in the cruise instance with the same account on the cloud instance. If the update timestamps do not match, update the cloud instance with the new profile data. Do not move the password hashes. Remove the 'on-cruise' attribute from users in the cloud instance.

Security Warning: This is a security risk! Understand the security model of an account takeover in the cruise ship instance. If anyone else scans the QR code, they can get access to the user's account.

The benefit is simple merging of data. You also don't need access to the database of the cloud instance, because all the data you are merging is available via the API.

After successfully pushing the data to the cloud server, wipe the cruise ship FusionAuth instance.

Cruise Ship FusionAuth With Existing Passwords

Here you are migrating the source of truth for these users to the cruise ship instance, including passwords, and then syncing them back.

Steps: Build an import script by reading the password hashes and other password data from the cloud instance for the users who are going on the cruise. This requires direct database access to the cloud instance. Import the users using the Import API to the cruise ship instance. Mark the accounts as 'on-cruise' in the user.data field. By doing this, you can clearly differentiate between the users on the cruise and anyone else in your CIAM system. This makes it easier to merge their profile and credential data after the cruise. Set up a webhook to disable any updates to these user accounts in the cloud FusionAuth instance while on the cruise. Do this by setting up a transactional webhook on user.update that fails when the user being updated has the 'on-cruise' attribute set. When on the ship, users can log in with their normal credentials and access applications, as well as update their profiles and password. After the cruise is done, compare the update timestamps for all users in the cruise instance with the same account on the cloud instance. If the update timestamps do not match, build an import file with the profile data and updated credentials. Read the credentials from the cruise ship instance database. Remove the 'on-cruise' attribute from users in the cloud instance. Delete the users' accounts in the cloud instance and import the user data from the cruise ship generated file.

The benefit is simple merging back to the cloud instance, because only one instance accepts changes at a time. A user is either managed by the cloud instance or by the cruise ship instance.

Automated account recovery won't work, so plan to allow staff to reset passwords if needed.

After successfully pushing the data to the cloud server, wipe the cruise ship FusionAuth instance.

Cruise Ship FusionAuth With Existing Passwords And Changes Allowed to Cloud FusionAuth

Here you are migrating these users to the cruise ship instance, including passwords, and then merging them back.

Steps: Build an import script by reading the password hashes and other password data from the cloud instance for the users who are going on the cruise. This requires direct database access to the cloud instance. Import the users using the Import API to the cruise ship instance. Mark the accounts as 'on-cruise' in the user.data field so that we'll know which users to merge. When on the ship, users can log in with their normal credentials and access applications, as well as update their profiles and password. The same accounts can be updated in the cloud instance by users or automated processes on land. After the cruise is done, compare the update timestamps for all users in the cruise instance with the same account on the cloud instance. If the update timestamps do not match, build an import file with the profile data and updated credentials. For the latter, you'll need to read from the cruise ship database. Prepare to merge the data from the cruise ship and cloud instances. Read all accounts with the 'on-cruise' from the cloud instance with an update date later than the start of the cruise. Find all the users on the cruise ships with an update date later than the start of the cruise. For each account, see what changes were made: If a cloud instance did not change and the cruise ship instance did not change, remove the 'on-cruise' data marker and do nothing else. If a cloud instance changed and the cruise ship instance did not, remove the 'on-cruise' data marker and do nothing else. If a cruise ship instance changed and the cloud instance did not, prepare an import entry from the cruise ship instance for this user. Delete the cloud instance account and then import the cruise ship instance account. If a cruise ship instance changed and the cloud instance did as well, prepare an import entry from the merged cruise ship and cloud instances. How you do this is business dependent. There may be user profile data that should be merged, and other data that might belong to either the cruise ship instance or cloud instance. The most recent password, wherever it lives, is the one that you should use for the import. When the merge is complete, write an import entry to a file. Remove the 'on-cruise' attribute at the same time. When all accounts have been merged successfully, delete the cloud instance account and then import the merged account.

Automated account recovery won't work, so plan to allow staff to reset passwords if needed.

After successfully pushing the data to the cloud server, wipe the cruise ship FusionAuth instance.

Other Considerations

If you are only allowing the user to change their profile data, you can move data without accessing the database. If users can change their passwords, you have to have access to the database to re-import them. (Or you can force a password reset.) The same applies to other secrets such as passkeys or TOTP secrets.

Options 1 and 2 work with FusionAuth Cloud hosted servers, but the other options do not because you don't have access to the database with FusionAuth Cloud.

If you allow a user to register on the cruise ship server, you will have to check for merge conflicts. If someone registered on the cruise ship, it is possible someone could have done the same on the cloud instance during the time of the cruise. Since you know all the cruise ship users, you can alternatively create accounts for everyone and disallow on ship registration.

When reading the password hashes, make sure you consult the schema for your version of FusionAuth, because the location of password hashes may change over time.

Account recovery is not available on the cruise ship, so make sure staff understands how to reset a user's password directly via the admin UI.

What is outlined above takes the final state of the user from the cruise ship and propagates it back the cloud instance. If you need to keep track of changes to the user on the cruise ship instance and replay them in order, use the webhook and event log to capture the events locally. Then replay them when the cruise ship docks using kafka.

We have an open issue to make passkeys one of the supported MFA methods.

But you can perform a step up passkey challenge using the APIs or the SDKs by doing the following:

User tries to access a restricted resource Customer app sees if the user has already been granted access (via the presence of a cookie, or some other mechanism). If they have, let them through. If the user hasn’t been granted access, perform a webauthn assertion workflow Call the /api/webauthn/start to get the workflow started Interact with the authenticator to produce the signature and whatever other information is needed. This is authenticator-specific. Call the /api/webauthn/assert to complete the workflow and prove possession of the authenticator If the workflow is successful Write a cookie or whatever if you want to remember this permission Let the user through If the workflow isn’t successful Deny access

If someone doesn't have a passkey enabled, which you can check by calling the /api/webauthn?userId={userId} API, direct them to the self-service account management passkey management pages.

Here are the API docs for the webauthn API.

Yes, I believe so.

It appears that connecting MitID to an application (also called an SP) requires utilizing an approved broker. A broker is essentially an OIDC connector.

Here is a list of official brokers: https://www.mitid.dk/en-gb/broker/current-brokers/.

We haven’t tested this, but based on reviewing Signicat’s OIDC documentation, the process seems fairly straightforward. They are one of the MitID brokers.

You can create two values for the FusionAuth url:

internalFusionAuthURL="http://fusionauth:9011" externalFusionAuthURL="http://localhost:9011"

So basically whenever you are sending the redirect to the browser (pretty much just the authorize and logout URLs) you use externalFusionAuthURL which references localhost.

When you are communicating with FusionAuth from the application backend (the express app) you use the internalFusionAuthURL which references the docker domain name.

I tested that out and it seems to work fine.

Give that a try.

Yes. You can use FusionAuth's OpenID Connect Identity Provider.

I did this a few weeks ago, so am writing these instructions from memory.

Prerequisites:

A yahoo account A running FusionAuth instance (localhost is fine)

Steps:

Go to the Yahoo! developer network and create an app. The redirect URI for Yahoo is https://<your instance>/oauth2/callback Save off the provided Client ID (Consumer Key) and Client Secret (Consumer Secret). Then go to FusionAuth and create an OpenID Connect Identity Provider: <your instance>/admin/identity-provider/add/OpenIDConnect Put the Client ID (Consumer Key) and Client Secret (Consumer Secret) into the Client Id and Client secret fields, respectively. Uncheck Discover Endpoints. Manually configure the endpoints: Set the Authorization Endpoint to https://api.login.yahoo.com/oauth2/request_auth Set the Token Endpoint to https://api.login.yahoo.com/oauth2/get_token Set the Userinfo Endpoint to https://api.login.yahoo.com/openid/v1/userinfo Set the Scope to openid email profile and any other scopes you might need. (I was unable to find an authoritative list, but here's info about the mail scopes.) Update the Button text and Button image as needed. Enable it for applications as needed. Save the Identity Provider.

This is due to non-ASCII characters in headers causing an issue in the FusionAuth parsing code. Cloudflare sends headers with non-ASCII characters (such as cf-region: São Paulo) which triggers this issue.

This is a java-http bug that was fixed in 2024, and released in FusionAuth version 1.51.2.

So, two options:

upgrade to a version of FusionAuth 1.51.2 or newer. This is the recommended approach, but may require some work. as an interim workaround, you can disable the "Add visitor location headers" option from your CloudFlare console. This should not have any negative impact, since we do not inspect those headers.

This is not available today without some glue code.

Currently our suggestion is to use Javascript on the Login page to jam the claim into a meta field that is shown on a Webhook payload, like jamming stuff into event.info.deviceDescription .

Then you create user.login.success webhook, making sure it is transactional. On login, the event is fired that off to your system and then you extract the claim off the event.info.deviceDescription field and make a PATCH call to FusionAuth. In that PATCH call, you add this to a field on user.data.x.

Then once that PATCH is successful, the 200 response back to the user.login.success event which completes the login and triggers the JWT populate lambda. That lambda extracts the claim off the user.data.x field and puts it into the JWT.

It's not pretty but it is the only way to have this work for now. (For self-service registration you can use a custom hidden field, much easier.)

Relevant docs:

https://fusionauth.io/docs/extend/code/lambdas/jwt-populate https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success https://fusionauth.io/docs/apis/users#update-a-user

This is possible in a couple of ways.

First, to allow users to register for an application on login, you need to turn on self-service registration. From the docs:

When you enable self-service registration for an application and a user who does not have a registration for that application successfully logs in to that application, the user will automatically be registered for that application, and have a registration added.

Then the question becomes, how can you disable the hosted login pages self-service registration form?

To do so, take the following steps:

update your theme to remove the link to the "Don't have an account? Create one" link from any pages, including the login page. You can also remove all the content from the registration themed page and replace it with not implemented or similar. However, a sinister user may still be able to post to the register endpoint and create a user if you are self-hosting, block access to the /register endpoint using a proxy if you are not self-hosting, prevent self-service registration by adding an encrypted secret value to all user accounts you create via the API. Then, create self-service registration validation lambda which will examine the user object. If the user object comes through without the secret value, fail the registration. Otherwise allow it through because it is a user who has logged in.

The self-service lambda may not fire unless there are required fields on the registration form, but that behavior is undocumented and may change.

By using a proxy or gateway that supports mutual TLS, you can use it with FusionAuth.

For example, AWS ALB supports Mutual TLS verify where the ALB does client certificate verification. Nginx has similar functionality.

If you are running FusionAuth 'bare' and terminating TLS directly at the FusionAuth server, mutual TLS is not supported.

Hiya,

There are currently no plans to support the full mTLS spec. We are discussing DPoP (tracking issue) internally.

However, depending on your needs, there may be a workaround.

Since the client credentials grant depends on Entities, you can leverage this to inject a client certificate hash into an access token obtained through the client credentials grant.

How this works at a high level:

Client Certificate Registration
During onboarding, your customer (e.g., a bank) registers their client certificate. A hashed value of that certificate is securely stored in FusionAuth (entity.data). The hashing process is outlined in the RFC. Client Credentials Request
When the bank requests an access token using the Client Credentials grant, a FusionAuth Lambda is invoked before the JWT is signed. Augment Custom Claims
The Lambda code looks up the stored certificate hash and injects it as a claim in the JWT. For maximum compatibility with RFC 8705, it is recommended to add this hash to the cnf object in the JWT, like so: "cnf":{ "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" } Accessing the Resource Server or API
The customer presents both the access token and presents their client certificate when calling your API. Validation Flow
Your API: verifies the JWT signature computes a hash of the presented client certificate compares it to the x5t#S256 claim in the token Decision Logic
If the hashes match, the request is bound to the correct client and access is granted to the protected resource.

@theogravity-sb Hmmm. So the issue is that someone is registering with a gmail account they control but it looks like this:

foo@gmail.com with a name of <Dan https://evil.com> which is being turned into a link?

Or am I misunderstanding your question?

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

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.

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.

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

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.

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

It is mentioned in the theme upgrade documentation.

Currently this is not editable in the Admin UI. This value can be set by calling the Tenant API, however.

Docs here: https://fusionauth.io/docs/apis/tenants#update-a-tenant

I was able to do this by:

copying the advanced theme editing it navigating to the Helpers file inside that, going to the head freemarker macro

I removed these lines:

<link rel="stylesheet" href="/css/font-awesome-4.7.0.min.css"/> <link rel="stylesheet" href="/css/fusionauth-style.css?version=${version}"/> [#-- Theme Stylesheet, only Authorize defines this boolean. Using the ?no_esc on the stylesheet to allow selectors that contain a > symbols. Once insde of a style tag we are safe and the stylesheet is validated not to contain an end style tag --] [#if !(bypassTheme!false)] <style> ${theme.stylesheet()?no_esc} </style> [/#if]

If you want to use the CSS field in the theme to store your CSs, leave in

[#if !(bypassTheme!false)] <style> ${theme.stylesheet()?no_esc} </style> [/#if]

which pulls in the CSS associated with the theme. Doing so allows you to add all your custom CSS to the CSS field in the theme and have it automatically included. If you don't do this, make sure you add your CSS to this macro (either directly or via a link). You'll want to make sure you keep it in as you upgrade.

Removing all the CSS will result in a page that looks like the one below.

unstyled login page