authentication and authorization

[Greg Fausak]

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

[Tobias Oberstein]

Hi Greg,

Am 23.09.2014 23:04, schrieb Greg Fausak:
> 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

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

[Greg Fausak]

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