Атрибут SameSite нарушает поток SAML - PullRequest
Новая
       142

Атрибут SameSite нарушает поток SAML

0 голосов
/ 05 февраля 2020

Chrome 80 представит новый атрибут SameSite.

  • Строгий - прикреплять куки только для запросов «одного сайта».
  • Lax - отправлять куки для ' запросы на тот же сайт, а также переходы между уровнями верхнего уровня с использованием безопасных методов HTTP, например (GET HEAD OPTIONS TRACE).
  • Нет - отправлять файлы cookie для всех сайтов с одним и тем же сайтом и между сайтами 'запросы.

Для получения дополнительной информации, эта статья объясняет SameSite довольно хорошо.

Из Azure документации:

Облачная служба (поставщик услуг) использует привязку HTTP Redirect для передачи элемента AuthnRequest (запрос аутентификации) в Azure AD (поставщик удостоверений). Azure AD затем использует HTTP-привязку публикации для публикации элемента Response в облачной службе

Мой вопрос: почему SameSite нарушает поток SAML? problem проблема "saml" на одном и том же сайте

Когда ответ IdP POST возвращается к SP, если SameSite = Lax, пользовательский агент не будет отправлять файлы cookie с доменом SP. Даже если он не отправляет куки, я не вижу проблем с SP.

Ответы [ 2 ]

0 голосов
/ 06 февраля 2020

При ответе IdP POST обратно на SP, если SameSite = Lax, пользовательский агент не будет отправлять файлы cookie с доменом SP. Даже если он не отправляет куки, я не вижу проблем с SP.

На IdP-init, скорее всего, не возникнет никаких проблем, потому что за пределами Ответ SAML, который отправляется. Однако

потоки SP-init, скорее всего, будут прерваны. Причина в том, что большинство продуктов SP отслеживают сеанс браузера с помощью параметра Cook ie, который он устанавливает перед отправкой пользователя в IdP. Браузер перенаправляется на IdP, аутентифицируется и отправляется обратно на SP с ответом на POST. Если для повара ie не было установлено SameSite=None;Secure (не забудьте, что для файлов cookie, для которых необходимо SameSite=None, также необходимо установить Secure), то повар SP ie не будет передан обратно для SP с POST, чтобы SP не имел всех частей, необходимых для безопасной настройки сеанса.

Один из способов взглянуть на это так, как если бы пользователю потребовалось два набора ключей для устанавливает sh безопасный сеанс в SP: во-первых, он хочет получить ключ сеанса от повара ie, а во-вторых, он хочет получить ключ от IdP.

0 голосов
/ 05 февраля 2020 
>> Even if it does not send cookies I don't see there is any problem with SP.

Если IdP cook ie неправильно настроен с SameSite = None, он не будет отправлен по запросу от SP в IdP, и пользователю будет предложено снова войти в IdP.

Источник: https://support.okta.com/help/s/article/FAQ-How-Chrome-80-Update-for-SameSite-by-default-Potentially-Impacts-Your-Okta-Environment

Вот что делает Shibboleth IDP: https://issues.shibboleth.net/jira/browse/IDP-1476

...