Аутентификация Node.js ESB для соединения с облачными сервисами
Я предполагаю, что можно достигнуть того, что Вы хотите с чем-то вроде этого (не протестированный, просто из памяти и вероятно работа привычки, но может дать Вам некоторые подсказки для запуска). В попытке веб-сервера:
iptables -t nat -I PREROUTING -p tcp --dport 5678 -j REDIRECT --to-port 1234
iptables -t nat -A PREROUTING -p tcp --dport 1234 -j DNAT --to-destination database.server.com
Если у Вас нет своего сервера базы данных, непосредственно недостижимого от Вашего маршрутизатора, можно сделать то же просто отображение соответствующих портов непосредственно в маршрутизаторе.
Однако, по-моему, Вы должны все еще с помощью туннеля ssh потому что его преимущества:
1) соединение требует аутентификации, которая хороша 2), трафик шифруется 3), можно настроить соединение каждый раз, когда Вы желаете с ssh (добавляющий сжатие, добавляя больше портов для туннелирования, добавляя socks5 привязку, и т.д...
Что касается аутентификации ESB, я могу сказать о SwarmESB (я автор), что легко изменить механизмы аутентификации: у вас есть и внешний сервис, предлагающий API (REST или что-то еще. Я использовал LDAP для проекта и локальную базу данных в другом) и адаптер (процессы node.js, предлагающие ваши собственные адаптированные API-интерфейсы для роя или для пересылки во внешнюю службу), и вы определяете описание роя (например, сценарий, написанный на JS и использующий 'swarm' и несколько соглашений), которые можно изменить в любое время без изменения кода клиента или кода адаптеров. С помощью нескольких IF вы можете легко получить другой алгоритм для отладки / разработки, разных клиентов, пользователей, провайдеров аутентификации и т. Д.
Мне нравится видеть сходство между SwarmESB и другими (обычно Java) ESB как сходство между REST и SOAP. Они служат тому же размаху, но с радикальным подходом к устранению (обычно бесполезной) церемонии. Я попытался создать решение, обладающее архитектурной гибкостью ESB, не платя за сложность обучения программистов с довольно сложными концепциями. Если кто-то понимает модель обмена сообщениями swam и некоторые детали, он может легко начать писать код node.js, который интегрирует различные API (веб-службы или что-то еще)
. Я обучал нескольких новичков node.js, чтобы понять концепции, и они стали способен сделать значимую работу за несколько дней. До сих пор я использовал SwarmESB в двух проектах (один для крупного румынского агентства, он стабилен и работает без проблем более года). SwarmESB выполняет свою работу, но все еще не так хорошо документирован (у меня нет ресурсов, время и т. д.) и не может масштабироваться бесконечно (как это могло бы быть теоретически, потому что немного ограничено одним экземпляром Redis PUB / SUB), и я мог бы быстро улучшить эти аспекты. Также я бы немного улучшил механизмы обработки ошибок и восстановления после сбоев. Может потребоваться немного доверия и любви к идее роя, чтобы использовать ее в новых проектах, и вам понадобится я как консультант и инструктор, чтобы начать проект, но все с открытым исходным кодом, и кода не так много, это выполнимо.
Один из аспектов заключается в том, что до сих пор мы использовали SwarmESB только с клиентами, использующими сокеты (flash и веб-сокеты), а модель swarm предоставляет push-уведомления от дизайна. Наличие чистых клиентов AJAX возможно, но, вероятно, не лучший вариант использования. Воспринимаемая скорость сокетов - большое преимущество UX. Что касается паспортов, вы можете отложить принятие решения, потому что с ESB вы получаете гибкость и можете сосредоточиться на разработке своих сервисов (адаптеров) и позволить аутентификацию до тех пор, пока вы не узнаете, каких провайдеров аутентификации вам действительно следует использовать с точки зрения бизнеса. Веб-сервер, использующий passwordjs, может использоваться как внешняя служба или предоставляться адаптером, используемым клиентами роя для подключения к ESB. Если интересно, со мной можно связаться по Skype, и я объясню, что возможно.