Проверка подлинности веб-приложения Kerberos: правильный ли способ объединения с файлами cookie? - PullRequest
Новая
       7

Проверка подлинности веб-приложения Kerberos: правильный ли способ объединения с файлами cookie?

0 голосов
/ 12 февраля 2019

Сценарий:

  • Корпоративное веб-приложение Python за брандмауэром.
  • Для аутентификации пользователей следует использовать Kerberos.
  • У меня естьрабочий код, который отправляет правильные ответы с сервера (заголовок Negotiate и т. д.) и получает имя пользователя Windows пользователя, обращающегося к приложению, используя пакет kerberos-sspi

У меня малоопыт работы с Kerberos, но некоторый опыт работы с веб-приложениями.

В других созданных мной веб-приложениях Python, использующих встроенную базу данных пользователей, процесс аутентификации обычно выглядит следующим образом:

  • Для каждого запроса проверьте, есть ли в запросе (подписанный) cookie-файл, содержащий идентификатор пользователя (или какой-либо вариант - например, с помощью flask-login, где идентификатор пользователя хранится в flask.session)
  • Если cookie-файлсуществует, ответьте нормально.
  • Если таких файлов cookie не существует, перенаправьте на /login/, отображая форму имени пользователя / пароля.POST до /login/ проверяет правильное имя пользователя / пароль, устанавливает безопасный cookie и перенаправляет на URL, указанный в параметре запроса ?next=.

Мой вопрос:

  • В веб-приложении, аутентифицированном Kerberos, похож ли поток аутентификации?

  • То есть я должен делать следующее:

    • Для каждого запроса проверять, является ли запросимеет (подписанный) файл cookie, содержащий идентификатор пользователя
    • Если файл cookie существует, ответьте нормально.
    • Если файл cookie не существует, перенаправьте на /login/./login/ выполняет необходимые действия, чтобы выяснить, кто пользователь (т.е. отправляет заголовок Negotiate, использует kerberos_sspi, чтобы найти имя пользователя и т. Д.), Затем устанавливает безопасный cookie и перенаправляет на URL-адрес, указанный в ?next= параметр запроса.

  • Или это нужно обрабатывать другим способом?

1 Ответ

0 голосов
/ 22 февраля 2019

Да, предлагаемый вами поток выглядит жизнеспособным.

Вы могли бы выполнить согласование Kerberos в качестве первой вещи, приземлившись на /login/ и перенаправить пользователя обратно в сеанс, если Kerberos сказал «да».Это может быть даже запрос XMLHttpRequest в фоновом режиме и перенаправление на /login/, если сеанс перестает быть действительным.Если сеанс проверяется в фоновом режиме, срок действия файлов cookie может быть значительно короче, чем у маркеров Kerberos, и в любой момент времени у вас будет меньше действительных сеансов, о которых нужно беспокоиться.

Если сеанс не существует, предложите Kerberosи потенциальные другие методы входа для пользователя.

Если у пользователя есть действительный сеанс через Kerberos, но нет профиля пользователя, предоставьте пользователя в приложение.Здесь вы можете опросить пользователя для получения дополнительной информации на месте, принять решение на основе групп и ролей или создать пользователя в качестве заглушки с набором разрешений по умолчанию, известными пропущенными значениями и, таким образом, отложить процесс.

Это было все очень общее.Вам, вероятно, следует проверить, что вы пытаетесь сопоставить свои цели с тройным А или AAA , как в Аутентификации, Авторизации и Учете.Кажется очевидным, что Kerberos выполняет аутентификацию, и необходимо определить остальные роли.

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

...