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 !

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.

It sounds like you're experiencing some confusion with the authentication setup in your FusionAuth application. When using traditional email + password authentication alongside Google login, you're expecting to see distinct information in the user session to differentiate between the two authentication methods.

In the context of your Express.js application, the req.session.user object should ideally provide some form of identity provider identification to distinguish between users authenticated via traditional email + password versus Google login. However, it appears that you're not seeing this distinction reflected in the session information.

This behavior could be due to how FusionAuth handles user authentication and session management. It's possible that FusionAuth is not explicitly adding information about the identity provider to the user session, leading to ambiguity when accessing the session data in your Express.js application.

To address this issue, you may need to customize your FusionAuth setup or modify your Express.js application logic to explicitly capture and store information about the identity provider used during authentication. This could involve updating your authentication middleware or incorporating additional FusionAuth API calls to retrieve and store identity provider information alongside user session data.

In summary, while the lack of distinction between authentication methods in the user session may not be the expected behavior, it's likely a result of how FusionAuth is configured or how session information is managed in your application. By exploring customization options and making adjustments to your application logic, you should be able to achieve the desired differentiation between traditional email + password and Google login authentication methods.

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