You have a variety of ways to approach this, with different tradeoffs around functionality, effort and cost. It also matters if the spam accounts are being signed up for by humans or bots.

use a webhook to prohibit bogus users from being created by setting the user.create webhook to be transactional. You'd then write a service that could examine the user object, including email address or other attributes, and return a non-200 value to fail their creation. Details on webhooks. This is available on the community plan.

use email verification to prevent spam users without an email inbox from using your application. Details on configuring this functionality. This is available on any paid plan.

use a self-service registration lambda, and examine the email address and other information for a user. If a user is obviously bogus or matches a pattern, you could return a message stating they can't register, or to call you for assistance. Details on using this lambda. This is available on any paid plan.

turn on CAPTCHA which will make it harder for bots to sign up. This requires an enterprise plan.

@cristian What are you using for the SSO Bridge? Also, If you don't want the user to enter their credentials on FusionAuth's login page, what will be acting as the Identity Provider (IdP)? I'm not 100% clear on your use case, but have you check out Connectors. Seems like that might be a way to go.

@cristian Glad you got it rolling.

@cthos Thanks for the feedback. Since it does appear that you can configure as required, I'm not sure this constitutes a bug. However if it is confusion to you it is likely to others as well. It may be worth opening an issue for the dev team to take a look at.

@bonfattidaniele Is auth.easycbam.eu your domain? Is bbdb8f55-65e7-4de7-a5ff-f08df4ea8005 your client_id? Is 9f144ac0-3006-e653-2ce1-ba98bb40f3eb your tenantId? It appears that those values may not have been updated if not. I am not an Apache expert so I am not sure what implications removing those statements is going to have. Can you try updating those ids, domains and other variables in the config to see if that works?

@spydmobile Are all the errors specifically about the CORSConfigurationCacheLoader or are there others?

@spydmobile said in Struggling to backup selfhosted fusionAuth.:

2025-01-31 16:33:45 fusionauth-1 | 2025-01-31 11:33:45.952 PM ERROR com.inversoft.scheduler.LogAndRetainFailureHandler - The scheduled service [class io.fusionauth.api.service.cache.CORSConfigurationCacheLoader] failed but will be re-run.
2025-01-31 16:33:45 fusionauth-1 | org.apache.ibatis.exceptions.TooManyResultsException: Expected one result (or null) to be returned by selectOne(), but found: 2

Yes, it is possible to configure a custom domain for your SAML audience URL using FusionAuth's Custom Domain feature. This setup allows you to map your desired domain, e.g., https://auth.company.com, to your FusionAuth instance, enabling the SAML audience URL to use your custom domain.

Steps to Achieve This:

Set Up a Custom Domain: Configure a custom domain in FusionAuth (available for production deployments). Once the custom domain is set up, the SAML audience URL will change to reflect your domain, e.g., https://auth.company.com/samlv2/sp/<id>. Update DNS Records: Point the custom domain (auth.company.com) to FusionAuth Cloud using the provided instructions during setup. Verify SAML Configuration: Ensure the custom domain is reflected in the audience URL and SAML metadata. Update your SAML federation partners with the new audience URL.

Additional Notes:

Issuer Setting: The "Issuer" setting on the tenant configuration only affects JWTs and is unrelated to SAML audience URLs. Custom URL Limitation: You’re correct that the login.fusionauth.io option allows for aliases to the default company.fusionauth.io domain but does not impact SAML audience URLs. Setting up a full custom domain resolves this limitation.

Yes, it is possible to configure an Application with the SAML IdP feature enabled and use it as an IdP for another Application within the same Tenant.

The error you’re encountering indicates that FusionAuth cannot find an Application configured as a SAML IdP with the Issuer URL https://company-stage.fusionauth.io/samlv2/sp/af59262c-79ba-48c6-a0a2-4ab1d2fc15d3. This URL corresponds to the Identity Provider you configured in Settings > Identity Provider.

Resolution:

To fix this issue, update the SAML configuration for Application B as follows:

