Защита веб-службы с сохранением состояния

Question

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

Эта устаревшая система защищена таким образом, что требуется первоначальная аутентификация по имени пользователя и паролю (процесс, который может занять от 5 до 10 секунд).После первоначальной аутентификации возвращается ограниченный по времени токен.Затем этот токен должен быть включен во все дальнейшие запросы, иначе запросы будут отклонены.

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

Служба RESTслой будет реализован с использованием стека Java 6 + Spring 3 + Spring Security 3.На первый взгляд кажется, что эта установка будет работать нормально: службы REST на основе Spring будут защищены с использованием довольно стандартной конфигурации Spring Security, устаревший токен безопасности будет храниться в сеансе HTTP пользователя, и каждый вызов будет извлекать этот токен с помощьюсеанс пользователя и отправка его в унаследованную систему.

Но возникает вопрос: как клиенты REST будут отправлять необходимые данные, чтобы HTTP-сеанс пользователя был получен правильно?Обычно это делается прозрачно веб-браузером, использующим cookie-файл JSESSIONID, но ни один браузер не участвует в этом процессе.Конечно, клиенты REST могут добавить управление cookie-файлами в свой код, но это простая задача для всех клиентов Spring RestTemplate, iPhone, BlackBerry и Android?

Альтернативой может быть обход HTTP-сеанса на уровне службы REST.и использовать некоторую другую форму сеанса пользователя, возможно, с использованием базы данных, которая будет идентифицирована с использованием некоторого ключа, который будет отправлен клиентами REST через заголовок HTTP или простой запрос запроса.Тогда возникает вопрос: как настроить Spring Security для использования этого альтернативного механизма сеанса вместо стандартного Servlet HttpSession?

Конечно, я не первый, кто сталкивается с этой ситуацией.Что мне не хватает?

Спасибо!

Answer 1

В печенье нет ничего волшебного.Это просто строки в заголовках HTTP .Любой достойный клиентский API может их обрабатывать, хотя многим требуется явная конфигурация для включения обработки файлов cookie.

Альтернативой использованию файлов cookie является добавление JSESSIONID в URL-адрес.Я ничего не знаю о Spring-Security, но похоже, что это действительно значение по умолчанию по крайней мере для некоторых типов URL-запросов, если только disable-url-rewriting явно не установлено в true.Это можно рассматривать как слабость безопасности , хотя.

Answer 2

К сожалению, аутентификация очень проблематична - немного слепая точка с точки зрения веб-стандартов и реализации браузеров. Вы правы в том, что куки не считаются «RESTful», но являются пуристами, но даже в полнофункциональных браузерах избегание требует немало взлома, как описано в этой статье: Аутентификация на основе отдыха .

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

• HTTP-аутентификация (в идеале "дайджест", а не "базовая")
• печенье

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