authentication and authorization

#1

What is everybody using for authentication and authorization? I would 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
  • a
  • b
  • c
  • d
  • 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:

  • call
  • register
  • publish
  • subscribe
  • admin

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…

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 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.

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 person.

Finally, permissions can be ‘granted’ or ‘revoked’ at any level. This gives a pretty flexible control function.

Comments?

-g

0 Likes

#2

Hi Greg,

What is everybody using for authentication and authorization? I would

Crossbar.io is doing this:

http://crossbar.io/docs/Authorization/

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:

"realms": [
    {
       "name": "realm1",
       "roles": [
          {
             "name": "role1",
             "permissions": [
                {
                   "uri": "*",
                   "call": true,
                   "register": false,
                   "subscribe": true,
                   "publish": false
                },
                {
                   "uri": "com.example.frontend.*",
                   "call": true,
                   "register": false
                   "subscribe": true,
                   "publish": true
                }
             ]
          }
       ]
    }
]

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
      o a
      o b
      o c
      o d
  * 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:

  * call
  * register
  * publish
  * subscribe
  * admin

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).

Yes, right.

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
person.

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.

Cheers,
/Tobias

···

Am 23.09.2014 23:04, schrieb Greg Fausak:

Comments?

-g

--
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
<mailto:autobahnws+...@googlegroups.com>.
To post to this group, send email to autob...@googlegroups.com
<mailto:autob...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/autobahnws/9a01d884-41fa-4793-9312-a2cb396fa37a%40googlegroups.com
<https://groups.google.com/d/msgid/autobahnws/9a01d884-41fa-4793-9312-a2cb396fa37a%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#3

I’ve put together an application that runs on AutobahnPython for authentication and authorization. This code works only with postgres (although porting to sqlite or mysql is very straight forward). WARNING, it won’t be useful after 9.3-3 because some of the functionality in AutobahnPython is moving out, but, it might be useful for Crossbar if somebody wants to port it.

This code does two things. 1) it enforces the dynamically maintained authentication / authorization (router part). 2) there is a complete api which manages the user/role/topic authorizations (wamp application part).

Since the wamp application is restricted by the same permissions it enforces it enables delegation and sandboxing of topic space to roles. For example, I could be admin for any topic starting with com., so I could grant someone admin for com.tenant.1234.root, and they would be able to manage permissions on that space (and below). Roles can be granted admin in the same hierarchical manner.

As a side effect sessions are tracked along with all activity inside each session.

It is on pypi, or github.

https://pypi.python.org/pypi?name=sqlauth

https://github.com/lgfausak/sqlauth

-g

···

On Tuesday, September 23, 2014 4:04:42 PM UTC-5, Greg Fausak wrote:

What is everybody using for authentication and authorization? I would 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
  • a
  • b
  • c
  • d
  • 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:

  • call
  • register
  • publish
  • subscribe
  • admin

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…

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 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.

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 person.

Finally, permissions can be ‘granted’ or ‘revoked’ at any level. This gives a pretty flexible control function.

Comments?

-g

0 Likes