This issue was resolved and released as part of 1.24.0.

More here: https://fusionauth.io/docs/v1/tech/release-notes/#version-1-24-0

@didier-rano

It looks like there are two issues.

The first is that the SAML login lambda runs after the JWT populate lambda (or at the least the order is indeterminate) so your groups aren't being propagated, at least for Azure AD. More concerning to me is the fact that you are only seeing one SAML reconciliation for your user. I would expect that lambda to run every time the user logs in.

These feel like issues to raise on our issues repo, preferably with reproduction steps. I have been trying to find time to replicate it and file the issue, but if you can, that'd be very helpful.

The second is whether we support Enterprise Applications. I don't know if any of the community is using that particular feature. That does make sense why you are not interested in OIDC, however. Do you have a link for the Azure docs on this so I could learn more (I googled for them, but wasn't able to find anything relevant).

Hi @tl-fa,

You can view our Roadmap Guidance regarding how features are implemented into FusionAuth. A good snapshot of current development can be found here as well.

We will certainly update any related issue cards as development moves forward!

Thanks!
Josh

Thanks @joshua !

@owork138 Thank you so much for the detailed and thoughtful explanation. Your insights have helped clarify the likely cause of the confusion with the authentication setup in our FusionAuth application. Understanding that the lack of distinction in the session data may stem from FusionAuth’s default handling—and that customization in our Express.js logic might be required—gives us a clear direction to move forward.

We truly appreciate the time and effort you put into outlining potential solutions. We'll be reviewing our current middleware and exploring the recommended approach to better capture identity provider information during authentication.

Thanks again for your support!

Well, I'd just call the 'create registration' API from the server three times after a user had successfully registered on your custom page: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-registration-for-an-existing-user

Does that make sense, or do I misunderstand your question?

Just wanted to update. A user opened: https://github.com/FusionAuth/fusionauth-dart-client/issues/7

To clear things up, with a public client like a mobile application, you can't safely store a client secret (it'll be shared among all the native apps and can be found via decompilation).

In this scenario, you should disable Require authentication in the FusionAuth Application configuration and use PKCE to secure communication with the Token endpoint.

You can use the exchangeOAuthCodeForAccessTokenUsingPKCE client method to do so.

This is also outlined here: https://fusionauth.io/docs/v1/tech/client-libraries/dart/

Ah, that's great! I've definitely made my share of mistakes, no worries!

I am not using elastic search. But I thank you for your help, but I am getting to it a different way. I have stuffed the use's email into the "state" variable and then on the app side I am using that as an index. So while it is not the most "pretty" solution, I think it might work.

The reason you got this error is because you forgot to register your java mysql jdbc driver with the application.

Should be like this:

Class.forName("com.mysql.jdbc.Driver");

This forces the driver to register itself, so that Java knows how to handle those database connection strings.

You'll have to read the manual on your specific mysql jdbc driver to find the exact string to place inside the the Class.forName("...") parameter.

@vexana succeeded, but had another question, so I forked the topic: https://fusionauth.io/community/forum/topic/811/mapping-fusionauth-roles-to-elasticsearch

Since the original post is from two years ago, it's important to consider that the technology landscape and integration options may have evolved since then.

@mark-robustelli

right on. I will use that next time.

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

As of July 25, 2023 we now support Unlimited Custom Domains for FusionAuth Cloud! You can read more in this post, on how to add a custom domain.

If you get an unauthorized message in the UI when you submit a form it is due to your network configuration. This error is caused by our protective measures for cross site request forgery.

I would assume you are seeing an error on the admin page to indicate your proxy configuration is invalid. If not, ensure you have the correct X-Forwarded-Port, X-Forwarded-Host, X-Forwarded-Proto headers set when behind a proxy.

If these values are not set, or are invalid then when we compare the Origin header against the request we will fail our CSRF assertions and return a 401.

Sounds like @viola-mauro you've got this all working.

For anyone else that may be interested, we do have an apache module, that seems to be similar to what you're trying to do.

https://github.com/FusionAuth/fusionauth-mod-authnz-external

In the meantime we could implemented it with the mentioned workaround.
Late thanks @robotdan !

Thanks @richb201 , appreciate the UI suggestions! I'll take a look as we definitely don't want folks to be confused/frustrated by the user interface.

Cheers,
Dan

@mehamm

I am working on a multi tenant guide. Thank you very much for your feedback; I'll make sure to include it.

As you continue to build out your multi tenant application, please continue to post on the forum about your progress and/or any other questions. 🙂

We often hear our multi tenant support is a differentiator for FusionAuth, and would love to make it easy/clearer for everyone.