What is everybody using for authentication and authorization? I would
Crossbar.io is doing this:
A WAMP client that connects (and authenticates) is assigned a role.
With "static authorization", a client gets permissions based on the realm+role and an URI pattern:
hate to roll my own if there is already something out there. I need a
fairly simple hierarchy of permissions, like root.tenant.device.sensor.
I have come up with a rudimentary idea that I wanted to get some input
on. Topics have the form a.b.c.d which form a hierarchy of sorts from
the left to the right. I makes sense to base the authorization on this
hierarchy. Basically, I'm thinking this:
* top level
* bottom level (arbitrarily deep)
Grants are assigned to a level in the hierarchy. A permission assigned
to level 'a', for example, would also apply to level b, c and d (unless
it is revoked). Grants come from the list:
What is "admin"? There are exactly 4 "atomic WAMP interactions":
call, register, publish, subscribe
Those need to be checked in a router.
Configuring the router authorization scheme is something completely different than the 4 atomic WAMP interactions above ..
So, if I want to subscribe to a.b.c.d, then I would need to have
subscribe permission for that level. Grants are discrete, they can be
assigned one at a time independently. So, if I have subscribe for
a.b.c.d it doesn't mean that I have publish, etc..
Yes, makes sense. Like Crossbar.io does.
There are two 'halves' to this subject. One half is checking the
authorization when the topic/permission is requested. The other half is
granting a permission to someone. For example, if I want to let you
Exactly. Those are completely different things.
subscribe to a.b.c.d I would 'grant' this permission to you. That is,
if I have the permission to do so. That permission is called admin.
Given 'admin' permission I can grant any permission from the grant
list to anyone (at that level or below). So, if I have admin at level
a.b.c, I can grant any permission to anyone at or below c. Maybe not
admin, I am still thinking about that.
I wouldn't mix these. E.g. with Crossbar.io, changing the router authorization configuration (or any other router config) cannot be done from a regular client connection attached to some app realm, but only from admin clients connected to the router's _admin_ realm.
Authorization is checked when the topic is summoned. For call and
publish, it would be checked every time you make a call or a publish.
For subscribe and register the authorization is checked at subscribe
(or register) time (not each time you receive a message).
One other detail, permissions are not granted to users directly, rather,
users can be members of groups, and permissions are granted to groups.
This seemed more practical to me than maintaining permissions for each
This is a "group based" authorization scheme. Crossbar.io implements "role based" authorization. A "user" is assigned a role when authenticated. The _role_ is assigned permissions.
Finally, permissions can be 'granted' or 'revoked' at any level. This
gives a pretty flexible control function.
As far as I understand above, this is close to what Crossbar.io calls "static authorization".
Given a complete URI like "com.example.foo.bar", Crossbar.io will look for the _longest_ matching URI pattern that matches the given URI. It will then apply the permissions configured for that URI pattern.
However, the set of permissions on an URI pattern is always the full set of 4 interactions. That is: there is no inheritance.
Am 23.09.2014 23:04, schrieb Greg Fausak:
You received this message because you are subscribed to the Google
Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to autobahnws+...@googlegroups.com
To post to this group, send email to autob...@googlegroups.com
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.