This also works with an OIDC provider and from tenant to tenant in the same FusionAuth instance. Assume you have an app (app1) in your existing tenant and you want to allow users in a different tenant to log in to app1. You can do this with an identity provider.

To do so:

create a new tenant in your FusionAuth instance create an application in the new tenant (app2) add an authorized redirect URL of https://yourinstance.fusionauth.io/oauth2/callback make sure the authorization code grant is checked. create a user in the new tenant use same email address but a different password register the user for app2 create an OIDC identity provider the name should be app2 IDP update the button text to say 'log in with app2 in a different tenant' the client identifier and secret should be the app2 client id and secret the scope should be openid profile email the authorization URL should be https://yourinstance.fusionauth.io/oauth2/authorize the token URL should be https://yourinstance.fusionauth.io/oauth2/token the userinfo URL should be https://yourinstance.fusionauth.io/oauth2/userinfo enable the OIDC identity provider for app1 and make sure to create a registration for that application when a successful authentication is done.

When you visit the app1 login screen, you should now see a button prompting you to log in with app2.

This allows you to do cross tenant enterprise sign on within the same FusionAuth instance.

I think @mark-robustelli is on the right track.

Ensure that you have configured the correct search type.

If you were to remove the configuration file or install into a new directory for the upgrade, you may be picking up the default configuration which will have search.type=database set as the default.

You can change this to search.type=elasticsearch for use with Elasticsearch or OpenSearch, or set an environment variable FUSIONAUTH_SEARCH_TYPE=ELASTICSEARCH.

See search.type in the config reference.

https://fusionauth.io/docs/reference/configuration

@tkates
I was thinking you had created a SAML v2 identity provider in FusionAuth which has a reconcile lambda.

Now, I understand that FusionAuth is configured as a SAML v2 IdP where FusionAuth is the system of record for the users. Thus, the application is setup as a SAML application using the SAML tab for the application which has the Populate Lambda.

Since that Lambda is for populating the SAML response, an option would be to use the Lambda HTTP Connect to update the user inside the populate lambda.

@itai This is what exists today, the team is working on more features for webhooks in upcoming releases.

FusionAuth provides certain guarantees when it comes to the delivery of webhooks. These guarantees are determined by the transaction level that you set for your webhooks. The transaction level can be one of the following:

"No webhooks are required to succeed": In this case, FusionAuth will "fire and forget" the webhooks. Even if all webhooks fail, the operation (like a user update) will still succeed (source).

"Any single webhook must succeed": If at least one webhook succeeds, the operation will succeed. If all webhooks fail, the operation will fail. FusionAuth will retry failed webhooks up to three additional times (source).

"All webhooks must succeed": Every single webhook must succeed for the operation to succeed. If any webhook fails, the operation will fail (source).

In case of failures, FusionAuth will retry sending the payload up to three additional times. If a webhook endpoint times out, this is considered a failure, the same as if a non 2xx status code is returned. If the endpoint does not respond after the retries, the failure will be logged in the system log (source).

It's important to note that if a webhook is transactional and returns a non 2xx status code, the corresponding action will not succeed. For example, if a user login triggers a webhook and the webhook fails, the user won’t be able to log in (source).

JavaMail settings in FusionAuth can be configured under the SMTP settings of a tenant. You can access these settings by navigating to Tenants > Edit > Advanced > SMTP settings. Here, you can add additional properties for JavaMail.

For example, to enable debug mode, you can add mail.debug=true to the additional properties. This will provide more verbose logging for SMTP, which can be helpful for troubleshooting email issues. The debug logs can be viewed under System > Logs and selecting fusionauth-app.log source.

In some cases, you might need to set timeouts for the SMTP connection. This can be done by adding the following properties:

mail.smtp.connectiontimeout=2000 mail.smtp.timeout=2000

These settings will set the read and write timeouts to 2 seconds (2000 ms) source.

If you're experiencing issues with email delivery, it might be helpful to change the SMTP port or switch between TLS and SSL, especially if you're using a cloud service like FusionAuth Cloud, which has certain restrictions on ports source.

Remember to be cautious when enabling debug mode or changing other settings, as it could potentially lead to a large volume of logs or affect the performance of your application.

@evanm Yes you can use the sub inside of the JWT when making any API call to your backend. In your database this will be a unique Id for the user. You can even get more details about the user from FusionAuth by calling the User endpoints.

https://fusionauth.io/docs/apis/users#response-1

