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

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.

@vatsal We did not

Hello there,
I feels like you are encountering some complex issues with running FusionAuth in Azure Container Apps and using KrakenD as a proxy.

For the Proxy Configuration Warning, be ensure that your FusionAuth instance is aware of the correct external URL and headers. You might need to set the FUSIONAUTH_URL environment variable appropriately.

Releated KrakenD, you could configure it to correctly handle the necessary headers for FusionAuth. Be sure your KrakenD configuration includes the necessary routes and headers for FusionAuth's admin and OAuth endpoints.

Consider checking the FusionAuth and KrakenD documentation for any specific configurations needed for Azure environments.

If the issue still did not get solved, you might want to reach out to FusionAuth support directly for more tailored assistance.

Hope it helps.

@tony-blank yes please help me.

Wonderful blog post. I found it very helpful and informative. Solar

Any news?

@egg said in Maximum lifetime of refresh token not honored? (sliding window configuration):

I am configuring my Tenant with a refresh token expiration policy of "sliding window with maximum lifetime". I have configured the maximum lifetime to 240 minutes, but the refresh token is actually expiring after 30 minutes.

The "sliding window with maximum lifetime" policy should allow the refresh token to remain valid as long as it's used within the configured lifetime, which in your case is set to 240 minutes.

@zaalbarxx sorry for the delay. I might be missing it (sorry not a PHP person) but I don't see where that confusion comes into play. I know that some of our docs had to get updated because of a change that we made during our 1.50 release that required to request further details in our scopes request.

This release makes significant changes to the default behavior of new Applications with regard to scopes in OAuth workflows. The database migration will update existing Applications to behave in a backwards compatible manner. See the OAuth Scopes documentation for more information, in particular the Relationship, Unknown scope policy, and Scope handling policy configurations.

https://fusionauth.io/docs/release-notes/#version-1-50-0

Let me know if that still isn't making sense, or if there is a spot you were hung up on and I would be happy to update our docs. Or even better feel free to add a PR.