Рубрики
Uncategorized

Анализ веб-входа (простой вход и единый вход)

Автор оригинала: David Wong.

Процесс входа в систему

Во-первых, давайте проанализируем, как реализован простой вход в систему.

  1. Простой процесс входа в систему

    • Пользователь вводит URL-адрес для посещения сайта, принимает запрос пользователя и решает, вошел ли пользователь в систему, или переходит на страницу входа, если он не вошел.
    • Пользователь заходит на страницу входа, заполняет и отправляет форму входа
    • Веб-приложение проверяет форму входа в систему, возвращает информацию об ошибке пользователю, если проверка не удалась, и если проверка прошла успешно, Введите информацию, связанную с пользователем (обычно идентификатор пользователя и т. Д.), В текущий сеанс Идентификатор сеанса может быть отправлен пользователю в виде файла cookie (и идентификационная информация в сеансе может быть отправлена пользователю в виде файла cookie, что необязательно. Файл cookie может быть использован для автоматического входа в систему, как показано на диаграмме анализа входа ниже).
    • После входа пользователя в систему файл cookie, содержащий идентификатор сеанса, полученный пользователем, будет передан веб-приложению при последующих посещениях. Если веб-приложение сможет получить соответствующую идентификационную информацию из сеанса в соответствии с идентификатором сеанса (или даже дополнительно найти соответствующие пользовательские данные из базы данных), оно успешно войдет в систему от имени пользователя.

  2. Выход из системы Выход из системы в основном включает в себя следующие два процесса

    • Уничтожить информацию о сеансе (уничтожить на сервере)
    • Уничтожьте файлы cookie клиента (файлы cookie с идентификатором сеанса)

автоматический вход в систему

Вообще говоря, сеансы на стороне сервера будут иметь определенное время истечения срока действия. Аналогичным образом, файлы cookie с идентификатором сеанса на стороне клиента также будут иметь срок действия. Если пользователь не делал запрос на доступ в течение длительного времени после входа в систему, то при повторном посещении пользователем сеанса сервера или файла cookie клиента может быть недействительным, что заставляет сервер судить о том, что пользователь “не вошел в систему”, но на самом деле пользователь не вышел из системы. Эта проблема может быть решена путем реализации “автоматического входа в систему”, то есть при сбое сеанса он может быть автоматически снова зарегистрирован.

Основная идея автоматического входа в систему:

  1. После входа пользователя в систему в дополнение к созданию файла cookie, соответствующего идентификатору сеанса, создается файл cookie, содержащий идентификационную информацию пользователя (при условии, что ключом файла cookie является идентификатор). Идентификационные файлы cookie содержат такую информацию, как идентификатор пользователя, Ключ авторизации пользователя (это более важно, функции ключей аутентификации несколько похожи на пароль, продолжительность действия файлов cookie и т.д.). Для достижения цели автоматического входа в систему срок действия файла cookie обычно устанавливается на очень долгое время (возможно, на неделю или даже на месяц).
  2. Когда сеанс пользователя завершается неудачно, пользователь снова обращается к веб-приложению, принося идентификационный файл cookie (поскольку у файла cookie более длительный срок службы). Веб-приложение сначала определяет, что пользователь “не вошел в систему” (из-за сбоя сеанса).
  3. Веб – приложения пытаются автоматически входить в систему для пользователей с помощью файлов cookie, удостоверяющих личность. Приложение получает “идентификатор пользователя” и “ключ авторизации пользователя” из файла cookie идентификации и проверяет действительность “ключа авторизации пользователя” путем сравнения с данными в базе данных.
  4. После подтверждения подлинности с помощью ключа аутентификации веб-приложение создает новый сеанс для пользователя и отправляет новый идентификатор сеанса пользователю в файле cookie. (то есть успешный вход пользователя в систему отмечен получением файла cookie, содержащего идентификатор сеанса)

Пример анализа (yii 1.1 и Yii 2)

  1. Анализ собственного входа в Yii 1.1

    Ссылка на облачный диск Baidu для загрузки оригинальных файлов и изображений

  2. Анализ собственного логина yii2

    Ссылка на облачный диск Baidu для загрузки оригинальных файлов и изображений

Резюме

  1. Cookie, сеанс-это основа входа в систему
  2. Цепочка корреспонденции: cookie клиента (содержит идентификатор сеанса ) –> идентификатор сеанса соответствует стороне сервера сессии (Содержит идентификационную информацию пользователя, такую как идентификатор ) – > На основе информации в сеансе вы можете перейти дальше из базы данных Получить сведения о пользователе (даже их соответствующие разрешения)

Что такое единый вход?

