v1 to v2 migration

#1

I am thinking about migrating my Autobahn application from v1 to v2. I have been looking at examples and documentation and I have a few questions about v2 functionality.

  1. In general, it appears that the addressing scheme for the subscriptions and rpcs are not compatible. We have :

http://mydomain.com/subscribe.to.this

and

pubsub.subscribe.to.this

So, that feels like a string substitution through my code base. No big deal.

  1. wampcra authentication. I think that is an advanced feature and not available in the basic router. Is it possible to use the wampcra code I wrote in v1 in v2? I have been looking at the mozilla persona stuff, I don’t think I can go that route. In the old v1 code I subclassed a class: WampCraServerProtocol. Is there a path I can take to get similar functionality on v2?

  2. My code implements an ‘internet of things’. I have many devices at the edges, and browsers that have relationships with those devices (like, for example, a garage door sensor and opener). My code maintains a relationship between a user and the internet of things they can subscribe / rpc to. The way I’ve implemented the publication/subscription is when an event comes in from a device, I search through the current logged in users that have a relationship with the device, then I direct publication of the event only to those user sessions that are related. In v2 can I also do the same thing? That is, can I direct a publish to specific wamp sessions? I don’t see the ability to pass the destination array. Perhaps a better way to do this would be to embed the endpoint in the topic itself, like pubsub.1234mainstreet.garagedoor and control the subscription to the endpoint?

-g

0 Likes

#2

Hi Greg,

I am thinking about migrating my Autobahn application from v1 to v2. I
have been looking at examples and documentation and I have a few
questions about v2 functionality.

1) In general, it appears that the addressing scheme for the
subscriptions and rpcs are not compatible. We have :

http://mydomain.com/subscribe.to.this

and

pubsub.subscribe.to.this

So, that feels like a string substitution through my code base. No big
deal.

Yes, some string substitution should work for this.

(The old URI scheme with "http" in it just triggered too much confusion.)

A recommended translation would be something like:

old: http://example.com/myapp/myproc
new: com.example.myapp.myproc

2) wampcra authentication. I think that is an advanced feature and not
available in the basic router. Is it possible to use the wampcra code I
wrote in v1 in v2? I have been looking at the mozilla persona stuff, I
don't think I can go that route. In the old v1 code I subclassed a
class: WampCraServerProtocol. Is there a path I can take to get similar
functionality on v2?

WAMP-CRA will be in Crossbar also of course. The relevant issue is

https://github.com/crossbario/crossbar/issues/12

It "just" needs to be done. Once it is, you should be able to reuse your code mostly unmodified: there will be hooks ApplicationSession that you override.

3) My code implements an 'internet of things'. I have many devices at
the edges, and browsers that have relationships with those devices
(like, for example, a garage door sensor and opener). My code maintains
a relationship between a user and the internet of things they can
subscribe / rpc to. The way I've implemented the
publication/subscription is when an event comes in from a device, I
search through the current logged in users that have a relationship with
the device, then I direct publication of the event only to those user
sessions that are related. In v2 can I also do the same thing? That is,
can I direct a publish to specific wamp sessions? I don't see the

Yes, of course all the exclude/eligible facilities are available.

from autobahn.wamp.types import PublishOptions

self.publish('com.myapp.topic1', 'hello',
    options = PublishOptions(eligible = [.. list of WAMP session IDs eligible for receiving ..]))

ability to pass the destination array. Perhaps a better way to do this
would be to embed the endpoint in the topic itself, like
pubsub.1234mainstreet.garagedoor and control the subscription to the
endpoint?

In general, yes. That is better, since it doesn't move routing logic into app code (which is in a way what exclude/eligible does).

You might have a persistent naming for your sensors, e.g.

com.example.myapp.door.1
com.example.myapp.door.2

and then have

com.example.myapp.door.1.onopen
com.example.myapp.door.1.onclose
com.example.myapp.door.2.onopen
com.example.myapp.door.2.onclose
...

A subscriber then would subscribe to only entities ("doors") and/or event ("onclose"/"onopen") it is interested in.

Similar, you might then have endpoints for procedures like:

com.example.myapp.light.7.set_brightness

Cheers,
/Tobias

···

Am 09.06.2014 18:32, schrieb Greg Fausak:

-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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#3

Hi Greg,

