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. Existing Role Limitations in FusionAuth

• FusionAuth provides predefined Admin UI roles, which are not modifiable.
• You can review the available roles here:
  FusionAuth Admin UI Roles
• The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available.

2. Requesting Read-Only Roles as a Feature

• FusionAuth does not currently support read-only access roles for applications or tenants.
• The likely reason for this is that users who need to view application/tenant properties often also need to update them.
• However, you can submit a feature request to suggest adding read-only roles:
  Submit a Feature Request

3. Workaround: Implement a Custom Read-Only View

If immediate read-only access is required, consider:

• Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data.
• Relevant APIs for this purpose:
  • Application API
  • Tenant API

Summary

• No built-in read-only roles exist for applications or tenants.
• FusionAuth Admin UI roles are not modifiable.
• You can request read-only roles as a feature via GitHub.
• A workaround is to build a custom, API-based read-only view.

We are evaluating the best permissions to assign different individuals in our QA and Production FusionAuth instances.

From the documentation, it seems that roles for tenants and applications are either create/update or delete, with no built-in read-only roles. Additionally, it appears that we cannot modify the roles for the default FusionAuth application.

Questions:

1. Is there a way to introduce read-only roles in FusionAuth?
2. If not, is there a plan to add this functionality in a future release?
3. We want to grant some users view-only access without allowing modifications—how can we achieve this?

1. User Linking Issues Between SP & IdP-Initiated Logins

No, this behavior is not expected—you should not need to drop and re-link users every time they switch login methods.

Troubleshooting Steps:

1. Are these configured as two separate Identity Providers in FusionAuth?
   • If so, ensure they are both linked to the same FusionAuth user.
   • If they are separate, FusionAuth may be treating them as different authentication sources, causing conflicts.
2. Is Azure using the same application for both login flows?
   • If different applications are used in Azure, they may be sending different user identifiers to FusionAuth.
3. Enable Debug Logging in FusionAuth:
   • Go to System > Event Log and enable Debug Mode in the Identity Provider settings.
   • Compare the SAML attributes (claims) being sent in SP vs. IdP-initiated logins.
   • If they differ, you may need to adjust Azure’s claim mappings to ensure consistency.

2. Ensuring Correct Redirect URL in IdP-Initiated Flow

Yes, RelayState works in FusionAuth, but there are specific requirements:

Check Your FusionAuth Version

• RelayState support was added in FusionAuth 1.41.0+.
• If you are on an older version, FusionAuth will default to the first redirect URL in the list.

Correct RelayState Configuration

1. Ensure the target redirect URL is listed as an "Authorized Redirect URL" in the FusionAuth application settings.
2. URL-encode the redirect URL before appending it to RelayState.
   • Example: https://example.com/welcome → https%3A%2F%2Fexample.com%2Fwelcome
3. Append the encoded URL to the ACS URL in Azure.

Example ACS URL with RelayState:

https://your-fusionauth-instance/samlv2/acs?RelayState=https%3A%2F%2Fexample.com%2Fwelcome

4. Test by logging in via IdP-initiated flow and checking if FusionAuth respects the RelayState.

Additional References:

• SAML Redirects in FusionAuth
• IdP-Initiated SAML Login

Summary:

• User linking issues are likely caused by different SAML claims or separate Identity Provider configurations in FusionAuth. Enable debugging to check for mismatched attributes.
• RelayState should work in IdP-initiated logins if you are on FusionAuth 1.41.0+, URL-encode the redirect URL, and ensure it is allowed in the application's settings.

We are setting up both SP-initiated and IdP-initiated login flows with Microsoft Azure SAML for the same users.

We configured two ACS URLs in Azure:

• SP-initiated: samlv2/acs
• IdP-initiated: samlv2/acs/4e98800a-7123-479f-ace7-92502a9a47dd/39ad6a2d-2559-4b14-9b3e-a611ec4da66a

This setup works but introduces two critical issues:

1. User Linking Issues Between SP-Initiated & IdP-Initiated Logins

• When a user logs in via SP-initiated login, FusionAuth successfully creates a user link.

However, when the same user attempts to log in via IdP-initiated login, the system fails with an error:

"This account is already linked to another user. Unable to complete this login request."

• The only way to resolve this is manually deleting the user link, after which the user can log in again via IdP-initiated flow.

Questions:

