Я интегрирую свое приложение с MS Azure AD IDP для единого входа, инициированного SAML2 IDP. Я использую учетную запись Office 365 моей компании и доступную через нее службу Azure AD.
В моей тестовой среде интеграция работает хорошо, когда я учитываю огромный «перекос» временных меток. Теперь при переходе к продукту я хотел бы решить проблему «перекоса» и работать с разумными небольшими значениями по умолчанию для перекоса разницы во времени в метке времени AuthnInstant SAMLResponse, который генерирует Azure AD, и времени моего сервера, на котором появляется ответ SAMLResponse. подтверждено.
Вот пример.
Я в зоне CEST, 4 сентября 2017 года, время 01:26. В моем Office 365 я получаю ответ SAML со следующим IssueInstant
<samlp:Response Destination="..." IssueInstant="2017-09-03T23:23:49.338Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
(выглядит правильно, так как я на 2 часа опережаю UTC, где это 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 на 2 часа опережает UTC).
Теперь откуда из Azure AD берется странный AuthnInstant 2017-09-03T16:23:16.000Z? Я полагаю, что где-то в Калифорнии это часовой пояс PDT, а сейчас около половины пятого. Но на отметке времени указано «Z», что означает нулевую дельту относительно UTC, и поэтому моя проверка SAMLResponse не выполняется.
Есть ли способ настроить mu 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. Это время, когда я последний раз входил в свой Office 365. Очевидно, это было 9 часов назад и превышало значение параметра проверки SAML «maxAuthenticationAge» (вместо «responseSkew», как я думал изначально).
Все заработало после того, как я повторно вошел в Office 365.