Is it possible to set all users to have the passwordChangeRequired status set to true by default, so they are forced to reset their password upon their first login? Additionally, can we set a default password format as company{username}? For example, a user with the username 1234 would have the default password company1234.

Our FusionAuth instance only lists 11 Lambdas by default, and JWT Populate is not one of them. How can we create a JWT Populate Lambda?

Does FusionAuth provide an API to import roles for an application?

We are using the /api/user/forgot-password API for password resets, with sendForgotPasswordEmail set to false since we send our own email. However, users are now receiving two emails: our custom email and a password reset email from FusionAuth using our template. This issue occurs only in our pre-live and production environments, not in the local Dockerized version. What could be causing this?

1. 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.
2. 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.

We have 5 FusionAuth environments: 4 dedicated to testing and development, and 1 for production. In the testing environments, we plan to run automated tests to register and log in users to verify functionality before deploying new code to production.

1. Does authentication activity in our non-production environments contribute to the Monthly Active Users (MAU) count used for billing?
2. If it does, what strategies can we use to run these tests without affecting our MAU totals?

1. 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.
2. 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.

Current state:

• There is one application: app1.
• We are adding a new application: app2.
• There are 200 users registered to app1.
• New users will be programmatically registered to both app1 and app2.

For the existing 200 users, we would like to register them to both app1 and app2.

Questions:

1. Does FusionAuth provide the ability to bulk register existing users to another application (app2)?
2. What is the best practice for handling such scenarios to avoid performing this as a manual "one-time" activity in the future?

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:

1. Update your integration to authenticate API calls with an API key instead of JWT.
2. 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:

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

In the /api/user endpoint, we had access to the data.salutation value. However, this information is no longer available in the /oauth/userinfo endpoint. Since we are required to transition to the new API due to the old one being sunset at the end of the year, how can we retrieve this value?

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.

We want to remove hard-coded credentials and enable FusionAuth to connect to our PostgreSQL database using AWS IAM roles. Our setup includes FusionAuth running in an EKS deployment and the database hosted in RDS. We’d like to generate tokens (used as the password) automatically, as described in AWS RDS IAM Authentication.

The challenge is that these tokens are only valid for 15 minutes. If FusionAuth loses its connection to the database and attempts to reauthenticate after the token expires, it would fail. While generating tokens through an init-container or similar approach is possible, it doesn't resolve the issue of token expiration for reconnections.

Does FusionAuth have a way to handle this, or are there any best practices you recommend to implement such a setup?

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.

I plan to use the following API call to change a user's password to a default value:

API Endpoint:

POST /api/user/change-password

Example JSON Request:

{
  "applicationId": "12b863f1-f468-4782-9ca1-8753fa8340a7",
  "currentPassword": "long password",
  "loginId": "user@company.com",
  "password": "much longer password"
}

When the user logs in with the default password, I want to force them to reset it. Is there a setting in the JSON request body to indicate that the user should be required to change their password on their next login?