As of 1.51.2, there is no way to do this. We keep track of the trusted devices and you can, with certain parameters, retrieve them using this API but there is no detail about a device that It doesn’t have any details that would allow you to revoke trust for a specific device.

If this is of interest to you, future reader, please open a github feature request with details about your use case.

See also this open GH issue addressing this: https://github.com/FusionAuth/fusionauth-issues/issues/2821

This is an example of Third-party Service Authorization.

We store the tokens on the Link, but leave the refresh operation up to the software needing to access the third party API.

This approach has some tradeoffs, but gives more granular control to the application that needs the access token.

How it works:

The developer sets up an 'authorize' button in their application We take care of the authorization/authentication/storage of the refresh token.

... time passes

When they need an access token, they call our APIs to get the refresh token for a particular user They call the 3rd party service to get the access token, They use the access token.

If the access token expires while they need it, they can get the refresh token again and then get an access token.

@mike-rudat

I wanted to confirm that the generic messenger does not have re-try logic built-in on a failure.

@mike-rudat

Yes, I verified using the SAML V2 and PagerDuty Integration. From the documentation, copy the Login URL from the FusionAuth SAML v2 Integration details section and paste it in PagerDuty’s own Login URL field and append the idp_hint query string parameter for an external IdP. In turn, the user was taken directly to the IdP login screen.

@mark-robustelli Thanks, Mark. After having worked with FA some more, I now realize that I don't need it to be a GET. Thanks for the response.

@as-redbios Can you please offer a little more detail. What version of FusionAuth are you using? What are the user actions that are taking place? What do you mean by "always force to re login"? Is this every page they visit?

This endpoint returns a 404 for an invalid or expired verificationId. It is also the case that you can only use a verificationId once for verification before it becomes stale.

What does this mean for your workflow? In my case, I was trying to verify a user's registration in the same request cycle as verifying their email. To do this, I needed to fetch the user response to get the user ID to verify the registration. Naturally, I was doing this after posting the email verification -- the result being said 404.

So, in terms of workflow, if you need to look up a user by verificationId, be sure to do it before you actually use the ID for verification.

Let me know if I got any of this wrong @arihantverma52

@dan Also, depending on the workflow, if a user does NOT federate but does NOT check "trust this computer" they will NOT establish "MFA trust". Without trust, a user will be prompted to MFA again. Of couruse, With "MFA trust", they will not be prompted. This answer is implicit to this conversation, but MFA policies and FusionAuth center around this check box and trust (with the current edge case of Federation noted).

@mr-sahand said in Fusion auth single sign on issue:

I have two same enabled applications defined on fusionauth each representing a separate web application hosted on my local. I have also created two applications on an azure ad tenant and connect my fusion auth applications to them via two saml v2 identity provider I have created on fusionauth. I have created one user on AzureAD tenant and only added that user to one of the applications.
I can launch the web application which the azure ad user has access to and log into the application using it. Now when I try the other web application on the same browser what happens is it logs into the application without even going to a login page. What I am expecting is the second application to be rejected to log in as the azure ad user does not have access to it.
What do I need to acheive the desired behaviour?

I am having the same single sign on issue now. Did you find any solution?

FusionAuth has a bunch of import scripts, but one that you are probably most interested in is the CSV importer, which takes a CSV file and then calls the user import API.

Here's the link: https://github.com/FusionAuth/fusionauth-import-scripts/tree/main/csv

Of course, LDIF is not CSV.

Instead of using a CSV gem to get the list of users and their attributes, use a gem that can read LDIF. Here's a candidate. https://www.rubydoc.info/gems/ruby-ldap/0.9.19/LDAP%2FLDIF.parse_file but I'm not sure what the state of the art for ruby LDIF parsing is nowadays.

If you pursue this, please submit a PR to that repo because there may be other folks who want to import users from LDIF

An alternative would be to have them manipulate the LDIF file into CSV and import that using the csv importer. See https://www.google.com/search?client=firefox-b-1-d&q=ldif+to+csv for some examples on how to do the LDIF->CSV transformation.

Ensure that the source machine that is building your image is the correct architecture type.

https://www.reddit.com/r/kubernetes/comments/13lurdl/kubernetes_error_exec_usrlocalbinyarn_exec_format/?rdt=39252

For instance, if you are building a K8's cluster running linux (x86) but have built the image locally on a Apple M2 Mac (ARM based), then you will need to instruct docker to use the build x command to build a multi-platform build or change the source build machine.