1. Is this behavior expected? Shouldn't FusionAuth allow a user to log in using both flows without requiring link deletion?
2. Why doesn't FusionAuth automatically retrieve the IdP user ID during IdP-initiated login to match the user correctly?
3. Is there a configuration option to change this behavior?

2. Controlling Redirect URLs in IdP-Initiated Logins

• Our FusionAuth application has multiple OAuth redirect URLs configured.
• During IdP-initiated login, FusionAuth always selects the first redirect URL from the list, ignoring RelayState from Azure.
• We attempted to specify a RelayState parameter in the Azure configuration, but FusionAuth does not appear to recognize it.

Questions:

1. How can we ensure FusionAuth uses the correct redirect URL during IdP-initiated login?
2. Does RelayState work in FusionAuth for this purpose, and if so, what is the correct way to configure it?

This behavior is due to FusionAuth’s default settings for email templates. The Magic Link URL is template-driven, and by default, it may reference a local development environment unless explicitly configured.

How to Fix This:

1. Customize the Magic Link URL in Email Templates

   • FusionAuth allows you to update the email template directly.
   • You may want to use the FusionAuth CLI and version control to manage email templates.
   • Refer to the note in this documentation for details:
     Email Templates & Replacement Variables

2. Update the Tenant Configuration

   • If you want to avoid changes to the email templates, you can put the link in the tenant object and have your template pull from there. To ensure Magic Links point to the correct domain (auth.example.com), update your tenant’s data object using the Tenant API:
     Update a Tenant API
   • This API allows you to populate the tenant.data object.
   • Then you can use it in your email templates.

Summary

• Magic Links use email templates, which may default to localhost:9011.
• Updating tenant settings allows you to set the correct domain dynamically.
• Use the Tenant API to configure the Magic Link domain properly.

I’m just starting to work with Magic Links in FusionAuth.

Our FusionAuth service is hosted at company.fusionauth.io, but the Magic Link being generated contains localhost:9011 as the domain.

Is there a configuration setting I’m missing?

There is no direct way to determine from the user object whether a password has been set.

1. Tracking Login Method (But Not Password Status)

• You can determine how a user logged in by using the authentication_type field in the user.login.success webhook event.
• This will tell you if they authenticated via Google, Password, or another IdP, but it does not indicate whether a password exists.
• Webhook Reference: User Login Success Event

2. Allowing Users to Set or Update a Password

If you want IdP users to be able to set a password, you can enable the User Self-Service Form in FusionAuth.

How to Enable Self-Service Password Management:

1. Navigate to: Application > Registration > Form Settings > User Self Service
2. The default self-service form includes a password field, but you can customize it or create a new form under Customizations > Forms.
3. Once enabled, users can access their account management page to update their password.
4. The Account URL can be found by "Viewing" the FusionAuth Application in the UI.

FusionAuth Account Management

Summary

• FusionAuth does not provide a direct flag to check if a user has a password.
• You can track login methods via webhooks but not password existence.
• The best approach is to enable self-service password management, allowing users to set a password themselves.

How can we determine whether a user has set a password?

The passwordLastUpdateInstant field contains a timestamp, but in cases where a user signed in using a Google Identity Provider (IdP), this does not indicate whether they ever set a password.

Our goal is to allow users who originally authenticated via Google IdP to add a password to their account if they don’t already have one.

Your request body looks correct for a basic search by email and should return a result if a user with that exact email address exists in your system.

1. Ensure You Are Using POST (or Use GET with Query Parameters)

• The /api/user/search endpoint supports both POST and GET, but they expect different input formats.

If using GET, you must provide query parameters, such as:

GET /api/user/search?ids=<user_id>

2. Searching for Partial Matches

If you want to find all users with a certain email domain, try using a wildcard search:

{
  "search": {
    "queryString": "*@email.com"
  }
}

3. Verify API Key Permissions

If you still get empty results, ensure that:

• Your API key has sufficient permissions to query user data.
• The user records exist in the database.

4. Further Reading on User Search

For more details on how to construct search queries, refer to:

• Elasticsearch Search in FusionAuth
• User Search with Elasticsearch

I'm trying to retrieve a list of all users stored in FusionAuth using the /api/user/search endpoint but keep getting empty results.
To troubleshoot, I tested the request in Postman, sending a POST request to /api/user/search with the following body:

{
  "search": {
    "queryString": "email@email.com"
  }
}

However, the response I receive is:

{
  "expandable": [],
  "total": 0,
  "users": []
}

Am I doing something wrong? Is there a better guide on how to format and send this request correctly?