Откуда Chrome берет мои идентификационные данные после удаления файлов cookie?

Откуда Chrome берет мои идентификационные данные после удаления файлов cookie?

Я пытаюсь выяснить, откуда Google Chrome извлекает мои идентификационные данные при аутентификации у поставщика удостоверений (SAML с аутентификацией на основе сертификата). Что я пробовал:

Удалить все файлы cookie, сохраненные пароли, файлы кэша

Удалить мой личный сертификат (тот, с помощью которого я прохожу аутентификацию) из моего личного хранилища)

В Firefox этого достаточно, чтобы IDP вышел из системы и снова запросил сертификат, если я обновлю страницу, но в Chrome он просто снова вводит меня в систему!

на chrome://password-manager-internals/ я вижу процесс загрузки пароля (я не знаю, какой именно, поскольку единственный введенный мной пароль был для расшифровки моего сертификата пользователя, который я удалил!):

Message: PasswordAutofillAgent::DidStartProvisionalLoad
PasswordManager::DidNavigateMainFrame: false
The new state of the UI: 0
Message: PasswordAutofillAgent::SendPasswordForms
only_visible: false
Security origin: https://ADFS-IDP/
Number of all forms: 1
Message: PasswordAutofillAgent::SendPasswordForms
only_visible: true
Security origin: https://ADFS-IDP/
Number of all forms: 1
Form found on page: {
    Action : https://ADFS-IDP/ ,
    Form name or ID :
}
Form is visible: false
Some control elements not associated to a form element are visible: false
Message: PasswordManager::CreatePendingLoginManagers
Message: PasswordManager::OnPasswordFormsRendered
Message: PasswordManager::IsAutomaticSavePromptAvailable
Message: No provisional save manager
HTML form for submit: {
    Action : https://ADFS-IDP/ ,
    Form name or ID :
}

Мой вопрос: откуда Chrome берет мою личность, а Firefox нет? Я предполагаю, что в Chrome много функций аутентификации на базе Windows, потому что то же самое происходит в браузере Edge. Есть идеи, пожалуйста?

решение1

Аутентификация SAML использует AD FS или другого поставщика удостоверений для SAML SSO, сам браузер никогда не является IdP. Действительно, Chrome имеет возможность брать токен сеанса Windows и передавать его поставщику услуг (SP). Сам SAML не использует сертификат в качестве удостоверения, но ваш сервер ADFS может. Если ваш ADFS настроен на несколько способов идентификации пользователя, он будет делать это даже без сертификата.

Примечание: проверка подлинности сертификата обычно используется ADFS только для внешней аутентификации пользователя, когда AD недоступен, а основным источником удостоверений по-прежнему является AD.

Для Azure AD с целью реализации единого входа используется специальная надстройка "Учетные записи Windows 10". В большинстве случаев многие компании используют гибридный режим идентификации, поэтому Azure AD использует аутентификацию пользователей в локальных ADFS.

Примечание: при удалении сертификата и уже прохождении аутентификации в ADFS ваш токен сеанса сохраняется в сеансе Windows.

Если вы запустите Chrome в приватном режиме, единый вход не произойдет, поскольку этот режим не имеет доступа к контексту сеанса Windows.

Чтобы глубже разобраться, как работает аутентификация SAML в Chrome, я рекомендую установитьДекодер сообщений SAMLплагин. Это даст вам представление о SAML Request и Response. В запросе вы должны проверитьsaml2p:AuthnRequestиsaml2:Эмитент. Я бы посмотрел наAssertionConsumerServiceURLиМесто назначенияв просьбе указать, откуда он исходит.

Также вам необходимо проверитьsamlp:ОтветИ егоЭмитент. По значению эмитента вы поймете, что ответил IdP и вПредметсеанса полезной нагрузки вы увидите, как был идентифицирован пользователь. SAML-запрос Ответ SAML

Связанный контент