next »

[Jos? V.]

I'm currently configuring SAMLServiceProvider for authentication with Azure AD Saml and I'm having a bit of trouble with timezones.

As far as I know(correct me if I'm wrong) Azure AD always comunicates using UTC timezone.
SAMLServiceProvider uses CURRENT operator which returns the system date/time in the current local timezone.
This is an issue when validating "NotBefore" and "NotOnOrAfter" assertions since our timezone is UTC+1.

To bypass this issue I tweeked SAMLServiceProvider's code to use *util.Datetime.toUTC(CURRENT)* which is always compatible with Azure AD.

My question is if there's any other way to solve this other than changing the 4gl code provided by 4js?

[Minora M.]

When working with SAML authentication and timezones, it's important to ensure that the timestamps in the SAML assertions are correctly handled to avoid issues with validation. If Azure AD always communicates using UTC timezone, you need to make sure that the timestamps in the SAML assertions are also in UTC.

[Jos? V.]

As a follow up to this post I came to the conclusion that our FGL version has a bug that is now reported and being solved by the 4js development team.

The bug is on the xml serialization of the timestamps with option xml_useutctime.
With xml_useutctime=TRUE the serialization should convert my timestamp to UTC when building the xml.
It works fine except if you are on GMT timezone, on this case it adds +1h instead of -1h.

The workaround to this is using *util.Datetime.toUTC(CURRENT)* instead of xml_useutctime=TRUE until this is solved on 4js BDL release.

[Jos? V.]

More Info:
Our version is 3.20.11.
Bug id is GWS-1285