FusionAuth uses standard SMTP for all email connections. As long as Proofpoint Cloud supports a standard SMTP connection where FusionAuth sends transactional emails, initiates a handshake, and completes delivery, the integration will work. You can reference our documentation for details on configuring SMTP with common providers:

Configure Email

You can manage both flows within a single tenant. Typically, you’d configure separate applications, one for the Admin portal tied to your AD/Entra ID provider, and another for your client-facing site using FusionAuth. You can then use login hints or managed domains to direct users to the correct Identity Provider (IdP).

Identity Provider Hints
Managed Domains

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.

@mark-robustelli thank you. I forgot to mention that I am already consuming FusionAuth events using webhooks, but there is no application ID in the event body. but it is okay i will manage it anyway

Yes, you can create a user without SMTP configured. In the Admin UI, disable the Send Setup Password option and set the password manually during user creation. If you’re using the API, set "sendSetPasswordEmail": false and include a "password" field in the user object.

Users API

During an upgrade, FusionAuth monitors your deployment, and if it becomes unresponsive for more than five minutes, the on-call engineer is alerted. A snapshot of the database is taken before the upgrade, so a rollback is possible, though it is manual and would result in data loss from the time of the upgrade to the rollback. Rollbacks are very rare and have only happened once in the past four years.

You can safely upgrade directly to 1.59, and many customers do skip versions. The upgrade process is straightforward: once started, the deployment status changes to Upgrading and returns to Active when complete. For production instances, downtime is minimal (typically seconds, if at all) because multi-node deployments use rolling upgrades. Most upgrades take under 20 minutes, though in rare cases they can take up to an hour.

FusionAuth never forces you to upgrade, but if you are running a very old version (1–2 years behind) and encounter issues, support may request that you upgrade before troubleshooting.

Upgrading a Deployment

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.

Even though the FusionAuth event log source creation gets stuck and didn't complete. I did notice it made this registry key HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application\FusionAuthApp

fa_event_registry.png

As of 1.59.0 this is possible but it is slightly unintuitive how to do it. It’s entirely driven by the form being used. Here's how to do it:

create a new user admin form: https://fusionauth.io/docs/lifecycle/manage-users/admin-forms make sure you omit the 'password' field from the form assign the form to your tenant create a new user

You can also create a user directly via the API with no password.

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.

@francis-ducharme-0 You may have to parse the json returned from the get and modify a few things. Does the application get created but not work or does the application not get created? I would think you would need to take the relevant parts from the returned application then create the application under a new tenant? Remember you will have to use the new TenantId in the Request Header. If you are not supplying the TenantId, it will use the default.

On a side note: If you are still interested in a duplicate application across tenant feature in the API, you might want to put a request in.

You’ll need to disable or mock CAPTCHA in a test environment and adjust rate-limit settings in FusionAuth’s config or use test API keys to avoid hitting production limits during automated runs.

@lambert-torres You can get support for FusionAuth. Please see the pricing page if you are interested. I'm not sure if this is your exact situation, but you might want to look at this blog post as well.

@witard91335 Interesting, how do you see the flow working? What kind of tags are you trying to track though FusionAuth?

Hi @mark-robustelli, thanks for your reply. I need an API that logs out a user, but apparently that’s not possible. Is there any way or approach to log someone out.

Good question. I believe this is due to how we implemented our PATCH calls. If you are making a straight API call, you can change the Content-Type header to application/merge-patch+json which will instead overwrite the existing array with whatever you have provided. That's the most straightforward way to replace array values. There are other methods detailed in the doc below but those involve removing values one by one instead of just overwriting them. The downside here is that I don't believe Client Libraries usually support the merge-patch header.

https://fusionauth.io/docs/apis/#the-patch-http-method

If you believe that you have discovered a bug or issue with FusionAuth, please log an issue below.

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

To note, you will likely want to be listening to the registration.update webhook for changes to the registration object prompted by additional fields the user needs to have completed based on what is a required field for self service registration.

In the case of a user entering all these fields "manually" (as part of a registration form) we will create the user and the registration at the same time (thus transmitting all information, including all required registration fields, as part of the user.create and registration.create events).

However, in the case of a social login, the user and registration will be created after the IdP provider returns information via the user.create and registration.create events. Additional registration will be asked of the user as part of the complete registration process (if there are additional required fields) and that additional information will be transmitted as part of the registration.update event.

https://fusionauth.io/docs/extend/events-and-webhooks/events/user-registration-update

The transient policy is not something FusionAuth will support for the SAML NameID policy. From the SAML standards doc, a transient NameID is supposed to be a temporary value which is not a good basis to build a link between two identity systems on. That is the main reason FusionAuth does not support this policy as it would likely lead to issues later down the line with the Identity Provider. Apologies for the inconvenience but having the User ID/UUID shift or change would cause problems as FA relies on a consistent User ID/UUID(NameID) to make a SAML link work.

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Currently, there is not a way to turn it off. Our air gapped license is still going to try to make that call out to us, but that won't cause any issues. The difference being that a normal license would have issues if it could not "phone home" back to us whereas the air gapped license won't have issues but it will still try to make those calls.

If you want to change the font on the hosted login page and the login experience users are offered through FusionAuth, then this can be changed via our Themes. Very likely you will want to update the CSS associated with the theme you are using for the FusionAuth Application/Tenant. Changes to the theme can be completed through this API: https://fusionauth.io/docs/apis/themes/advanced-themes.

Alternatively, you can use the Admin UI to make changes to your CSS as well.