Posts made by joseantonio

@mark-robustelli Thanks! That prevents the error but adds the code to the url, which in my case is not needed, so I'm using response_mode=form_post to hide it. Is that ok?

@mark-robustelli

This is the error shown in the url after oauth2/authorize redirects to redirect_uri:

?error=invalid_request&error_reason=missing_response_type&error_description=The+request+is+missing+a+required+parameter%3A+response_type

At some point I used a combination of these two params in the oauth2/authorize endpoint to prevent it, is this safe to do or may it come with possible drawbacks?

• response_type=code
• response_mode=form_post

Thanks!

I'm glad it's finally possible to bootstrap an SSO session manually as described here, nice!

However, as part of the explanation on how to actually achieve it, there's a step that's not explained in detail, which is:

"FusionAuth requires the access token to be in an Authorization header. Because browsers do not provide a way to set the Authorization header when browsing to a location, you’ll need to add the header using, for example, a reverse proxy.""

I managed to make it work using nginx as the reverse proxy, I've published a gist to show how.
Is this approach correct?

The only thing that seems off is that after redirecting to oauth2/authorize, FusionAuth redirects to the redirect_uri provided, but includes an error about the response_type in the url (SSO session is correctly created though).

Hi,

I want to do something like in this post: MagicLink + Google IDP, creating a custom login page for one of my applications, that will have a "Login with Google" button.

However, there are two more applications that are using the FusionAuth built in page, so I don't know how this would work.

Once I complete the login using this: https://fusionauth.io/docs/apis/identity-providers/google#complete-the-propsidp_display_name-login:

Will the user need to authenticate again in other applications that use hosted FusionAuth page? Or will the sso session persist somehow?

All the applications share the same parent domain.

Hi @dan !

I'm sorry, the only thing I can say is that setting

fusionauth-search.additional-java-args="-Duser.timezone=UTC"

solved the issue for me.

If that's already solved, I guess it can be closed.

Thanks @dan and @robotdan for reviewing issues!

Hi again!

For the record, I just found the solution.

Fusionauth config is taken from JVM variables, as explained here. These can be chaged with the fusionauth-search.additional-java-args property, specified in the fusionauth.properties file like so:

fusionauth-search.additional-java-args="-Duser.timezone=UTC".

Then everything is working and compliant with SAMLv2 timestamps. Hope this helps someone else some day.

Hi!

Situation:
Few months ago my I set up a FA installation hosted in FA servers. Then I set a SAMLv2 IDP configuration, and in the end ran perfect.

Now I set the same configuration for the same IDP in a FA installation (1.27.2) hosted in our servers.

However, this configuration does not work correctly this time. I have contacted the IDP manager, and he said that the timestamp in the AuthNRequest is invalid. So, I checked the server and database timezone configurations, and set everything to UTC, as SAMLv2 demands, and then rebooted everything. No effect from this.

Then I realized that the event logs in the FA server shows a different time (UTC) from ours (CEST).

FA hosted server:

Our server:

Do you have any ideas on how I can change or set that timezone? Since I think this is the reason why the SAML conection is not working.

Thank you!

Hi @joshua,

Just to let you know, in the end I installed FA in a new VPS, and pointed a new subdomain to it so everything is now on the same domain, and it's working fine inside the iframe!

Thank you so much for your support! Helped a lot!

Jose

@joshua

Indeed, custom URL/domain is the only feature we really need from HA.

In this case, would it be possible to do a "partial upgrade", meaning paying more just for this feature? Otherwise I think we should give self hosting a try.

Just to be sure, the CloudFlare option would involve implementing that "coordination" on both apps aswell?

Thank you again for the great support!

Jose

Hi @joshua,

Many thanks for the information. Indeed that is exactly the use case.

Since our current Cloud plan is not High-Availability, the current structure is:

FusionAuth deployment.fusionauth.io
App A -> a.mydomain.com
App B -> b.mydomain.com

Do you think it's necessary to upgrade the current Cloud plan to fit the structure you mentioned?

The Cloudflare option might be good, but I'm not sure which kind of cookie would I need to set for making it work. Any guidance about this?

