#web-services #authentication #soap
Вопрос:
У нас есть веб-службы SOAP в производстве, которые полагаются на заголовки SOAP (содержащие обычные учетные данные клиента) для аутентификации. WS используются в гетерогенных средах с клиентами .NET/Java/PHP/Python/C как для веб-приложений, так и для настольных приложений.
Мы рассматриваем версию v2 для этих WS, и мне интересно, что считается лучшей практикой для аутентификации WS SOAP? (достаточно безопасный, но простой в обращении на самых разных платформах).
Ответ №1:
Самый простой способ справиться с этим на различных платформах-использовать базовую аутентификацию HTTP и HTTPS для транспортного уровня. WS-Безопасность была бы хороша, если ваши потребности выходят за рамки простого имени пользователя/пароля, но поддержка будет довольно сильно различаться между платформами. Аутентификация HTTP поддерживается каждой достойной реализацией SOAP.
Ответ №2:
Если вам нужно свернуть все это самостоятельно и вы не можете использовать HTTPS, я бы посоветовал использовать часть WS-Security, основанную на хэшах. Это довольно безопасно и довольно легко реализовать, если в ваших библиотеках есть функции хэширования.
Если вы занимаетесь веб-сервисами, я бы не стал полагаться на HTTP для аутентификации.
WS-Безопасность в целом слишком велика.
Комментарии:
1. Почему бы не полагаться на существующую аутентификацию HTTP, это только в том случае, если вы НЕ МОЖЕТЕ использовать https?
2. @Xepoch говорит об основной аутентификации, где имя пользователя и pwd отправляются в качестве заголовка soap ?
3. @Дэвид, пожалуйста, скажите мне, как реализовать «хэш-ориентированную часть WS-безопасности». можете ли вы дать мне любую ссылку, по которой я могу прочитать код и загрузить код для запуска на своем ПК. спасибо
Ответ №3:
В прошлом я решал эту проблему с помощью стандартных функций WS -*.
Вместо использования функции аутентификации мы включили функцию целостности заголовка сообщения. Это требует, чтобы обе стороны диалогового окна имели доступ к паре открытый/закрытый ключ и обнаруживали любое изменение поля имени пользователя в заголовке. Таким образом, вы можете быть уверены, что тот, кто отправил сообщение и установил идентификатор пользователя, имеет доступ к закрытому ключу.
Это обеспечивает разумный уровень целостности при правильном управлении ключами.