LINUX.ORG.RU

Размышления по поводу ldap юзеров в python

 ,


1

1

Какую бы документацию или мануал по интегрированию ldap юзеров в flask я не открыл, она всегда сводится к тому, чтобы один раз при авторизации забрать слепок юзера с ldap и запухнуть его куда-нибудь в другую базу данных , будь то sql или словарь или еще что-то.

Если почитать мой прошлый пост, то у меня были проблемы с uswgi воркерами. Каждый из них требовал отдельной авторизации одного и того же юзера. И решением было сохранять юзера в sql.

Сама концепция этого довольно костыльная. У меня есть open-ldap, а я кеширую юзеров в другое место. Но так же это приведет к лагам между изменением в open-ldap и реакции приложения на эти изменения:

Допустим у меня есть роут

@app.route('/test')
@role_required('admin')
def test():
  return "ldap admin access"

роль 'admin' это принадлежность юзера к группе в ldap, но я ее кеширую вместе с юзером в sql. И выходит, что когда я исключу юзера из этой группы в ldap, его кешированная копия в приложении все равно будет иметь доступ к этому маршруту.

А ведь мне нужен максимально быстрый отклик на такие изменения. И вот уже я переписываю врапер @role_required, чтобы он опрашивал ldap в реальном времени.

Но почему я не могу просто и сразу прямо использовать ldap в качестве базы юзеров? без sql или каких-то костылей?

Или как мне очищать sql от юзеров по таймауту?

★★★

Можно прямо сразу использовать ldap в качестве базы юзеров, это правильно. Не знаю где ты нашел что костыли необходимы. Реализации LDAP как правило на порядок быстрее чем RDBMS.

ei-grad ★★★★★ ()
  1. правильнее выкинуть бидон и взять яву/c#, если проект еще не зашёл далеко в разработке и там в asp.net core или spring использовать ldap напрямую

  2. если ваш ldap-сервер позволяет, написать хук на изменение пользователя, который будёт дергать flask, чтобы он сходил за обновлённой информацией по пользователю

Ford_Focus ★★★★★ ()
Последнее исправление: Ford_Focus (всего исправлений: 1)
Ответ на: комментарий от Ford_Focus

правильнее выкинуть бидон и взять яву/c#

ну у меня проект не самоцель, цель - язык. Я начал с консоли, затем прицепил flask, затем разбил на файлы. На каждом шаге полная реструктуризация кода и навешивание функционала. Планирую сейчас блюпринты, потом пойду в django. Яву я терпеть не могу, потому что она жрет. Про си как-то даже и не думал. В общем, речь о смене языка не идет.

Хуки - тоже костыль имхо. Мне, наверно, проще сделать тогда таймаут сессии и перезаписывать юзера при логине.

constin ★★★ ()

Может быть правильнее использовать nsswitch модуль ldap? Тогда ldap пользователи станут Unix пользователями. Unix пользователей ведь неведомой мне flask поддерживает?

iliyap ★★★★★ ()
Ответ на: комментарий от constin

Планирую сейчас блюпринты, потом пойду в django

Не знаю насчёт flask, но джанга всегда будет сохранять кусок юзера в свою базу при аутентикации в ldap. Она не должна дать зайти если юзер из ldap удалён на момент входа, но если есть старая сессия — её никто не убьёт. Без своей модели в джанге нельзя (вообще никак) потому, что в очень многих местах ожидается foreign key на settings.AUTH_USER_MODEL, поэтому, очевидно, таблица с этой AUTH_USER_MODEL обязана быть в той же базе, что и всё остальное приложение.

я ее кеширую вместе с юзером в sql.

Если flask сделан нормально — он не должен кэшировать пароль и должен обновлять копию в твоей rdbms каждый раз когда юзер вводит этот самый пароль.

Или как мне очищать sql от юзеров по таймауту?

Убедись, что твоя проблема — не в сессиях. Судя по твоему вопросу, она именно там.

Ты можешь добавить лишнюю проверку статуса в ldap при подхвате сессии с юзером, это решит все проблемы (ну, у тебя добавится 1 запрос в ldap на буквально каждый HTTP-запрос, но иногда это может быть ок решением).

Но почему я не могу просто и сразу прямо использовать ldap в качестве базы юзеров? без sql или каких-то костылей?

