authorization and topic subscription for individual user notifications best practice

[sieben tupel]

Hi,

are there any best practice policies or advice on the following situation:

In an application each user needs his private channel for incoming notifications. In all those channels new messages may be published by a set of services provided by the backend which has its own role (or set of roles). Publishing to those channels can easily be restricted using the authentication role of the backend services and a dynamic authentication/authorization mechanism.

Now, what would be the best way to restrict the users to be able to subscribe only to their own channel, assuming all users have the same authentication role (e.g. 'user')? Right now i can think of the following

1. Create a channel with random name for each user, e.g. 'com.myapp.notifications.<random_string>'. Each user can access all channels by the access restrictions set by the authorization service, but a user knows only his own channel. Using brute force to subscribe to other channels is very difficult because of the big namespace (assuming the string is long and random). Personally i don't like this approach very much as it does not give real security because it highly depends on trial and error.

Can you recommend another way how to realize this in a safe way?

cheers sieben

[Gareth Bult]

Hi, well (!) I do it something like this, first set up an authorizer in config.json;

"roles": [
 { "name": "client", "authorizer":"ionman.security.authorize" }
]


Then I add a wrapper function;

@wamp.register(u'ionman.security.authorize')
    def security_authorize(self,session, uri, action):
        """ authorize wrapper """
        try:
            return self.on_security_authorize(session,uri,action)
        except Exception as e:
            log.err()


Then I'm free to implement whatever controls I want, this example (untested, but based on working code) would assume that you use "ionman.personal.<identifier>" as the per user channel, where <identifier> is the '_id' database field of each user to ensure uniqueness .. this would prevent anyone other than the user from connecting to "their" channel.

    def on_security_authorize(self,session, uri, action):
        # Just subscribe for now ...
        if action != 'subscribe': return True
        parts = uri.split('.')
        #   And we're only letting in our REALM
        if parts[0] != 'ionman': return False
        #   Just interested in personal subscriptions for now ..
        if parts[1] != 'personal': return True
        #
        authid = session.get('authid',None)
        user_record = mongo.ionman.users.find_one({'authid':authid})
        if not user_record: return False

        if parts[2] <> str(user_record['_id']): return False

        return True

I implement this as a crossbar component and sit it in the same code block as my custom authenticator code ...

(never assume someone somewhere somewhen won't try to brute force your system ... ;)  )

[Tobias Oberstein]

Hi,

you could have URIs like

com.myapp.notifications.<authid>

plus a dynamic authorizer that checks the URI being subscribed/published
to versus the authid of the session doing so, when authrole=user, and
always allows when authrole=backend.

Cheers,
/Tobias

Am 30.01.2016 um 18:09 schrieb sieben tupel:
> Hi,
>
> are there any best practice policies or advice on the following situation:
>
> In an application each user needs his private channel for incoming
> notifications. In all those channels new messages may be published by a
> set of services provided by the backend which has its own role (or set
> of roles). Publishing to those channels can easily be restricted using
> the authentication role of the backend services and a dynamic
> authentication/authorization mechanism.
> Now, what would be the best way to restrict the users to be able to
> subscribe only to their own channel, assuming all users have the same
> authentication role (e.g. 'user')? Right now i can think of the following
>

> 1. Create a channel with random name for each user, e.g.

> 'com.myapp.notifications.<random_string>'. Each user can access all
> channels by the access restrictions set by the authorization
> service, but a user knows only his own channel. Using brute force to
> subscribe to other channels is very difficult because of the big
> namespace (assuming the string is long and random). Personally i
> don't like this approach very much as it does not give real security
> because it highly depends on trial and error.
>
>
> Can you recommend another way how to realize this in a safe way?
>
> cheers sieben
>

> --
> You received this message because you are subscribed to the Google
> Groups "Crossbar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crossbario+...@googlegroups.com
> <mailto:crossbario+...@googlegroups.com>.
> To post to this group, send email to cross...@googlegroups.com
> <mailto:cross...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crossbario/71d3877a-c7aa-4f8b-8c15-c61b6f664c7a%40googlegroups.com
> <https://groups.google.com/d/msgid/crossbario/71d3877a-c7aa-4f8b-8c15-c61b6f664c7a%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.