snip…

  1. My code implements an ‘internet of things’. I have many devices at

the edges, and browsers that have relationships with those devices

(like, for example, a garage door sensor and opener). My code maintains

a relationship between a user and the internet of things they can

subscribe / rpc to. The way I’ve implemented the

publication/subscription is when an event comes in from a device, I

search through the current logged in users that have a relationship with

the device, then I direct publication of the event only to those user

sessions that are related. In v2 can I also do the same thing? That is,

can I direct a publish to specific wamp sessions? I don’t see the

Yes, of course all the exclude/eligible facilities are available.

from autobahn.wamp.types import PublishOptions

self.publish(‘com.myapp.topic1’, ‘hello’,

options = PublishOptions(eligible = [.. list of WAMP session IDs

eligible for receiving …]))

ability to pass the destination array. Perhaps a better way to do this

would be to embed the endpoint in the topic itself, like

pubsub.1234mainstreet.garagedoor and control the subscription to the

endpoint?

In general, yes. That is better, since it doesn’t move routing logic
into app code (which is in a way what exclude/eligible does).

You might have a persistent naming for your sensors, e.g.

com.example.myapp.door.1

com.example.myapp.door.2

and then have

com.example.myapp.door.1.onopen

com.example.myapp.door.1.onclose

com.example.myapp.door.2.onopen

com.example.myapp.door.2.onclose

A subscriber then would subscribe to only entities (“doors”) and/or
event (“onclose”/“onopen”) it is interested in.

Similar, you might then have endpoints for procedures like:

com.example.myapp.light.7.set_brightness

Tobias,

Thank you for the reply. I really like this architecture. It would require some sort of authentication during subscription, right? I wouldn’t want to be able to control my neighbors garage door. How would you envision authorization using a scheme like this? Can I require a unique role for each endpoint, and specific authorization for role/endpoint relationship? Or perhaps each endpoint has it’s own Router with it’s own authentication? Can Routers be hooked to Routers?

-g

···

On Tuesday, June 10, 2014 9:40:24 AM UTC-5, Tobias Oberstein wrote:

Cheers,

/Tobias

-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+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#4

Thank you for the reply. I really like this architecture. It would
require some sort of authentication during subscription, right? I
wouldn't want to be able to control my neighbors garage door. How would
you envision authorization using a scheme like this? Can I require a

The goal is to have Crossbar provide both builtin machinery as well as hooks for authentication and authorization.

E.g.: an authorization scheme that works via URI-matching permissions (allowed to publish on that URI, allowed to register stuff under the URI, ..)

have a look at the following part of a Crossbar config:

          "realms": [
             {
                "name": "realm1",
                "roles": [
                   {
                      "name": "anonymous",
                      "permissions": [
                         {
                            "uri": "*",
                            "publish": true,
                            "subscribe": true,
                            "call": true,
                            "register": true
                         }
                      ]
                   }
                ]
             }
          ],

This configures the permissions for role "anonymous" on "realm1":

allowed to publish, subscribe, call and register any URI.

[here, `uri: "*"` is a pattern that machtes "any URI".]

But that could be a specific URI as well, or a different URI pattern.

The flags indicate the permissions a client connected to the given realm and under the respective role will get by Crossbar.

Now, above scheme probably works in a lot of scenarios, but not all. And for that, the hook builtin works like this:

When you register a procedure, an app component can ask to be forwarded the caller's details whenever it is invoked.

The caller details include the authentication information determined during WAMP opening handshake:

- auth. role
- auth. ID

as well as WAMP session ID of the caller.

What the app code registered now can do while it is being invoked: it can enforce whatever authorization scheme it likes to implement:

"call only allowed on wednesdays after 12 pm?"
"call only allowed if caller 'owns' the object being modified"
etc

Of course both URI-matching in custom authorization schemes can be combined.

unique role for each endpoint, and specific authorization for
role/endpoint relationship? Or perhaps each endpoint has it's own

A client authenticates on a router instance, at a specific realm. When it does so, this will result in an authentication ID and authentication role being assigned to this client (session). Now, the pair of realm and role (on a router configuration) determines the list of permissions.

Router with it's own authentication? Can Routers be hooked to Routers?

Router-to-Router communication, with all routers being federated into a virtual one, is a mid-term goal. This is a non-trivial thing, but of course highly desirable ..

/Tobias

···

