Having contemplated raising a bug for this issue, I've discovered that it, or something very similar, is in fact already the subject of a GitHub Issue. The issue was raised out of this Forum Thread, which provides some avenues for further investigation. Thanks for the responses @mark-robustelli & @kvi68507

@calumhall96 I didn't want you to think no one was looking at your post. I am not familiar with this set up so it is going to take me a while to check it out. In the mean time, if anyone has any ides, please speak up.

@Scot Woo-hoo, glad you got rollin'!

@otislinker345 I believe the 'verify' is to make sure it is a valid JWT indicates the signature is valid and the payload has not be tampered with. You will need to look at the roles in a valid JWT to determine if a user has that role.

I think you should implement custom registration or login logic using FusionAuth's webhooks or API. For example, you can check the application context during login and prevent users from being registered or authenticated in an application they are not supposed to access.

You should ensure that the redirect URI you are using is correctly configured in your application settings on Aithor. It should match the expected URI exactly.

@cluong Hmm, Just to verify, when you submit the data, do you get a URL that looks similar to this?
https://sptest.iamshowcase.com/ixs?idp=581409a977a79eb0f979f2f591204c8f69f0f334

It does not surprise me that the WebAuthN Wizard would fail if we cannot get the url provided to work.

For clarification, it is my understanding that iamshowcase is the SP in this test case and FusionAuth is the IDP. I never used the "Initiate login URL" when setting up the SP initiated SSO.

For the record, if I enable "Enable IdP initiated login" from the SAML tab of the Application, I too am able to see the federated page.
When setting up the SP initiated SSO, I do not use the url provided by "Initiate login URL."

Would you be able to share the Metadata URL or the xml that it produces? Could you also share a copy of your Application -> SAML tab configuration. (feel free to mark it up and hide any information you do not want public.) If that does not work for you, I suggest setting up a test instance so you can share some more detail so we can get this working for you. Also, what version of FusionAuth are you working with?

@tschlegel Thanks for sharing the update!

@fusionauth-qhj5e Here is some documentation on the subject. Hope it helps.

As of 1.51.1, we now have a dedicated health check API endpoint:

https://fusionauth.io/docs/apis/system#retrieve-system-health has more details

@paulp It will only work with Outlook if you disable all security features. Sure you can manually re-apply security features one-by-one but that's just madness. There's not even an option to disable security for an individual inbox, it has to be organisation wide 😵

Either Outlook really don't want you using SMPT Auth or they just can't support this. Went with AWS in the end.

Thank you for share this information............

@randall Glad you were able to figure it out.

Currently, FusionAuth does not have native support for limiting users to a single session. However, this can be achieved programmatically using API calls.

Steps to Restrict to a Single Active Session:

User Logs In:
Upon a successful login, you will receive a new JWT for the session.

Retrieve Existing JWTs:
Use the GET /api/jwt/refresh endpoint to fetch all active JWTs for the user:

GET /api/jwt/refresh?userId={userId} Documentation: Retrieve JWTs

Revoke Other Sessions:
Loop through the retrieved JWTs and revoke all tokens except for the one associated with the most recent login. Use the DELETE /api/jwt/refresh endpoint to revoke each token:

DELETE /api/jwt/refresh?token={token} Documentation: Revoke JWT

Considerations:

This approach assumes the most recent login session is the one you want to keep active. It requires handling session management programmatically on your end.

Feature Request:

There is an open request for native session-limiting functionality in FusionAuth. If this feature is important to your use case, you can upvote the request on GitHub:
GitHub Issue #1363

To handle nested routes and query parameters in this scenario, the solution typically involves using the redirect_uri and state parameters as part of the authentication request. These parameters allow Salesforce to pass the user's intended destination to FusionAuth, so the user can be redirected back to the correct route after login.

Implementation Steps:

