authorization and topic subscription for individual user notifications best practice

#1

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

0 Likes

#2

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.” as the per user channel, where 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 … :wink: )

0 Likes

#3

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.

0 Likes