Безопасность для Spring Restful Web Services

Question

Я пишу проект Spring Restful Web Services. Мне нужно написать безопасные веб-сервисы. Для безопасности я уже использую Spring Security + SSL, однако теперь мне нужно немного security для шифрования и подписи сообщений . Я знаю, как зашифровать сообщение из кода, однако я ищу механизм, позволяющий автоматически шифровать / расшифровывать и подписывать сообщения.

Я искал различные альтернативы для безопасности, включая Spring WSS и другие, но большинство из них для SOAP. Кто-нибудь может предложить мне какой-нибудь лучший механизм безопасности и ссылку на него.

Answer 1

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

1) Аутентификация. - Для аутентификации можно использовать Spring Security.
2) Авторизация. - Для авторизации запроса можно использовать OAuth.
3) Обеспечение безопасности общения. - SSL можно использовать для защиты канала связи.
4) Шифрование - снова Oauth может решить цель
5) Подписание сообщения. - Снова Оаут может решить цель

Таким образом, для обеспечения спокойной безопасности веб-службы Spring + можно использовать OAuth. Другие механизмы безопасности, которые можно использовать, это Http Basic Security и Digest Security.

Вот очень хороший пример, обеспечивающий весенний отдыхающий веб-сервис с пружинной безопасностью: http://java.dzone.com/articles/securing-restful-web-service

Также для использования безопасности пружины в сочетании с OAuth вы можете следовать этому руководству:

Пружина безопасности с OAuth

Answer 2

У вас есть два шаблона безопасности REST:

1. Шифровать и подписывать запросы / ответы на уровне приложений и запускать по HTTP. Это включает в себя значительный объем работы, как вам нужно канонизировать все данные перед подписью и убедиться, что клиент / сервер следует точно так же. Этот подход был принят в начале версии протоколов веб-сервисов Amazon.

2. Использовать SSL (возможно, с клиентскими сертификатами). Это предпочтительный подход, так как нет необходимости изобретать велосипед. Ускорители SSL доступны и производительность будет значительно лучше, чем обработка шифрования и подписание вашего кода.

Amazon перешел на использование SSL, и вы должны сделать то же самое. Эта статья дает хорошее сравнение двух подходов.

ОТДЫХ против SOAP

Вы ссылались на SOAP и WS-Security, которые определяют протокол для шифрования и подписи на уровне сообщений (а не транспорта). Причина, по которой WS-Security определяет такой протокол, заключается в обеспечении сквозной конфиденциальности, целостности и аутентичности в архитектуре SOA с посредничеством. Например, вы можете отправить SOAP-сообщение из службы A в службу B, которая проходит через CD и E. SSL / TLS работает на транспортном уровне и поэтому будет защищать только сообщение между A и B. Однако REST не предназначен для брокерской архитектуры так что этот подход не применим в вашем случае.