@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.

@benlabbe2007 What version of FusionAuth are you running?

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.

@sergey_smirnov, it is awesome that you are able to follow and create steps to replicate the issue. To be 100% I'm not sure if this is a bug or a feature request. If FusionAuth is not behaving as you would like it, I would suggest opening an issue on Github. Be sure to include the details and repeatable steps.

Thanks for your answer. I got it.

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.

@mark-robustelli Thanks for your reply, Mark. If I manage to make it, I’d love to show you how I made it and what it looks like.

@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.