I’ve implemented WAMP-CRA for WAMP2:
This example includes a AutobahnJS build from trunk, which also supports
Both Autobahn’s will soon get a new release with official support.
I’ve also implemented:
- Ticket-based authentication
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.
Am 20.06.2014 19:03, schrieb Greg Fausak:
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.
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
On Wednesday, June 11, 2014 3:00:49 PM UTC-5, Tobias Oberstein wrote:
> this is very useful. but, it appears to be a static declaration.
> the 'name' and the uri can be modified or looked up at run time
> could implement permissions based on name. If the configuration
> static definition, every time I add a user name, or modify their
> of uri's they can access, I'd have to 'bounce' the crossbar
The authorization scheme as described above can be configured with
Crossbar either via local configuration file, or via the management
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
> message. Or, I could turn things around and send events to my
> when permissions change, and cache that permission information.
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
- each and every callee site needs to be armored with this
> at subscription time would be very advantageous. this would
> subscribers have permission eliminating the authorization from the
That is yet another approach: upon a new client _connecting_ to
Crossbar, the router might actively call an app provided procedure
returns a dynamic set of permissions:
def my_compute_permissions(realm, authid, authrole):
return [ .. list of permissions .. ]
In the Crossbar config, a reference to "com.myapp.compute_permissions"
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 ..
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
For more options, visit https://groups.google.com/d/optout.