Единый вход (SSO) также переводится как единая регистрация, которая обеспечивает атрибуты контроля доступа для многих взаимосвязанных, но независимых программных систем. В среде с этим атрибутом, когда пользователь входит в систему, он может получить доступ ко всем системам без необходимости входить в каждую отдельную систему по очереди. Эта функция обычно реализуется протоколом доступа к каталогу Light (LDAP), который хранит информацию о пользователях в базе данных LDAP на сервере. Аналогичным образом, единый выход означает, что доступ к нескольким системам может быть прекращен одним действием по выходу. (то есть Во многих приложениях пользователям нужно только один раз войти в систему, чтобы получить доступ ко всем доверенным приложениям; пользователям нужно только один раз выйти из системы, чтобы выйти из всех приложений. )

Преимущества единого входа в систему

  • Уменьшите риск доступа к сторонним веб-сайтам (пароли пользователей не хранятся и не управляются извне).
  • Пользователям не нужно использовать разные имена пользователей и пароли на разных сайтах, чтобы уменьшить утомляемость паролем.
  • Сократите время, затрачиваемое на повторный ввод паролей для аутентификации при использовании разных сайтов.
  • Сократите затраты на ИТ.

Основные идеи единого входа в Интернет

  1. Когда пользователь впервые обращается к прикладной системе 1, поскольку он не вошел в систему, он будет направлен в систему аутентификации для входа в систему (1)
  2. В соответствии с информацией для входа, предоставленной пользователем, система аутентификации проверяет личность, и если она проходит проверку, она возвращает ее пользователю. Билет с удостоверением личности (2)
  3. Пользователи повторно получают доступ к прикладной системе 1, Это приведет к тому, что билет будет у вас с собой. 。 Когда прикладная система 1 получает запрос, она отправляет билет в систему аутентификации для проверки действительности билета.( Вошел в систему от имени пользователя Пользователь может получить доступ к прикладной системе 1
  4. Когда пользователи посещают другие приложения (3,5), они берут билет с собой в качестве учетных данных для аутентификации. После получения запроса система подачи заявок отправит билет в систему аутентификации для проверки и проверки действительности билета (4,6). Если это подтверждено, пользователи могут получить доступ к прикладной системе 2 и прикладной системе 3 без необходимости повторного входа в систему.

Заключение: билет Это ядро всей системы. билет Он будет передаваться при взаимодействии пользователей, прикладных систем и систем аутентификации и в конечном итоге достигнет цели единого входа. билет Это единый знак аутентификации для пользователей во всех системах.

Проблемы, возникающие при едином входе в систему

Q1: Что такое билет? Из чего она состоит? Как упоминалось ранее, билет является единым знаком аутентификации для пользователей во всех системах. В конкретной реализации мы можем использовать файлы cookie для реализации функции тикета. Просто файл cookie с идентификатором сеанса можно считать билетом. В последующем анализе конкретной реализации у нас будет более глубокое понимание ticket. По соображениям безопасности билеты обычно шифруются. Для того чтобы реализовать функцию единого входа и разрешить пользователям входить в систему только один раз, необходимо разрешить прикладной системе идентифицировать пользователей, которые вошли в систему. Система подачи заявок должна уметь идентифицировать и извлекать билеты. Посредством связи с системой аутентификации он может автоматически определить, вошел ли текущий пользователь в систему, выполнив таким образом функцию единого входа.

Q2: Каковы категории внедрения технологии единого входа? С точки зрения технической реализации единый вход может быть разделен на Единый вход между поддоменами и Полный единый вход между доменами

Q3: Что такое? Кросс-поддоменный единый вход ? В чем заключается конкретная идея ее реализации? Кросс-поддоменный единый вход То есть для достижения единого входа между сайтами с одним и тем же корневым доменным именем. Например, существуют следующие сайты a.example.com, b.example.com, p.example.com (центр сертификации), все из которых имеют общее корневое доменное имя “example.com”. При записи файлов cookie в режиме единого входа установите домен файлов cookie в качестве их общего родительского домена (example.com), так что один и тот же файл cookie (билет) может использоваться в разных поддоменах, и в то же время несколько систем могут обмениваться информацией о сеансе.

Q4: Что такое? Полный междоменный единый вход ? В чем заключается конкретная идея ее реализации? Полный междоменный единый вход То есть единый вход реализован между сайтами с разными корневыми доменными именами. Идеи для реализации: каждому сайту нужен свой собственный билет (A-tikcet, B-билет, P-билет); при доступе к системе приложений (A, B), если соответствующий билет отсутствует, он автоматически перенаправляется в систему аутентификации (P), после того, как система аутентификации получила P-билет, он перенаправляется в систему приложений (A или B), обменивает P-tikcet на соответствующий A-билет или B-билет; при отмене он должен отменить место. Некоторые билеты (P-билет, A-билет, B-билет)

Q5: Каковы ограничения на совместное использование файлов cookie в Q3? Во-первых, доменное имя группы приложений должно быть унифицировано; во-вторых, технология, используемая системами группы приложений (по крайней мере, веб-серверами), должна быть одинаковой, в противном случае ключевое значение файла cookie (tomcat-JSESSIONID, PHP-PHPSESSID) отличается, и сеанс не может поддерживаться. Способ совместного использования файлов cookie не может обеспечить вход в кросс-языковую технологическую платформу, например, между java, PHP и. сетевые системы; в-третьих, сам файл cookie небезопасен. 。

Единый вход в перекрестный поддомен

Реализация междоменного единого входа в систему относительно проста и может быть реализована на основе файлов cookie. Основная идея заключается в следующем:

  1. Предварительное условие: Доменные имена каждого сайта в группе приложений должны быть унифицированы, то есть одно и то же корневое доменное имя; технология, используемая группой приложений, должна быть одинаковой, чтобы можно было поддерживать обратный вызов (например, ключевое значение cookie в Tomcat-JSESSIONID, в то время как в стеке технологий PHP-PHPSESSID).
  2. На основе “основной идеи единого входа в Интернет”, упомянутой выше, билет реализован в виде идентификатора сеанса в файле cookie, и шаги проверки билета, применяемые в центре аутентификации, могут быть опущены.

Подробные иллюстрации приведены ниже:

1. Когда пользователь обращается к системе 1 (доменное имя a.example.com), система обнаруживает, что в запросе пользователя нет билета (то есть нет соответствующего файла cookie), затем решает, что пользователь не вошел в систему, и перенаправляет пользователя в центр аутентификации (с URL-адресом системы 1 центр аутентификации может перенаправить пользователя в конференц-систему 1 после завершения аутентификации).

2. Пользователь отправляет форму входа в центр аутентификации и создает соответствующий сеанс после проверки. Идентификатор сеанса отправляется пользователю в виде билета с помощью файла cookie, и пользователь перенаправляется в систему 1. (обратите внимание, что Домен cookie является корневым доменом “example.com” )

3. Пользователи перенаправляются в Систему 1 (с соответствующим файлом cookie в качестве билета). Когда система 1 обнаруживает билет, она отправляет запрос в центр аутентификации для проверки действительности билета.

4. Центр сертификации проверяет действительность билета (то есть проводится соответствующая сессия) и возвращает результаты в систему 1.

5. Система 1 может считать пользователя “вошедшим в систему” после получения результата успешной проверки из центра аутентификации.

6. Пользователи продолжают посещать Систему 2 (поскольку доменное имя системы 2 “b.example.com” и его корневое доменное имя также “example.com”, соответствующий файл cookie будет доставлен в качестве билета в это время). Система 2 обнаруживает билет, затем запрашивает центр аутентификации для проверки действительности билета.

7. Центр аутентификации проверяет действительность билета (то есть существует соответствующая сессия) и возвращает результат в систему 2.

8. Система 2 может считать пользователя “вошедшим в систему” после получения результата успешной проверки из центра аутентификации.

Полный междоменный единый вход

Полный междоменный единый вход Как упоминалось ранее, здесь мы повторим: 1. Каждому сайту нужен свой собственный билет (при условии, что система 1-A-tikcet, система 2-B-билет, а центр аутентификации-P-билет) 2. При доступе к прикладной системе (система 1, система 2), если соответствующего билета нет, автоматически перенаправьте в систему аутентификации (P), перенаправьте в прикладную систему (система 1 или система 2) после того, как система аутентификации получила P-билет, обменяйте P-tikcet на соответствующий A-билет или B-билет; при отмене отмените все P-билеты (P-билет, A-билет, B-билет)

Подробные иллюстрации приведены ниже: Примечание. В конкретной реализации файл cookie может использоваться для реализации билета. Билет может быть файлом cookie, содержащим идентификатор сеанса.

1. Система доступа пользователя 1. Система 1 обнаруживает, что пользователь не вошел в систему (без билета), переходит в центр аутентификации и принимает URL-адрес системы в качестве параметра (то есть URL обратного вызова, чтобы пользователь мог вернуться после аутентификации).

2. Центр аутентификации обнаруживает, что пользователь не вошел в систему (нет-билет), и направляет пользователя к интерфейсу входа.

3. Пользователи отправляют регистрационную информацию в центр аутентификации.

4. Центр аутентификации проверяет регистрационную информацию пользователя. После проверки создается глобальный сеанс и генерируется билет, привязанный к текущему сеансу. Затем P-билет отправляется пользователю и перенаправляется в систему 1 (обратите внимание, что P-билет прилагается).

5. Система 1 получает запрос с P-билетом и отправляет запрос в центр аутентификации для проверки действительности P-билета.

6. Центр аутентификации получает запрос на проверку системы 1 и возвращает результат проверки системе 1. В то же время, если это подтверждено, связь сопоставления (P-билет, система 1) записывается в таблицу сопоставления (называемую таблицей “P-билет”). Список реестра , То есть для записи соответствующей взаимосвязи между подсистемами, вошедшими в систему, и P-билетом, чтобы, когда пользователь выйдет из системы, он мог отправить запрос в соответствующую подсистему и уничтожить соответствующий локальный сеанс.

7. Система 1 принимает результаты проверки из центра аутентификации. Если проверка проходит успешно, пользователь считается “вошедшим в систему”. Система 1 создает сеанс (локальный сеанс) для пользователя в своей собственной системе и генерирует билет, привязанный к сеансу. В то же время он записывает взаимосвязь сопоставления (A-билет, P-билет) в одну из своих таблиц сопоставления (называемую таблицей). “Таблица сопоставления билетов” ) Затем система 1 отправляет пользователю билет. При последующем доступе пользователя к системе 1 с ним будет доставлен билет, который можно использовать для определения того, вошел ли пользователь в систему.

