Private Channels

#1

Hi there,

TL;DR - is it possible to create the concept of a ‘private’ channel with crossbar eg: 1 realm, many topics, 1 user/topic?

We are currently looking at integrating live updates into our tech stack and crossbar.io looks great, except for one small thing that I am unsure about.

We would like each client to have a websocket connection to the server, and receive updates only applicable for that user. This means that a user can’t see any other users updates, even if they know their ‘topic’ name and attempt to connect directly to it.

Essentially a private channel with just the user, and a HTTP-Pusher service pumping updates to the client.

I (think) the way to do this is:

1.) By creating a single realm, and each user must authenticate to connect to this realm using an auth backend

2.) Get the user to create their own topic based on some id unique to them

3.) When the user attempts to connect to this topic, the authorization handler does a check that this user is infact able to subscribe/create to this topic. If the user doesn’t have the correct authorization - ie hashes don’t match for example, they won’t be able to see the topic, this means that a user can only connect to their specific topic.

Does this sound like a possible implementation of the use case?

Moreover, if we want the user to also receive ‘system’ updates, I’m guessing the user can just subscribe to another topic ie: com.system.updates to get global messages whilst maintaining the existing websocket connection?

Thanks for your time!

Any help whatsoever is appreciated.

Cheers,

Ben

0 Likes

#2

Hi Ben!

You can have both a custom dynamic authenticator and a dynamic authorizer component. This gives you the possibility to e.g. use the authenticationID as part of your per-user topic, and verify this upon subscription, i.e. allows implementing your suggested flow.

For general updates, you can e.g. have a topic to which all sessions which have been authenticated as role ‘user’ can subscribe (and this can be statically configured). You can have multiple subscriptions on a single WAMP session (and over a single Websocket connection).

Hope this points you in the right direction.

Regards,

Alex

···

Am Freitag, 13. Februar 2015 15:47:12 UTC+1 schrieb Ben Novakovic:

Hi there,

TL;DR - is it possible to create the concept of a ‘private’ channel with crossbar eg: 1 realm, many topics, 1 user/topic?

We are currently looking at integrating live updates into our tech stack and crossbar.io looks great, except for one small thing that I am unsure about.

We would like each client to have a websocket connection to the server, and receive updates only applicable for that user. This means that a user can’t see any other users updates, even if they know their ‘topic’ name and attempt to connect directly to it.

Essentially a private channel with just the user, and a HTTP-Pusher service pumping updates to the client.

I (think) the way to do this is:

1.) By creating a single realm, and each user must authenticate to connect to this realm using an auth backend

2.) Get the user to create their own topic based on some id unique to them

3.) When the user attempts to connect to this topic, the authorization handler does a check that this user is infact able to subscribe/create to this topic. If the user doesn’t have the correct authorization - ie hashes don’t match for example, they won’t be able to see the topic, this means that a user can only connect to their specific topic.

Does this sound like a possible implementation of the use case?

Moreover, if we want the user to also receive ‘system’ updates, I’m guessing the user can just subscribe to another topic ie: com.system.updates to get global messages whilst maintaining the existing websocket connection?

Thanks for your time!

Any help whatsoever is appreciated.

Cheers,

Ben

0 Likes

#3

Hi Alex,

This was very helpful, thank you!

I have implmented a basic version of the ‘private’ channel mode, but I noticed in your documentation you have the secret in cleartext in the javascript - if I am not running over HTTPS, how might I be able to securely achieve this exchange? My cryptography knowledge is a bit rusty - does salting the secret solve this problem, and if so - can you point me to example python/js code to do so. I have seen a couple of places where salting is mentioned, but no clear use cases.

As for the system updates, you mention “have a topic to which all sessions which have been authenticated as role ‘user’ can subscribe”. How can a user have multiple roles? I attempted to set the authrole to a list in python, but this broke the auth handshake. Ideally I would want the perms on the system topic to be ‘subscribe’ only.

Thanks again for your help!

Cheers,

Ben

···

On Friday, February 13, 2015 at 5:12:00 PM UTC+1, Alexander Gödde wrote:

Hi Ben!

You can have both a custom dynamic authenticator and a dynamic authorizer component. This gives you the possibility to e.g. use the authenticationID as part of your per-user topic, and verify this upon subscription, i.e. allows implementing your suggested flow.

For general updates, you can e.g. have a topic to which all sessions which have been authenticated as role ‘user’ can subscribe (and this can be statically configured). You can have multiple subscriptions on a single WAMP session (and over a single Websocket connection).

Hope this points you in the right direction.

Regards,

Alex

Am Freitag, 13. Februar 2015 15:47:12 UTC+1 schrieb Ben Novakovic:

Hi there,

TL;DR - is it possible to create the concept of a ‘private’ channel with crossbar eg: 1 realm, many topics, 1 user/topic?

We are currently looking at integrating live updates into our tech stack and crossbar.io looks great, except for one small thing that I am unsure about.

We would like each client to have a websocket connection to the server, and receive updates only applicable for that user. This means that a user can’t see any other users updates, even if they know their ‘topic’ name and attempt to connect directly to it.

Essentially a private channel with just the user, and a HTTP-Pusher service pumping updates to the client.

