Как использовать учетные данные LDAP в автономном режиме?

Question

Я хотел бы использовать сервер LDAP (вероятно, каталог Apache ) для управления логинами и учетными данными для приложения. Время от времени приложение должно работать в автономном режиме (на ноутбуке) без подключения к серверу LDAP.

Каков наилучший способ репликации учетных данных локально?

Я уже думал о:

• Использование Mitosis для репликации сервера LDAP на ноутбуке.

  Но это было бы довольно "тяжелое" и сложное решение. Более того, Митоз, похоже, еще не закончен.

• Экспорт учетных данных в виде файла LDIF, который можно сохранить на ноутбуке.

  Но мне нужен способ проверить, что файл LDIF действительно поступает с сервера LDAP (файл должен содержать своего рода подпись). Кроме того, я хотел бы отклонить файлы LDIF, которые не обновлялись более недели. Было бы неплохо, если бы я сам мог избежать подписания и проверки возраста.

Какие-нибудь другие идеи или инструменты, которые могут мне помочь?

Отредактировано Edit: Я посмотрел на Kerberos, потому что документация Java-Kerberos-API , кажется, говорит о том, что возможно использовать кэшированный тикет в локальном кеше и я подумал, что это может быть решением для меня. Кроме того, Kerberos может быть добавлен в качестве плагина к Apache Directory. Но в кэше Kerberos хранятся расшифрованные билеты (с целью обмена ими с другими приложениями). Мне понадобится зашифрованная версия билета, чтобы иметь возможность проверить пароль пользователя во время автономного сеанса. Вывод: Kerberos не предлагает простого решения моей проблемы.

Answer 1

Зная, что , вероятно, будет нормально, если пользователь должен будет войти в систему один раз, прежде чем сможет войти в автономный режим , рассмотрим следующий алгоритм:

1. пользователь предоставляет вашему приложению (username + password)
2. приложение пытается связаться с LDAP для аутентификации
   • работаешь онлайн? (например, соединение установлено)
     1. приложение аутентифицируется по LDAP с использованием (username + password)
        • аутентификация прошла успешно?
          1. приложение сохраняет или обновляет hash(password) как (cached_credentials) для (username) в локальном безопасном хранилище
          2. заявка продолжается как аутентифицировано [[STOP]]
        • аутентификация не удалась?
          1. приложение обрабатывается как без проверки подлинности (неверные учетные данные) [[STOP]]
   • работает в автономном режиме? (например, ошибка сети)
     1. приложение пытается получить (cached_credentials) для (username) из локального безопасного хранилища
        • (cached_credentials) существует AND более поздняя версия, чем (1 week)?
          1. приложение сравнивает (cached_credentials) с hash(password)
             • спичка
               1. заявка продолжается с проверкой подлинности [[STOP]]
             • нет совпадений?
               1. приложение обрабатывается как без проверки подлинности (неверные учетные данные) [[STOP]]
        • (cached_credentials) не существует OR менее недавно, чем (1 week)?
          1. приложение продолжает работать как без аутентификации (ошибка сети) [[STOP]]

Между прочим, это (или было IIRC) та же модель, используемая Windows NT + для аутентификации пользователей на контроллерах домена. При входе в систему делается попытка аутентификации на контроллере домена и создание или обновление локальной (кэшированной) версии профиля пользователя. Если контроллер домена недоступен, пользователю предлагается продолжить аутентификацию по учетным данным, записанным в локальном (кэшированном) профиле (если таковой существует).

---

EDIT

• Да, по сути, это то же решение, что и локальное копирование файла ldif, за исключением того, что вам не нужно анализировать ldif, когда вы не в сети. :)
• Понятно, что вы можете хранить любые дополнительные атрибуты (разрешения и т. Д.) В своем кэше
• Также подразумевается, что «безопасное хранилище» как минимум подписано. :) Вы можете сделать это достаточно легко с помощью хэша и секрета SHA-1, или вы можете использовать полноценных поставщиков криптографии, доступных на вашей платформе (или в Java, если используется Java). Вам не нужно шифровать это так долго так как внутри не хранится секретная информация.

Answer 2

Вот решение, которое я решил использовать (я уже описал его в редактировании моего вопроса, но я хотел бы принять ответ, чтобы «закрыть» вопрос):

Поскольку я не нашел другого решения, я решил использовать экспорт LDIF, добавить метку времени в качестве комментария в начале файла и затем подписать файл. Чтобы подписать файл, я вычисляю хеш-значение (SHA-1) файла + секретный ключ. Подпись добавляется в качестве комментария в начале файла. Чтобы проверить подпись, я удаляю первую строку подписанного файла и пересчитываю значение хеш-функции.