Аутентификация для уведомлений пользователей с помощью Crossbar/Autobahn?

В настоящее время я пытаюсь реализовать систему уведомлений пользователей с использованием веб-сокетов через Crossbar/Autobahn. Я провел несколько тестов и просмотрел документацию, однако я не уверен, есть ли решение для работы следующего рабочего процесса:

  1. Пользователь входит в веб-приложение — это делается через JWT.
  2. Frontend устанавливает соединение через веб-сокет с работающим экземпляром crossbar.
  3. Фронтенд пытается подписаться на URI специально для уведомлений пользователя: т. е. com.example.notifications.user.23 или com.example.user.23.notifications'. Where23` — это идентификатор пользователя.
  4. JWT пользователя проверяется, чтобы узнать, разрешен ли пользователю доступ к подписке.
  5. Когда действие генерируется и вызывает уведомление, серверная часть публикует пользовательские URI.

Что касается шага 3, я не могу сказать, есть ли у текущих методов аутентификации поддержки то, что мне нужно. В идеале мне нужен метод аутентификации, который я могу настроить (чтобы внедрить аутентификатор JWT в Crossbar), который я могу применить к шаблону URI, но НЕ предоставлять доступ ко всему шаблону подписавшемуся пользователю. Это частично решается методами динамической аутентификации, но отсутствует вторая половина:

Например (мой идеальный рабочий процесс):

  1. Пользователь пытается подписаться на URI com.example.user.23.notifications.
  2. URI соответствует com.example.user..notifications (шаблон подстановки в http://crossbar.io/docs/Pattern-Based-Subscriptions /)
  3. Токен авторизации проверяется, и пользователю предоставляется доступ только com.example.user.23.notifications.

Достижимо ли вышеизложенное простым способом? Из того, что я могу сказать, это может быть возможно только в том случае, если я каким-то образом сгенерирую .crossbar/config.json, который содержит перестановки URI всех идентификаторов пользователей... и автоматически создаст новую конфигурацию для каждого нового пользователя, что совершенно не является разумным решением.

Любая помощь приветствуется!


person ineedtosleep    schedule 25.02.2016    source источник


Ответы (1)


Используйте авторизатор.

См. http://crossbar.io/docs/Authorization/#dynamic-authorization.

Зарегистрируйте динамический авторизатор для роли пользователя, которой сеанс был назначен при присоединении/аутентификации:

           {
              "name": "authorizer",
              "permissions": [
                {
                  "uri": "com.example.authorize",
                  "register": true
                }
              ]
            },
            {
              "name": "authenticator",
              "permissions": [
                {
                  "uri": "com.example.authenticate",
                  "register": true
                }
              ]
            },
            {
              "name": "user",
              "authorizer": "com.example.authorize"
            },
...
"components": [
    {
      "type": "class",
      "classname": "example.AuthenticatorSession",
      "realm": "realm1",
      "role": "authenticator",
      "extra": {
        "backend_base_url": "http://localhost:8080/ws"
      }
    },
    {
      "type": "class",
      "classname": "example.AuthorizerSession",
      "realm": "realm1",
      "role": "authorizer"
    }
  ]

Написать класс

class AuthorizerSession(ApplicationSession):
    @inlineCallbacks
    def onJoin(self, details):
        print("In AuthorizerSession.onJoin({})".format(details))
        try:
            yield self.register(self.authorize, 'com.example.authorize')
            print("AuthorizerSession: authorizer registered")
        except Exception as e:
            print("AuthorizerSession: failed to register authorizer procedure ({})".format(e))

    def authorize(self, session, uri, action):
        print("AuthorizerSession.authorize({}, {}, {})".format(session, uri, action))
        if session['authrole'] == u'backend':  # backnend can do whatever
            return True
        [Authorization logic here]
        return authorized
person ImplexOne    schedule 25.02.2016
comment
Действительно, это так. Я действительно пробовал это раньше, но я не понимал, что это вызывается для нескольких событий. Данных, представленных в session, uri и action, также недостаточно для моих целей, поэтому я взломал передачу данных URI в authorize. - person ineedtosleep; 27.02.2016