8. Пользователь обращается к системе 2. Система 2 обнаруживает, что пользователь вошел в систему (без B-билета), переходит в центр аутентификации (в это время доступ к центру аутентификации будет осуществляться по P-билету) и принимает URL системы 2 в качестве параметра (то есть URL обратного вызова, чтобы после аутентификации можно было вернуться).

9. Центр аутентификации обнаруживает, что пользователь вошел в систему (поскольку у пользователя уже есть P-билет). После подтверждения действительности P-билета пользователь может считаться “вошедшим в систему”. Центр аутентификации перенаправляет пользователя в систему 2 (с P-билетом).

10. Система 2 получает запрос с P-билетом и отправляет запрос в центр аутентификации для проверки действительности P-билета.

11. Центр аутентификации получает запрос на проверку системы 2 и возвращает результат проверки системе 2. В то же время, в случае подтверждения, в систему будет добавлена связь сопоставления (P-билет, система 2). Список реестра 。

12. Система 2 принимает результаты проверки из центра аутентификации. Если проверка проходит успешно, пользователь считается “вошедшим в систему”. Система 2 создает сеанс (локальный сеанс) для пользователя в своей собственной системе и генерирует B-билет, привязывающий сеанс. В то же время он записывает взаимосвязь сопоставления (A-билет, P-билет) в свою собственную таблицу сопоставления (называемую таблицей). “Таблица сопоставления билетов” ) Затем система 2 отправляет пользователю B-билет. При последующем доступе пользователя к системе 2 с ним будет доставлен B-билет, который можно использовать для определения того, вошел ли пользователь в систему.

