Рекомендации по хранению токенов аутентификации

Question

У меня есть случай, когда неинтерактивные устройства периодически отправляют данные на сервер через HTTP. Я думаю о том, чтобы использовать аутентификационный подход для проверки правильности запросов от этих устройств.

Сначала устройство просыпается, инициирует ssl-соединение и отправляет свои учетные данные на сервер; сервер проверяет учетные данные и генерирует токен на основе SHA на основе учетных данных + некоторый случайный ввод и отправляет токен обратно на устройство

Этот токен должен присутствовать в качестве заголовка в каждом http-запросе, который отправляет устройство. Сервер будет использовать фильтр сервлетов, который ищет этот заголовок и отфильтровывает сообщения, в которых его нет.

Не передается конфиденциальная информация, я просто хочу убедиться, что устройство, общающееся с сервером, является действительным, а не кто-то пытается возиться с неверными данными. (Wannabe хакеры, сценаристы и т. Д.)

Токен должен храниться где-нибудь, где несколько «узлов» могут проверить, что запрос действителен - где вы порекомендуете сделать это?

Я могу придумать 3 подхода

1) Иметь отдельный веб-сервис, который поддерживает токены и выполняет аутентификацию (я ограничиваю это служебной нагрузкой для каждого запроса)

2) Поддерживайте набор аутентифицированных токенов в сеансе, и пусть контейнер сервлетов позаботится об этом, используя встроенную поддержку кластеризации (не уверен, что это самый надежный способ)

3) Использовать базу данных для хранения токенов и проверки их (с учетом Redis для этого)

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

Answer 1

Мое мнение:

1) Имею отдельный веб-сервис, который поддерживает токены и выполняет аутентификацию

Если речь идет о производительности и вам необходимо обслуживать много устройств, ясогласитесь, что это может стать узким местом производительности.

2) Поддерживать набор аутентифицированных токенов в сеансе и позволить контейнеру сервлета позаботиться об этом с помощью встроенной поддержки кластеризации.

Личное мнение: никогда не полагайтесь на сеансы в сценарии системной интеграции.Во-вторых, в кластерных средах вы должны реплицировать состояние сеанса между участниками.Хотя контейнер об этом позаботится, это повлияет и на производительность в случае репликации в памяти.

3) Используйте базу данных для хранения токенов и проверки ее (с учетом Redis для этого)

Если база данных уже существует, сделайте это здесь

Альтернатива: Используйте подход симметричного хеширования.После того, как устройство аутентифицировало себя, верните одноразовый токен (дайджест), каждый серверный узел может проверить независимо (на основе определенных критериев, например, пароля).«Ничего общего».

КСТАТИ: нет вопросов, транспорт должен быть защищен (TLS / SSL).

Answer 2

Я думаю, что 1-е решение будет наиболее масштабируемым и гибким.Попробуйте OpenAM с SAML.Это готовое решение.Он имеет такой фильтр и может управлять хранилищем с такими данными.Более пуленепробиваемое решение может быть основано на WebSphere DataPower и SAML .Если SAML слишком сложный, вы можете использовать легкое, нестандартное решение, но имхо первая идея будет лучшей.