По умолчанию аутентификацию для учетных записей Google обрабатывает внешний сервис учетных записей Google. Когда неаутентифицированный пользователь посещает страницу Google , требующую аутентификации, форма входа в Google запрашивает адрес электронной почты и пароль пользователя. После того, как пользователь вводит свой адрес электронной почты и пароль, система аутентификации Google проверяет правильность введенных данных. Если данные верны, система аутентификации Google устанавливает файлы cookie для входа пользователя.
Некоторые предприятия используют более сложную модель, в которой аутентификацию обрабатывает сторонний поставщик идентификационных данных (IdP). Аутентификация Google поддерживает эту модель с помощью стандартного протокола Security Assertion Markup Language (SAML) . Администратор может настроить домен для использования аутентификации SAML.
Получение пароля пользователя
ChromeOS необходимо идентифицировать пароль пользователя, введенный при входе в систему:
- Зашифруйте данные пользователя, хранящиеся на жестком диске.
- Защитите экран блокировки.
- Включите автономный вход в систему при отсутствии доступа к сети.
При использовании SAML пароль вводится не непосредственно в диалоговом окне системы ChromeOS, а внутри веб-представления, размещенного у поставщика идентификации. Хотя ChromeOS имеет доступ к HTML-коду, простого и общепринятого способа получить пароль не существует, поскольку неясно, какие поля формы содержат эти данные.
При использовании SAML существует два способа получения пароля пользователя: API передачи учетных данных и сбор паролей.
API для передачи учетных данных Chrome
Google предоставляет API для передачи учетных данных , который поставщики идентификации могут реализовать на страницах SAML с помощью JavaScript для передачи необходимых данных в ChromeOS. Аутентификация Google использует этот API, но любой поставщик идентификации SAML также может его использовать.
извлечение паролей
Поставщик идентификационных данных SAML может использовать сбор паролей, если он не поддерживает API передачи учетных данных.
В этом методе:
- Экран аутентификации внедряет скрипт содержимого в веб-представление, которое содержит процесс авторизации.
- Скрипт содержимого идентифицирует HTML-поля ввода типа «пароль» и копирует их содержимое в массив. Массив обновляется всякий раз, когда изменяется содержимое поля ввода пароля.
- Собранные пароли отправляются на фоновую страницу, которая их накапливает. Таким образом, пароль может быть получен, даже если процесс авторизации включает несколько перенаправлений на разные HTML-страницы.
В конце процесса авторизации массив собранных паролей извлекается со страницы, отображающей фоновый процесс. Возможны три случая: ни один пароль не был собран, был собран ровно один пароль или было собрано более одного пароля.
Пароль не был скопирован.
Скрипт содержимого не может найти пароль на HTML-страницах, предоставляемых поставщиком идентификации. Поставщик идентификации может не использовать традиционные пароли.
В этом сценарии ChromeOS предложит пользователю выбрать пароль для устройства вручную . Если пароль отсутствует (например, аутентификация с помощью смарт-карт, NFC, биометрии), процесс аутентификации ChromeOS может продолжиться без пароля .
Был считан ровно один пароль.
В скрипте содержимого указан ровно один пароль. Скорее всего, это пароль пользователя, используемый для аутентификации.
В этом сценарии мы, скорее всего, правильно получили пароль пользователя. ChromeOS будет использовать полученный пароль в качестве пароля пользователя для продолжения процесса аутентификации .
Было скопировано более одного пароля.
Скрипт содержимого идентифицирует несколько паролей. Это может произойти, например, когда поставщик идентификационных данных требует от пользователя ввести постоянный пароль и одноразовый пароль в форму входа в систему.
В этом сценарии мы, вероятно, получили фактический пароль пользователя, а также некоторые дополнительные поля для ввода пароля, которые не представляют интереса для ChromeOS. Чтобы определить, какой из них является правильным паролем, ChromeOS предложит пользователю ввести пароль еще раз в дополнительном окне запроса пароля.
Если введенный пароль совпадает с одним из найденных паролей, значит, фактический пароль пользователя определен, и процесс аутентификации продолжится. Если совпадений нет, пользователю будет предложено ввести пароль повторно. После двух несовпадений вход в систему завершается с ошибкой.
Регистрация предприятия
Для корпоративной регистрации необходим адрес электронной почты регистрирующего пользователя, чтобы связать устройство с правильным доменом. Электронное письмо отправляется с сервера управления устройствами (DM) в Chrome в поле имени пользователя сообщения PolicyData во время получения политики устройства. Определять пароль пользователя не требуется.