Схема выхода из системы:

1. Пользователь инициирует запрос на отмену в систему 1 (с билетом).

2. Система 1 основана на таблице сопоставления “Таблица сопоставления билетов” Удалите соответствующий P-билет. Система 1 инициирует запрос на отмену (с P-билетом) в центр аутентификации.

3. Действительность P-билета проверяется после получения центром сертификации запроса на отмену. Если P-билет действителен, локальная глобальная сессия (в соответствии с P-билетом) уничтожается. Центр сертификации из Списка реестра Узнайте все системы, связанные с P-ticket, и отправьте запрос на частичную отмену сеанса во все соответствующие системы.

4. Система 2 получает запрос “отменить локальный сеанс” от центра аутентификации, и, согласно P-билету, она получает запрос “отменить локальный сеанс” от центра аутентификации. “Таблица сопоставления билетов” Удалите соответствующий B-билет и уничтожьте локальную сессию в соответствии с B-билетом.

5. Система 1 получает запрос “отменить локальный сеанс” от центра аутентификации, и, согласно P-билету, она получает запрос “отменить локальный сеанс” от центра аутентификации. “Таблица сопоставления билетов” Удалите соответствующий A-билет и уничтожьте локальную сессию в соответствии с A-билетом.

Примечательные моменты: 1. В приведенных выше реализациях мы видим, что P-билет должен передаваться с каждого конца, поэтому по соображениям безопасности мы должны выполнить некоторую обработку безопасности для P-билета, такую как шифрование.