我正在将我的应用程序与SAML2 IDP启动的单点login的MS Azure AD IDP进行集成。 我正在使用我公司的Office 365帐户和通过它访问的Azure AD服务。
在我的testing环境中，当我考虑一个巨大的时间戳“skew”时，整合效果很好。 现在，当进入prod时，我想解决“skew”问题，并在Azure AD生成的SAMLResponse的AuthnInstant时间戳和SAMLResponse获取的服务器的时间的时间差歪斜的合理的小默认值validation。
所以这里是一个例子。
我在CEST区，2017年9月4日，时间01:26。 从我的Office 365，我得到一个SAMLResponse以下IssueInstant
<samlp:Response Destination="..." IssueInstant="2017-09-03T23:23:49.338Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> （看起来是正确的，因为我比UTC快2小时，这是03.09.2017 23:23:29）和AuthnInstant：
<AuthnStatement AuthnInstant="2017-09-03T16:23:16.000Z" SessionIndex="_ad9dd439-9f99-4361-a8ae-497888a292a9">
我的应用程序运行的服务器有时间正确同步，因为它似乎：
[jboss@my-service-2373129067-knfwj ~]$ date Sun Sep 3 23:23:16 UTC 2017
（这是有道理的，因为我的CEST区域比UTC早2个小时）。
现在，从Azure公司获取古怪的AuthnInstant 2017-09-03T16:23:16.000Z ？ 我想，在加利福尼亚州的某个地方，这是PDT时区，大概是下午4点半左右。 但时间戳记说“Z”，这是UTC的零增量，因此我的SAMLResponsevalidation失败。
有没有办法configurationμOffice 365以正确指定AuthnInstant中的时区？
我已经看到这篇文章： https ： //support.microsoft.com/en-us/help/2718817/time-zone-settings-are-incorrect-or-missing-for-multiple-mailboxes-in
这看起来像一个错误，我有点担心与PowerShell控制台和我所有的公司用户搞乱。
我发现了这个问题。 Azure AD在这里工作正常。
AuthnInstant不是SAMLResponse生成的时间。 这是我上次loginOffice 365的时候。 这显然是9小时前，超过了“maxAuthenticationAge”SAMLvalidation设置（而不是我最初想的“responseSkew”）。
这一切都工作后，我重新login到Office 365。