I (think) the way to do this is:

1.) By creating a single realm, and each user must authenticate to connect to this realm using an auth backend

2.) Get the user to create their own topic based on some id unique to them

3.) When the user attempts to connect to this topic, the authorization handler does a check that this user is infact able to subscribe/create to this topic. If the user doesn’t have the correct authorization - ie hashes don’t match for example, they won’t be able to see the topic, this means that a user can only connect to their specific topic.

Does this sound like a possible implementation of the use case?

Moreover, if we want the user to also receive ‘system’ updates, I’m guessing the user can just subscribe to another topic ie: com.system.updates to get global messages whilst maintaining the existing websocket connection?

Thanks for your time!

Any help whatsoever is appreciated.

Cheers,

Ben

0 Likes

#4

Alex,

I seem to have solved the system topic problem.

I was unable to get the static permissions working as I was using a dynamic authorizer, and when i provided both the authorizer & permissions keys in the config, it seemed to ignore the custom authorizer and just dump me straight into the permissions which didn’t allow me to customize at a topic level.

I ended up just doing it all through the authorizer and checking things manually:

def authorize(self, session, uri, action):

stripped_uri = uri[len(“com.company.product.”):]

if stripped_uri == ‘system’:

grant everyone read access to system updates

if action == ‘subscribe’:

return True

return False

else:

ben’s temp dumb auth

user = u’user.%s’ % session[u’authid’]

if stripped_uri == user:

return True

return False

``

And the config looks like this:

{

“controller”: {

},

“workers”: [

  {

     "type": "router",

     "options": {

        "pythonpath": [".."]

     },

     "realms": [

        {

           "name": "realm1",

           "roles": [

              {

                 "name": "authorizer",

                 "permissions": [

                    {

                       "uri": "com.company.product.authorize",

                       "register": true

                    }

                 ]

              },

              {

                 "name": "frontend",

                 "authorizer": "com.company.product.authorize"

              },

              ...

           ]

        }

     ],

     "transports": [

      ...

     ],

     "components": [

        {

           "type": "class",

           "classname": "authorize.InboxUserAuthorization",

           "realm": "realm1",

           "role": "authorizer"

        },

        ...

     ]

  }

]

}

``

This seems to solve my problem - just the question about the secret remains :slight_smile:

Thanks!

···

On Monday, February 16, 2015 at 9:48:26 PM UTC+1, Ben Novakovic wrote:

Hi Alex,

This was very helpful, thank you!

I have implmented a basic version of the ‘private’ channel mode, but I noticed in your documentation you have the secret in cleartext in the javascript - if I am not running over HTTPS, how might I be able to securely achieve this exchange? My cryptography knowledge is a bit rusty - does salting the secret solve this problem, and if so - can you point me to example python/js code to do so. I have seen a couple of places where salting is mentioned, but no clear use cases.

As for the system updates, you mention “have a topic to which all sessions which have been authenticated as role ‘user’ can subscribe”. How can a user have multiple roles? I attempted to set the authrole to a list in python, but this broke the auth handshake. Ideally I would want the perms on the system topic to be ‘subscribe’ only.

Thanks again for your help!

Cheers,

Ben

On Friday, February 13, 2015 at 5:12:00 PM UTC+1, Alexander Gödde wrote:

Hi Ben!

You can have both a custom dynamic authenticator and a dynamic authorizer component. This gives you the possibility to e.g. use the authenticationID as part of your per-user topic, and verify this upon subscription, i.e. allows implementing your suggested flow.

For general updates, you can e.g. have a topic to which all sessions which have been authenticated as role ‘user’ can subscribe (and this can be statically configured). You can have multiple subscriptions on a single WAMP session (and over a single Websocket connection).

Hope this points you in the right direction.

Regards,

Alex

Am Freitag, 13. Februar 2015 15:47:12 UTC+1 schrieb Ben Novakovic:

Hi there,

TL;DR - is it possible to create the concept of a ‘private’ channel with crossbar eg: 1 realm, many topics, 1 user/topic?

We are currently looking at integrating live updates into our tech stack and crossbar.io looks great, except for one small thing that I am unsure about.

We would like each client to have a websocket connection to the server, and receive updates only applicable for that user. This means that a user can’t see any other users updates, even if they know their ‘topic’ name and attempt to connect directly to it.

Essentially a private channel with just the user, and a HTTP-Pusher service pumping updates to the client.

I (think) the way to do this is:

1.) By creating a single realm, and each user must authenticate to connect to this realm using an auth backend

2.) Get the user to create their own topic based on some id unique to them

3.) When the user attempts to connect to this topic, the authorization handler does a check that this user is infact able to subscribe/create to this topic. If the user doesn’t have the correct authorization - ie hashes don’t match for example, they won’t be able to see the topic, this means that a user can only connect to their specific topic.

Does this sound like a possible implementation of the use case?

Moreover, if we want the user to also receive ‘system’ updates, I’m guessing the user can just subscribe to another topic ie: com.system.updates to get global messages whilst maintaining the existing websocket connection?

Thanks for your time!

Any help whatsoever is appreciated.

Cheers,

Ben

0 Likes