Как аутентифицировать пользователя приложения при подключении к RabbitMQ по протоколу WEB-STOMP?
Исходные данные
Дано: WEB-приложение на PHP с фронтендом на JS, а также RabbitMQ, который в том числе используется как websocket сервер, работающий по протоколу STOMP (web-stomp-plugin).
Схема взаимодействия стандартная: фронтенд приложение, используя stomp.js, подключается к RabbitMQ, авторизуясь при помощи логина и пароля. На RabbitMQ созданы exchange типа fanout для каждого зарегистрированного пользователя веб-приложения - они используются для передачи push-сообщений в сторону фронтенда. Фронтенд после загрузки сразу же подключается к RabbitMQ, создает временную автоубиваемую очередь и подключает ее к конкретному exhange, ассоциированному с текущим пользователем web-приложения. Теперь, если бекенд отправит сообщение в exchange пользователя - оно сразу же попадет во все очереди, подключенные к нему и будет передано в сторону фронтенд по протоколу stomp. Эта схема работает отлично.
Проблема
Дело в том, что изучив исходный js-код на фронтенде или же трафик, можно найти там логин и пароль подключения к RabbitMQ, а также наименование exchange, к которой подключается очередь, созданная фронтендом. Имея эти данные можно не санкционировано подключаться к RabbitMQ, а также создавать очередь и подключать ее к любому exchange, перехватывая информацию, которая предназначается другим пользователям.
Вопрос
Каким образом можно организовать доступ к конкретному exchange только в пределах известной сессии? Или же каким-то другим способом? Наверняка есть стандартные решения этого вопроса безопасности, реализуемые средствами в RabbitMQ.
Решение на вскидку - сделать небольшой сервис, который будет авторизоват пользователя по токену или по куке и прокидывать запросы на rmq. Но это выглядит как велосипед, возможно есть более адекватные способы решения проблемы, может кто напишет...
Создавать очереди должен только бэкенд (PHP). Он же выдает уникальные ID (например, session_id или md5) клиенту. Далее клиент подключается к ранее созданной очереди с этим ID.
Теоретически клиент может брутфорсить очереди, но можете сами посчитать, сколько там будет возможных комбинаций.
P.S. Логин/пароль на клиенте нет смысла использовать, ибо он все легко равно перехватывается.