Posts made by mark.robustelli

@ahcfrontdoor I set up an application with the setting you are talking about and was allowed to register and proceed without any re-direction. Can you share a screen shot of your application registration tab. Please be sure to black out any sensitive information if necessary.

@dan Great catch, no sure how I confused mfa and captcha. Thank you!

@muditshukla3 you can. Please check out this blog. https://fusionauth.io/blog/announcing-fusionauth-1-37#configure-mfa-requirements-for-an-application

@morten Check out this thread and please let me know if it works for you. https://fusionauth.io/community/forum/topic/2743/can-i-configure-a-tenant-application-as-an-external-identity-provider-for-other-tenants/8

@sandiprghane based on that info, I think the above method will work for you and as I mentioned, maybe check out custom scopes for third party applications if you have a license that supports it.

@rrock Does this have to be during the registration process? I found this under progressive registration in the docs. It suggests you "collect minimal user profile data to get users into your application with as little friction as possible. Then, you’d use the User APIs or User Registration APIs along with custom screens in your application to collect additional information."

@sandiprghane , For some reason, I have still been thinking about this question. We didn't get too much into the "why" you want this setup and if it works for you...that is great. I just want to throw something else out there for consideration.

While this is a premium feature, you may think about custom scopes for third party applications. FusionAuth has a blog post that describes this.

@mark-robustelli OK, this question became a brain bug and I could not let it go. I think I got it to work the way you want but it may be a little confusing. Here is what I did.

I have a couple of tenants; Default; Tenant 1, Tenant 2 (We can ignore Tenant 2) not used here.

I have a couple of users: Again, ignore test@example.com user in Tenant 2. Just note that test@example.com does not exist for the Default tenant.

I use the .Net Web Quickstart application as my test app.

I set up a Test Base Application for Login application. I now have 3 applications: FusionAuth(Default), ExampleDotNetApp (from quickstart), and the Test Base Application for Login (this will be the source of auth app)

(note that the ExampleDotNetApp belongs to a different tenant the the Test Base Application for Login application.)

I then set up an new OpenID Connect identity provider: "TestBaseApplication"

I set it up using info the Test Base Application. Then I enabled it in the ExampleDotNetApp and selected Create Registration.

Now, when I go to login to the Change Bank Quickstart I see the Login with Test Base Application button. (The text is cut off in the image because it is too long, but you get the idea)

When I click that button and login with the test@example.com user, it allows me in. When I go back to users, you can see the test@example.com user was added to the ExampleDotNetApp.

Now please be aware that the test@example.com user for the Default tenant is technically different than the test@example.com user for Tenant 1. They will have different User Ids. However now user test@example.com in Tenant 1 can log into the application in the default tenant.

For here you should be able to use the APIs to update whatever data you need.

Hope this helps.

@sandiprghane So you can create users with the same user info in different tenants:

However, they will ultimately be different users.

As far as a FusionAuth tenant using another FusionAuth tenant for and IdP, that is an interesting question. I should get some time next week to look into that. I will let you know what I find.

@damien, That is not the case, you can use WebAuthn with the licensed starter version as well. I did take a look at the website and sure enough, it looks like it may be out of date and indicates otherwise. Thanks for reaching out and making us aware. We will get it updated.

@sandiprghane For the "centralized authentication", are using FusionAuth or another IdP?

If so I think this could be done validating the user against the external Idp, then when you get that users info, you can use the APIs to add them.

@kiouplidis I found this in the documentation.

In version 1.50.0 and later, the UserInfo response can be customized with a lambda using the oauthConfiguration.userinfoPopulateLambda value of the application object. See UserInfo populate lambda.

In FusionAuth, you can add custom data to the oauth2/userinfo endpoint response using a Lambda function. This function can add extra claims to the UserInfo response. Here's an example of a simple Lambda function that adds a few extra claims:

function populate(userInfo, user, registration, jwt) {
  // Add a new claim named 'favoriteColor' from a custom data attribute on the user
  userInfo.favoriteColor = user.data.favoriteColor;
  // Add a new claim named 'dept' using a custom data attribute on the registration
  userInfo.dept = registration.data.departmentName;
  // Copy a claim named 'applicationId' from the provided JWT
  userInfo.applicationId = jwt.applicationId;
  // Create an event log of type 'Debug' when the lambda has Debug enabled
  console.debug('Added custom claims to the UserInfo response');
}

In this example, the favoriteColor and dept are custom claims added to the UserInfo response. These claims are derived from the custom data attributes on the user and registration respectively.
Please note that the Lambda function needs to be assigned to an application in FusionAuth for it to take effect.

@rrock Can you tell us a little more about what you mean by conditional data? You should be allowed to have non required fields.

So are you saying you can no longer access Tenant -> Advanced -> SMTP Settings -> Additional properties?

@tkates

In the SAML protocol, the Identity Provider (IdP) typically sends the SAML assertion to the Service Provider (SP) via an HTTP POST binding. This is because the SAML response data can be quite large and may exceed the maximum URL length if sent via GET.
FusionAuth, when acting as a SAML IdP, follows this standard practice and sends the SAML assertion to the SP via POST. Currently, there is no configuration option in FusionAuth to change this behavior to use a GET binding instead.
For more details on how FusionAuth handles SAML, you can refer to the FusionAuth SAML documentation.

Can you tell us why you need it as a GET?

@thiago-gabriell Are you sure you still have elastic search enabled?

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

@elliotdickison Check out these posts:

179 and 2485