Thank you!

Thank you @joshua,

Alright then, I've tried using incognito mode aswell. Also checked everything is HTTPS -> HTTPS.

I'll wait for the cookie settings news.

Hi @joshua,

Yeah, it's pretty much the same issue Netflix faces. However, in this case 2FA would be too annoying for our users, and doesn't make enough sense I think.

Indeed WAF is a good idea, I've been looking at some solutions like AWS WAF, but seems pretty complex at first.

The ideal solution would be FA being able to handle this. I imagine it would store the device fingerprint (using fingerprint.js for example) in the user data / registration data, and then check the count against a limit set in the tenant/application settings on every login. Is this something FA can develop as a paid request?

Another solution would be allowing Lambdas to import external js libraries, or even make API calls would do the trick. Then anyone could implement the limitation by their own.

Let me know our thoughts about any of this options and/or new ideas!

And thank you for the amazing support job!

Hi @joshua,

Thank you for the new info!

I thought those settings were not possible in the cloud version. Am I wrong?

Being able to apply that configuration in the cloud version might be the solution, hope it can be done!

For the apps part, I have tested in a simple local apache server aswell, just a static html page with the iframe and I got the same result.

Thank you so much!

Hello @joshua, thank you for the information!

It actually happens in every browser i've tested in (Chrome, Edge and Firefox, and IE).

I checked the samesite attribute and every other configuration for cookies, as well as for iframes.

What I have tried so far:

• Setting samesite attribute to None and secure to true (applied to all FusionAuth cookies created from my site).
• Adding sandox attribute to iframe object like sandbox="allow-same-origin allow-scripts"

Also, I have noticed that the FA login page sets its own cookie "fusionauth.sso" with samesite Lax. Our login is hosted in FA.

SSO still works in a new tab.

Hope this information helps.

Thank you!

Jose.

Hi @joshua, thank you for the quick reply!

Indeed, the idea is to limit the number of different devices an account can login from, so account credentials sharing isn't allowed.

For example, if the limit is 2, a user could authenticate from his/her Phone1 and Desktop2, but won't be able to authenticate from any new device (Phone, Desktop, etc.).

On the other hand, if you think there is already another way to prevent account sharing, that could be another solution too.

Thank you in advance!

Jose.

We currently have two apps in different domains, A and B.

A is a Wordpress website, and in one of its pages, there is an iframe with src to app B.

When a user is authenticated in A, and goes to the iframe page, it is required to authenticate again for B inside the iframe.

However, if I open another browser tab and go to app B, SSO works and it automatically authenticates. The strange thing is, if I now come back to the iframe page in A and reload, it is automatically authenticated inside the iframe aswell.

Any ideas what this could be?

Cookie problem maybe?

Thank you!

I thought using fingerprint.js to track the devices and store it in the registration on each login, but since external libraries can't be imported into lambdas (right?), I can't imagine another solution from the FusionAuth part.

I know it could be possible to implement in the app side, but I have no access to that code because it's an external service provider.

@dan Thank you for the help. Indeed it is not possible to assign a generated email in SAML reconcile lambdas. However, I found a solution for my problem.

Using SAML reconcile lambda, I create a new metadata field for the registration called "generated_email". Then, I assign it to the JWT response for the specific application using a JWT populate lambda. Example:
Edit: adding code for SAML reconcile lambda as well.

SAML reconcile:

function reconcile(user, registration, samlResponse) {
var userid=samlResponse.assertion.subject.nameID.id;
//registration.email = userid + '@subdomain.mydomain.com'; This can't be done yet
registration.data.generated_email=userid + '@subdomain.mydomain.com';
}

JWT populate:

function populate(jwt, user, registration) {
if(registration.data&&registration.data.generated_email){
    var new_email= registration.data.generated_email;
    jwt.email= new_email;
  }else{
    console.debug('No generated email set');
  }
}

(after checking that it exists for the registration).

New problem: I need to make an API call inside the SAML reconcile. Is this possible?

@robotdan Is the workaround for no email Identity Providers available in SAML as well?