-g

    Cheers,
    /Tobias

     >
     > -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 autobah...@googlegroups.com <javascript:>
     > <mailto:autobahnws+...@googlegroups.com <javascript:>>.
     > For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.

--
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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#5

Thank you for the reply. I really like this architecture. It would

require some sort of authentication during subscription, right? I

wouldn’t want to be able to control my neighbors garage door. How would

you envision authorization using a scheme like this? Can I require a

The goal is to have Crossbar provide both builtin machinery as well as
hooks for authentication and authorization.

E.g.: an authorization scheme that works via URI-matching permissions
(allowed to publish on that URI, allowed to register stuff under the
URI, …)

have a look at the following part of a Crossbar config:

      "realms": [

         {

            "name": "realm1",

            "roles": [

               {

                  "name": "anonymous",

                  "permissions": [

                     {

                        "uri": "*",

                        "publish": true,

                        "subscribe": true,

                        "call": true,

                        "register": true

                     }

                  ]

               }

            ]

         }

      ],

This configures the permissions for role “anonymous” on “realm1”:

allowed to publish, subscribe, call and register any URI.

[here, uri: "*" is a pattern that machtes “any URI”.]

But that could be a specific URI as well, or a different URI pattern.

The flags indicate the permissions a client connected to the given realm
and under the respective role will get by Crossbar.

this is very useful. but, it appears to be a static declaration. if the ‘name’ and the uri can be modified or looked up at run time then i could implement permissions based on name. If the configuration is a static definition, every time I add a user name, or modify their ‘scope’ of uri’s they can access, I’d have to ‘bounce’ the crossbar server. Of these two solutions, I think this would be more efficient.

Now, above scheme probably works in a lot of scenarios, but not all. And
for that, the hook builtin works like this:

When you register a procedure, an app component can ask to be forwarded
the caller’s details whenever it is invoked.

The caller details include the authentication information determined
during WAMP opening handshake:

  • auth. role

  • auth. ID

as well as WAMP session ID of the caller.

What the app code registered now can do while it is being invoked: it
can enforce whatever authorization scheme it likes to implement:

“call only allowed on wednesdays after 12 pm?”

“call only allowed if caller ‘owns’ the object being modified”

etc

Of course both URI-matching in custom authorization schemes can be combined.

there is the rub. “allowed if caller ‘owns’” requires an rpc call per message. Or, I could turn things around and send events to my devices when permissions change, and cache that permission information. a hook at subscription time would be very advantageous. this would ensure that subscribers have permission eliminating the authorization from the publication.

···

On Tuesday, June 10, 2014 1:08:04 PM UTC-5, Tobias Oberstein wrote:

unique role for each endpoint, and specific authorization for

role/endpoint relationship? Or perhaps each endpoint has it’s own

A client authenticates on a router instance, at a specific realm. When
it does so, this will result in an authentication ID and authentication
role being assigned to this client (session). Now, the pair of realm and
role (on a router configuration) determines the list of permissions.

Router with it’s own authentication? Can Routers be hooked to Routers?

Router-to-Router communication, with all routers being federated into a
virtual one, is a mid-term goal. This is a non-trivial thing, but of
course highly desirable …

/Tobias

-g

Cheers,
/Tobias
 >
 >
 > -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 <javascript:>
 > <mailto:autobahnws+unsub...@googlegroups.com <javascript:>>.
 > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout)
