我正在将我的应用程序与 MS Azure AD IDP 集成,以实现 SAML2 IDP 发起的单点登录。我正在使用我公司的 Office 365 帐户和可通过该帐户访问的 Azure AD 服务。
在我的测试环境中,当我考虑到巨大的时间戳“偏差”时,集成工作得很好。现在,当进入生产环境时,我想解决“偏差”问题,并使用合理的小默认值来处理 Azure AD 生成的 SAMLResponse 的 AuthnInstant 时间戳中的时差偏差以及我的服务器验证 SAMLResponse 的时间。
这里有一个例子。
我位于 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 小时,即 2017 年 9 月 3 日 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 AD 在哪里获取奇怪的 AuthnInstant 2017-09-03T16:23:16.000Z
?我猜想,在加利福尼亚的某个地方,它是 PDT 时区,大约是下午 4 点半。但是时间戳显示“Z”,即与 UTC 的差值为零,因此我的 SAMLResponse 验证失败。
有没有办法配置 mu Office 365 以正确指定 AuthnInstant 中的时区?
这看起来像是一个错误,我有点害怕弄乱 PowerShell 控制台和我所有的公司用户。
答案1
我找到了问题所在。Azure AD 在这里运行良好。
AuthnInstant 不是生成 SAMLResponse 的时间。它是我上次登录 Office 365 的时间。那显然是 9 小时之前,并且超过了“maxAuthenticationAge”SAML 验证设置(而不是我最初认为的“responseSkew”)。
我重新登录 Office 365 后,一切恢复正常。
答案2
有没有办法配置 mu Office 365 以正确指定 AuthnInstant 中的时区?
此外,SAML 时间戳始终采用 UTC 格式。这是协议规范所要求的,因此您无法更改这一点。