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 @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.
Thank you for the quick reply.
By "Also start the authorization process there?" I mean manually open a new tab for my application and clicking on "Login" which redirects to "/oauth2/authorize". So the same login process initiated twice in different tabs, then introducing login credentials on the first one.
The debug doesn't shed any light I'm afraid. The problem seems to be the "saml.csrf" cookie changing it's value across tabs.
Hi!
We have a setup in which FusionAuth is acting as SAML Idp, using hosted login pages.
Now if I try to login to the connected application through the /samlv2/login url in browser, it redirects to /oauth2/authorize. So far so good.
But, If I keep this browser tab open (tab A), then open a new tab (tab B) and also start the authorization process there, the saml.csrf cookie is now changed for tab A, which I think is the reason why if you try to finish the authorization process in tab A, you get a "OAuth return is missing a valid CSRF token." error.
Is there a way to avoid this? Or is it a consecuence of the CSRF system?
Additional information:
@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?
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?
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.
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!