<[https://groups.google.com/d/optout](https://groups.google.com/d/optout)>.

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+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#6

Hi Greg,

<snip>

this is very useful. but, it appears to be a static declaration. if
the 'name' and the uri can be modified or looked up at run time then i
could implement permissions based on name. If the configuration is a
static definition, every time I add a user name, or modify their 'scope'
of uri's they can access, I'd have to 'bounce' the crossbar server. Of

The authorization scheme as described above can be configured with Crossbar either via local configuration file, or via the management API.

So in principle it can be changed at run-time and dynamically.

However, currently, I'm not sure it's a good idea in the long run to dynamically modify Crossbar configuration from regular application code via the management API (but see below).

The question remains: what if the URIs contain "entity names" and permissions on URI should depend "auth ID/role" in relation to "entity names". Hence no static rules.

<snip>

there is the rub. "allowed if caller 'owns'" requires an rpc call per
message. Or, I could turn things around and send events to my devices
when permissions change, and cache that permission information. a hook

Yes. Enforcing app authorization rules at the callee site is the most flexible, but comes at a price:

- if the "determine if authorized" code needs to go remote itself, caching of the relevant authorization info might be appropriate/required
- each and every callee site needs to be armored with this authorization enforcing code

at subscription time would be very advantageous. this would ensure that
subscribers have permission eliminating the authorization from the
publication.

That is yet another approach: upon a new client _connecting_ to Crossbar, the router might actively call an app provided procedure which returns a dynamic set of permissions:

@register("com.myapp.compute_permissions")
def my_compute_permissions(realm, authid, authrole):
    return [ .. list of permissions .. ]

In the Crossbar config, a reference to "com.myapp.compute_permissions" is made.

Depending on configuration, Crossbar might be allowed or not to cache the list of permissions per (realm, authid, authrole) triple.

I am in favor of such a third option for authorization - in this case, since authorization (and authentication) are complex features with requirements varying broadly between apps.

Above still leaves questions unanswered: can an app actively change the permissions (not only when being asked)? Change permissions of a client while the client is connected?

Mmh. This needs more discussing and thinking ..

Cheers,
/Tobias

0 Likes

#7

Tobias,

I have implemented ticket based authentication that works well for my need of establishing an authorized session. It required modifications to both authbahnpython and autobahnjs. I modeled it after the persona example in wamp/auth. The onHello returns a Challenge(“ticket”), is that an acceptable name for it? Also, what do you intend to name the wamp-cra challenge? Then, in the onAuthenticate callback I simply do a query to validate the ticket (this is using txpostgres async twisted queries). But I imagine that everyone’s ticket will be different, so the best that I can do is an example.

On the javascript side I implemented the other auth type. The ticket.auth() function simply provides the ‘clear text’ ticket, which is what the python side looks up.

The txpostgres driver doesn’t feel right in the ab python code base. I can produce the ticket code without a db lookup as an example (do a hard coded ticket string match), and leave the db stuff out.

Seems to work as it should. I am a little worried about maintaining it outside the scope of ab python/js. is this something I can contribute to those code bases as examples? The problem is that even though it is an ‘example’ on the python side, the javascript side needs a slot for it.

thank you,

-g

···

On Wednesday, June 11, 2014 3:00:49 PM UTC-5, Tobias Oberstein wrote:

Hi Greg,

this is very useful. but, it appears to be a static declaration. if

the ‘name’ and the uri can be modified or looked up at run time then i

could implement permissions based on name. If the configuration is a

static definition, every time I add a user name, or modify their ‘scope’

of uri’s they can access, I’d have to ‘bounce’ the crossbar server. Of

The authorization scheme as described above can be configured with
Crossbar either via local configuration file, or via the management API.

So in principle it can be changed at run-time and dynamically.

However, currently, I’m not sure it’s a good idea in the long run to
dynamically modify Crossbar configuration from regular application code
via the management API (but see below).

The question remains: what if the URIs contain “entity names” and
permissions on URI should depend “auth ID/role” in relation to “entity
names”. Hence no static rules.

there is the rub. “allowed if caller ‘owns’” requires an rpc call per

message. Or, I could turn things around and send events to my devices

when permissions change, and cache that permission information. a hook

Yes. Enforcing app authorization rules at the callee site is the most
flexible, but comes at a price:

  • if the “determine if authorized” code needs to go remote itself,
    caching of the relevant authorization info might be appropriate/required

  • each and every callee site needs to be armored with this authorization
    enforcing code

at subscription time would be very advantageous. this would ensure that

subscribers have permission eliminating the authorization from the

publication.

That is yet another approach: upon a new client connecting to
Crossbar, the router might actively call an app provided procedure which
returns a dynamic set of permissions:

@register(“com.myapp.compute_permissions”)

def my_compute_permissions(realm, authid, authrole):

return [ .. list of permissions .. ]

In the Crossbar config, a reference to “com.myapp.compute_permissions”
is made.

Depending on configuration, Crossbar might be allowed or not to cache
the list of permissions per (realm, authid, authrole) triple.

I am in favor of such a third option for authorization - in this case,
since authorization (and authentication) are complex features with
requirements varying broadly between apps.

Above still leaves questions unanswered: can an app actively change the
permissions (not only when being asked)? Change permissions of a client
while the client is connected?

Mmh. This needs more discussing and thinking …

Cheers,

/Tobias

0 Likes

#8

Hi Greg,

I've implemented WAMP-CRA for WAMP2:

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/wamp/auth/wampcra

This example includes a AutobahnJS build from trunk, which also supports WAMP-CRA.

Both Autobahn's will soon get a new release with official support.

I've also implemented:

- Ticket-based authentication

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/wamp/auth/ticket

- One Time Password (TOTP)

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/wamp/auth/otp

The latter can be used with Google Authenticator.

What's missing is WAMP-CRA-TOTP, which would provide 2 factor authentication for WAMP.

I'd like to finish that and then do the release. But if you want to experiment, that's possible from trunk.

Cheers,
/Tobias

···

Am 20.06.2014 19:03, schrieb Greg Fausak:

Tobias,

I have implemented ticket based authentication that works well for my
need of establishing an authorized session. It required modifications
to both authbahnpython and autobahnjs. I modeled it after the persona
example in wamp/auth. The onHello returns a Challenge("ticket"), is that
an acceptable name for it? Also, what do you intend to name the
wamp-cra challenge? Then, in the onAuthenticate callback I simply do a
query to validate the ticket (this is using txpostgres async twisted
queries). But I imagine that everyone's ticket will be different, so the
best that I can do is an example.

On the javascript side I implemented the other auth type. The
ticket.auth() function simply provides the 'clear text' ticket, which is
what the python side looks up.

The txpostgres driver doesn't feel right in the ab python code base. I
can produce the ticket code without a db lookup as an example (do a hard
coded ticket string match), and leave the db stuff out.

Seems to work as it should. I am a little worried about maintaining it
outside the scope of ab python/js. is this something I can contribute
to those code bases as examples? The problem is that even though it is
an 'example' on the python side, the javascript side needs a slot for it.

thank you,

-g

On Wednesday, June 11, 2014 3:00:49 PM UTC-5, Tobias Oberstein wrote:

    Hi Greg,

    <snip>

     > this is very useful. but, it appears to be a static declaration.
      if
     > the 'name' and the uri can be modified or looked up at run time
    then i
     > could implement permissions based on name. If the configuration
    is a
     > static definition, every time I add a user name, or modify their
    'scope'
     > of uri's they can access, I'd have to 'bounce' the crossbar
    server. Of

    The authorization scheme as described above can be configured with
    Crossbar either via local configuration file, or via the management
    API.

    So in principle it can be changed at run-time and dynamically.

    However, currently, I'm not sure it's a good idea in the long run to
    dynamically modify Crossbar configuration from regular application code
    via the management API (but see below).

    The question remains: what if the URIs contain "entity names" and
    permissions on URI should depend "auth ID/role" in relation to "entity
    names". Hence no static rules.

    <snip>

     > there is the rub. "allowed if caller 'owns'" requires an rpc
    call per
     > message. Or, I could turn things around and send events to my
    devices
     > when permissions change, and cache that permission information.
      a hook

    Yes. Enforcing app authorization rules at the callee site is the most
    flexible, but comes at a price:

    - if the "determine if authorized" code needs to go remote itself,
    caching of the relevant authorization info might be
    appropriate/required
    - each and every callee site needs to be armored with this
    authorization
    enforcing code

     > at subscription time would be very advantageous. this would
    ensure that
     > subscribers have permission eliminating the authorization from the
     > publication.

    That is yet another approach: upon a new client _connecting_ to
    Crossbar, the router might actively call an app provided procedure
    which
    returns a dynamic set of permissions:

    @register("com.myapp.compute_permissions")
    def my_compute_permissions(realm, authid, authrole):
         return [ .. list of permissions .. ]

    In the Crossbar config, a reference to "com.myapp.compute_permissions"
    is made.

    Depending on configuration, Crossbar might be allowed or not to cache
    the list of permissions per (realm, authid, authrole) triple.

    I am in favor of such a third option for authorization - in this case,
    since authorization (and authentication) are complex features with
    requirements varying broadly between apps.

    Above still leaves questions unanswered: can an app actively change the
    permissions (not only when being asked)? Change permissions of a client
    while the client is connected?

    Mmh. This needs more discussing and thinking ..

    Cheers,
    /Tobias

--
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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#9

Looks great! I am going to give it a try first thing in the morning. Thanks Tobias,
-g

···

On Sunday, June 22, 2014 6:20:02 PM UTC-5, Tobias Oberstein wrote:

Hi Greg,

I’ve implemented WAMP-CRA for WAMP2:

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/wamp/auth/wampcra

This example includes a AutobahnJS build from trunk, which also supports
WAMP-CRA.

Both Autobahn’s will soon get a new release with official support.

I’ve also implemented:

  • Ticket-based authentication

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/wamp/auth/ticket

  • One Time Password (TOTP)

https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/wamp/auth/otp

The latter can be used with Google Authenticator.

What’s missing is WAMP-CRA-TOTP, which would provide 2 factor
authentication for WAMP.

I’d like to finish that and then do the release. But if you want to
experiment, that’s possible from trunk.

Cheers,

/Tobias

Am 20.06.2014 19:03, schrieb Greg Fausak:

Tobias,

I have implemented ticket based authentication that works well for my

need of establishing an authorized session. It required modifications

to both authbahnpython and autobahnjs. I modeled it after the persona

example in wamp/auth. The onHello returns a Challenge(“ticket”), is that

an acceptable name for it? Also, what do you intend to name the

wamp-cra challenge? Then, in the onAuthenticate callback I simply do a

query to validate the ticket (this is using txpostgres async twisted

queries). But I imagine that everyone’s ticket will be different, so the

best that I can do is an example.

On the javascript side I implemented the other auth type. The

ticket.auth() function simply provides the ‘clear text’ ticket, which is

what the python side looks up.

The txpostgres driver doesn’t feel right in the ab python code base. I

can produce the ticket code without a db lookup as an example (do a hard

coded ticket string match), and leave the db stuff out.

Seems to work as it should. I am a little worried about maintaining it

outside the scope of ab python/js. is this something I can contribute

to those code bases as examples? The problem is that even though it is

an ‘example’ on the python side, the javascript side needs a slot for it.

thank you,

-g

On Wednesday, June 11, 2014 3:00:49 PM UTC-5, Tobias Oberstein wrote:

Hi Greg,
<snip>
 > this is very useful.  but, it appears to be a static declaration.
  if
 > the 'name' and the uri can be modified or looked up at run time
then i
 > could implement permissions based on name.  If the configuration
is a
 > static definition, every time I add a user name, or modify their
'scope'
 > of uri's they can access, I'd have to 'bounce' the crossbar
server.  Of
The authorization scheme as described above can be configured with
Crossbar either via local configuration file, or via the management
API.
So in principle it can be changed at run-time and dynamically.
However, currently, I'm not sure it's a good idea in the long run to
dynamically modify Crossbar configuration from regular application code
via the management API (but see below).
The question remains: what if the URIs contain "entity names" and
permissions on URI should depend "auth ID/role" in relation to "entity
names". Hence no static rules.
<snip>
 > there is the rub.  "allowed if caller 'owns'" requires an rpc
call per
 > message.  Or, I could turn things around and send events to my
devices
 > when permissions change, and cache that permission information.
  a hook
Yes. Enforcing app authorization rules at the callee site is the most
flexible, but comes at a price:
- if the "determine if authorized" code needs to go remote itself,
caching of the relevant authorization info might be
appropriate/required
- each and every callee site needs to be armored with this
authorization
enforcing code
 > at subscription time would be very advantageous.  this would
ensure that
 > subscribers have permission eliminating the authorization from the
 > publication.
That is yet another approach: upon a new client _connecting_ to
Crossbar, the router might actively call an app provided procedure
which
returns a dynamic set of permissions:
@register("com.myapp.compute_permissions")
def my_compute_permissions(realm, authid, authrole):
     return [ .. list of permissions .. ]
In the Crossbar config, a reference to "com.myapp.compute_permissions"
is made.
Depending on configuration, Crossbar might be allowed or not to cache
the list of permissions per (realm, authid, authrole) triple.
I am in favor of such a third option for authorization - in this case,
since authorization (and authentication) are complex features with
requirements varying broadly between apps.
Above still leaves questions unanswered: can an app actively change the
permissions (not only when being asked)? Change permissions of a client
while the client is connected?
Mmh. This needs more discussing and thinking ..
Cheers,
/Tobias

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+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

0 Likes