Потому, что foreign key и транзакции между двумя разными базами данных (твоя rdbms и LDAP) — ОЧЕНЬ сложные вещи и django/flask не заморачиваются ими.

Но так же это приведет к лагам между изменением в open-ldap и реакции приложения на эти изменения:

Потому, что у тебя распределённая система и твоя проблема — на выбор — инвалидация кэша либо распределённые транзакции. Прямой способ решить всё это — не делать систему распределённой (= хранить все разрешения и роли в ldap), тогда ты потеряешь возможность управлять юзерами средствами flask/django. И да, тебе придётся переписать весь auth-кусок этих фреймворков поскольку навскидку готового решения (без копирования информации из ldap) я не помню. Я бы посоветовал вместо этого пользоваться костылями, если честно.

x3al ★★★★★ ()
Последнее исправление: x3al (всего исправлений: 1)

как мне очищать sql от юзеров по таймауту?

Кстати, в большинстве приложений так не выйдет. Допустим, у тебя есть поле `created` (или `updated`, неважно), которое foreign key на твою модель юзера в flask/django. Если ты удалишь юзера из своей базы — всё созданное им будет, на выбор, с created=null либо каскадно удалено. Обычно ты этого не хочешь.

x3al ★★★★★ ()
Ответ на: комментарий от constin

Ява жрет, но питон просто глотает непережевывая и потом неделю лежит, пока не переварит. Я если что питон люблю, а яву нет, но такой критерий нелюбви к Ява в сравнении с питоном очень удивляет.

anonymous ()
Ответ на: комментарий от x3al

Всё правильно написал, но есть ньюанс про «кусок юзера в django». Это нормально, записи в django и LDAP - отдельные сущности которые используются для разных целей. Конечно это зависит от приложения. У меня был проект где django с внешними юзерами в LDAP сочеталась и всё было сделано консистентно.

ei-grad ★★★★★ ()
Ответ на: комментарий от x3al

Потому, что у тебя распределённая система и твоя проблема — на выбор — инвалидация кэша либо распределённые транзакции.

инвалидация кэша

При обновлении данных в каталоге обновлять их или маркировать как устаревшие в рбд.

anonymous ()

И выходит, что когда я исключу юзера из этой группы в ldap, его кешированная копия в приложении все равно будет иметь доступ к этому маршруту.
А ведь мне нужен максимально быстрый отклик на такие изменения.

В этих ваших линуксах группы, к которым принадлежит пользователь читаются при логине и кэшируются до конца сессии/логаута. На максимально быстрый отклик всем насрать.

anonymous ()

Но почему я не могу просто и сразу прямо использовать ldap в качестве базы юзеров?

Тебе нужно логиниться, не зная пароля, в браузере под виндой?

См. SPNEGO (надстройка над GSSAPI) для Firefox и Chrome.

Для работы прозрачной доменной аутентификации (SSO) в nginx необходим пакет nginx-spnego, https://www.altlinux.org/Nginx/AD-auth

P.S. По состоянию на 2017 год Firefox поддерживает авторизацию через SPNEGO но по умолчанию она отключена из-за соображений безопасности. Поэтому на странице about:config в параметрах network.negotiate-auth.trusted-uris и network.negotiate-auth.delegation-uris надо прописать имя домена, например mydomain.int. Internet Explorer поддерживал SPNEGO-based Kerberos and NTLM HTTP Authentication ещё в 2006 году (RFC 4559).

Но я тут чисто теоретик, вся эта инфа найдена в инете.

BruteForceSSL ()
Ответ на: комментарий от BruteForceSSL

Мне не нужно логиниться под виндой, у меня, слава Линусу, нет виндовых серверов и клиентов на фирме. Я не думаю, что мне сейчас нужно SSO и я не писал об этом. Впрочем , на остальных сервисах, типа веб интерфейса к почте , я сделал SSO.

В результате я все таки пихаю в sql юзера и пароль. А его доступы я не кеширую и проверяю каждый раз при обращении к вьюшкам. При текущей нагрузке на приложение вроде все ок.

constin ★★★ ()
Ответ на: комментарий от BruteForceSSL

Где я хоть раз упоминал виндовые браузеры?

Вот твое сообщение, с их упоминанием, на основе которого ты зачем-то решил вести о них беседу :)

Тебе нужно логиниться, не зная пароля, в браузере под виндой?

constin ★★★ ()