Configure the Redirect URI:
Salesforce should include the destination route (including any query parameters) in the state parameter of the authentication request sent to FusionAuth. This ensures that the user's original route is preserved during the login process. State Parameter Usage:
The state parameter can store the desired nested path and query parameters. Once FusionAuth completes the authentication, it will pass this state parameter back to Salesforce, which can use it to redirect the user to the correct location.
Example: User tries to access https://myapp.my.salesforce.com/customers/services/somenestedpath?someSearchArg=value. Salesforce sends the following request to FusionAuth:
https://your-fusionauth-domain/oauth2/authorize?client_id=yourClientId&response_type=code&
redirect_uri=https://myapp.my.salesforce.com/services/auth/test/FusionAuth&state=/customers/services/somenestedpath?someSearchArg=value After login, FusionAuth redirects back to Salesforce with the state parameter, allowing Salesforce to guide the user to their intended destination. Limitations: Check Salesforce’s documentation to confirm if it supports appending custom state or deep-linking query parameters for redirection. If Salesforce does not support this behavior, it may be a limitation of the platform or the integration.

Next Steps:
Review Salesforce's documentation or consult their support to verify how to include deep-linking information in authentication requests. FusionAuth’s integration supports the state parameter for scenarios like this, but Salesforce must support passing and utilizing this information as part of the redirect process.

You can submit feature requests on FusionAuth’s public GitHub repository. Here’s the link: Submit a Feature Request.

Tips for Submission:

Be as detailed as possible when describing your request. Include how the feature would work, its intended functionality, and the overall goal or problem it addresses. Providing use cases and examples can help prioritize the request.

FusionAuth does not currently provide out-of-the-box support for security questions.

If security questions are critical to your solution, you would need to implement this functionality externally and integrate it with FusionAuth using API calls. For example:

Authoring Security Questions: Create a custom interface for users to set up their security questions and store these securely in your system. Using Security Questions During Registration: Extend your registration workflow to include security questions, then associate the responses with the user data stored in your database. Using Security Questions During Credential Recovery: Implement a custom flow to verify the user's identity using security questions before proceeding with a password reset, and use FusionAuth’s APIs to handle credential recovery.

By building this functionality externally and integrating it via FusionAuth’s APIs, you can achieve the desired security question workflow while maintaining compatibility with FusionAuth.

FusionAuth provides replay-resistant authentication mechanisms by adhering to industry standards for the technologies it implements. The level of replay resistance depends on the authentication workflow and specific standards followed.

Key Standards:

OAuth 2.0: FusionAuth adheres to RFC 6749, RFC 8628, and OpenID Connect Core, which include mechanisms to mitigate replay attacks (e.g., nonce and state parameters). Documentation: OAuth 2.0 Authorization Code Grant Example Other Standards:
FusionAuth follows established standards for other authentication protocols, such as: WebAuthn: Provides strong, cryptographic-based authentication resistant to replay attacks. SAMLv2: Uses unique assertions and timestamps to prevent replay. OIDC (OpenID Connect): Includes nonce and other mechanisms to mitigate replay.

Replay Resistance Considerations:

Replay resistance is primarily ensured when these protocols are implemented as defined by their standards. FusionAuth provides the tools and configurations necessary to follow these standards. However, deviations from these standards or implementation flaws outside of FusionAuth’s control (e.g., improper handling of state or nonce values) could introduce vulnerabilities.

FusionAuth's TOTP implementation is compatible with most popular authenticator apps that follow the industry-standard TOTP algorithm, specifically those using HMACSHA1. While we cannot provide an exhaustive list, here are some commonly used authenticator apps that are known to work with FusionAuth:

Google Authenticator Authy Microsoft Authenticator LastPass Authenticator 1Password

Compatibility Check:

If an authenticator app does not support FusionAuth’s TOTP, it will simply fail to recognize the QR code when scanned.

Documentation Reference:

For more details about FusionAuth's TOTP implementation and requirements, refer to the FusionAuth TOTP Documentation.

Most users should have no issues using any modern TOTP-based authenticator app.

Unfortunately, FusionAuth does not support changing a user’s ID after the user has been created.

However, when creating users via API, you can specify a custom user ID at the time of creation. This allows you to control user IDs during the initial setup.

API Reference:

Create a User API

Since the IDs are already assigned, your best option might be to adjust your integration logic or recreate the users with the desired IDs.