Navigate to Application B > Edit > SAML. Add the Issuer URL (https://company-stage.fusionauth.io/samlv2/sp/af59262c-79ba-48c6-a0a2-4ab1d2fc15d3) in the Issuer field.

By doing this, FusionAuth will recognize the SAML request and correctly map it to Application B.

The behavior you are experiencing is working as designed.

Currently, only the global_admin role can bypass the OTP requirement to disable 2FA. While the user_support_manager role allows managing other user account aspects, it does not have the necessary permissions to bypass 2FA for removal.

Feature Request Option:
If this functionality is critical for your workflow, you could consider submitting a feature request to extend this capability to additional roles in a future release. Or review this issue and comment if it meets your needs.

@stefan-0 I don't really see where there is an issue here, we wouldn't want to actually keep the Azure AD access_token if you want it just add something to the openid reconcile lambda and store it as needed.

https://fusionauth.io/docs/extend/code/lambdas/openid-connect-response-reconcile

I can't speak to FusionAuth in particular, but when you have a public client you ideally don't want to use the client secret for anything, since SPAs / Mobile Apps / etc cannot keep a secret.

Edit: Found this Github issue marked as wontfix: https://github.com/FusionAuth/fusionauth-issues/issues/2173

If you do need a confidential client for something you should have a separate client for it.

So, my take would be that since you shouldn't be using that secret for anything you shouldn't need it to be required for any flow.

You also didn't ask this but you do want to have PKCE enabled for your SPA's client.

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

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

Thanks for your answer. I got it.

MAU Billing in Non-Production Environments:
Authentication activity in your non-production environments will not count toward your MAU billing as long as you are not using the "production" license key on those instances. How to Ensure Testing Does Not Impact MAU Totals: Use separate non-production license keys for your testing environments. Ensure these keys are applied to your non-production instances, isolating them from your production MAU calculations.

For more information, refer to the following resources:

FusionAuth Licensing Documentation What Makes a User Active?

This setup allows you to run comprehensive automated tests in your non-production environments without affecting your billing.

Bulk Registration of Existing Users:
FusionAuth does not currently provide a bulk endpoint for creating user registrations. However, you can achieve this by using the Create User Registration API to programmatically register users to app2. This requires iterating through the list of existing users and making an API call for each user to add the new registration. Best Practices for Future Scenarios:
To avoid manual one-time activities like this in the future, consider the following approaches: Enable Self-Service Registration:
If you are using FusionAuth's hosted login pages for user sign-ins, you can enable self-service registration for app2. With this feature, a user will automatically have a registration created for app2 when they attempt to log in for the first time. Programmatic Registration:
Implement a workflow in your onboarding process that ensures users are automatically registered to all relevant applications when they are created or updated in your system. Custom Scripts for Batch Processing:
Write a script to fetch all existing users and register them to any new applications as needed. This can be reused whenever new applications are added to your system.

References:

Create User Registration API Self-Service Registration

These steps should help streamline your workflow and reduce manual intervention for future scenarios.

There seems to be a misunderstanding regarding the deprecation timeline. The /api/user endpoint itself is not being deprecated at the end of the year; only JWT authentication for that API is being deprecated. You can continue to use the /api/user endpoint by switching to API key-based authentication.

Steps to Continue Using /api/user:

Update your integration to authenticate API calls with an API key instead of JWT. Access data.salutation as usual through the /api/user endpoint. This data is part of the user.data object, which is populated by your integration and not automatically generated by FusionAuth.

Steps to Use /oauth2/userinfo:

Write and install a UserInfo lambda which can read the user.data object and augment the userinfo response to include the data.salutation value. Docs on this lambda.

Unfortunately, FusionAuth does not currently support using AWS IAM authentication for database connections or automatic rotation of database credentials. There is an open issue tracking this feature request:
GitHub Issue #973.

For now, this functionality would need to be handled outside of FusionAuth. For example, an external process or tool could be used to manage the generation and rotation of AWS IAM tokens. This might involve periodically restarting FusionAuth on a rolling 10-minute basis to ensure it picks up the updated credentials, or implementing a custom solution that works in conjunction with FusionAuth to manage database authentication. However, such approaches would not be officially supported by FusionAuth.

The POST /api/user/change-password endpoint does not support a flag to require a password reset. However, you can achieve this by using the PATCH /api/user/{userId} endpoint and setting the passwordChangeRequired field in the request body.

Here’s an example JSON for the PATCH /api/user/{userId} call:

{ "user": { "passwordChangeRequired": true } }

Alternatively, you can set this requirement manually via the FusionAuth Admin UI:

Navigate to Users > Manage User > Edit User Dropdown. Select Require Password Change.

Documentation for reference:

Update a User

This ensures the user will be prompted to reset their password upon their next login.

You can retrieve this data using FusionAuth's API, which provides specific endpoints for users, entities, and entity grants. The users object includes a registrations section that lists the applications each user is registered with. Here are the relevant API endpoints and documentation:

Users: Search for Users Entities: Search for Entities Entity Grants: Search for Grants

Steps to Retrieve Data:

To fetch all users, entities, or grants, perform a search query with a queryString parameter set to *. Use pagination as described in the API documentation to handle large datasets efficiently.

This approach allows you to systematically acquire the information your data engineers need on a daily basis.