I'm integrating my application with MS Azure AD IDP for SAML2 IDP-initiated single sign on.
I am using my company's Office 365 account and Azure AD service accessible through it.
In my test environment integration works well when I account for a huge timestamp "skew". Now when going into prod, I'd like to resolve the "skew" issue and work with reasonable small default values for the time difference skew in the AuthnInstant timestamp of the SAMLResponse that Azure AD generates and the time of my server where the SAMLResponse gets validated.
So here is an example.
I am in CEST zone, 4th September 2017, time 01:26.
From my Office 365, I get a SAMLResponse with the following IssueInstant
<samlp:Response Destination="..." IssueInstant="2017-09-03T23:23:49.338Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
(looks correct, since I am 2 hours ahead of UTC where it is 03.09.2017 23:23:29) and AuthnInstant:
<AuthnStatement AuthnInstant="2017-09-03T16:23:16.000Z" SessionIndex="_ad9dd439-9f99-4361-a8ae-497888a292a9">
The server where my app runs has time properly synchronized as it seems:
[jboss@my-service-2373129067-knfwj ~]$ date
Sun Sep 3 23:23:16 UTC 2017
(that makes sense since my CEST zone is 2 hours ahead of UTC).
Now where from the Azure AD takes the weird AuthnInstant 2017-09-03T16:23:16.000Z?
I imagine, that somewhere in California, it is PDT time zone and it is around half past 4 PM.
But the timestamp says "Z", that is zero delta to UTC, and thus my SAMLResponse verification fails.
Is there a way to configure mu Office 365 to specify the time zone in the AuthnInstant correctly?
I've seen this article:
https://support.microsoft.com/en-us/help/2718817/time-zone-settings-are-incorrect-or-missing-for-multiple-mailboxes-in
That looks like a bug and I'm a bit affraid of messing around with PowerShell console and all my company users altogether.
Best Answer
I have found the problem. The Azure AD works fine here.
The AuthnInstant is not the time when the SAMLResponse gets generated. It is a time when I had logged me in into my Office 365 last time. That was apparently 9 hours before and was exceeding "maxAuthenticationAge" SAML verification setting (instead of "responseSkew" as I thought initially).
It all worked after I re-logged in into Office 365.