communicating with different realms

#1

I have a multi-tenant web application server serving customers that each also have a remote on-premise server. The web app & on-premise servers communicates using WAMP via a router running somewhere. To isolate customers from one another, there’d be a realm per customer.

I guess it is possible to build a WAMP “megaclient” that instantiates a component per customer / realm. Is that how it should be done? But does that mean also a separate connection per customer to the router? Is there any way to multiplex the connections over a single (say, websocket) transport, so that a single connection would suffice?

Seems there’s a IETF draft for websocket multiplexing: https://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11.

0 Likes

#2

Hi,

the WebSocket multiplexing spec didn’t went anywhere (it is not finished, not implemented anywhere (but lab impl) to my knowledge).

We’ve had discussion about adding a multiplexed WAMP transport (at the WAMP level), but this isn’t finished either.

So as it stands today, you will need multiple connections if you want to connect to multiple realms.

And yes: if you use realms for tenants, having 1 backend component per realm is the recommended pattern (we use that in our apps) - this also helps with really separating tenants (otherwise, you’d need to be very careful not to leak info or break tenant separation).

Hope that helps,
Cheers,
/Tobias

···

Am Freitag, 7. Oktober 2016 23:03:23 UTC+2 schrieb pe...@koodaamo.fi:

I have a multi-tenant web application server serving customers that each also have a remote on-premise server. The web app & on-premise servers communicates using WAMP via a router running somewhere. To isolate customers from one another, there’d be a realm per customer.

I guess it is possible to build a WAMP “megaclient” that instantiates a component per customer / realm. Is that how it should be done? But does that mean also a separate connection per customer to the router? Is there any way to multiplex the connections over a single (say, websocket) transport, so that a single connection would suffice?

Seems there’s a IETF draft for websocket multiplexing: https://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11.

0 Likes

#3

Thank you Tobias.

perjantai 11. marraskuuta 2016 11.07.43 UTC+2 Tobias Oberstein kirjoitti:

···

Hi,

the WebSocket multiplexing spec didn’t went anywhere (it is not finished, not implemented anywhere (but lab impl) to my knowledge).

We’ve had discussion about adding a multiplexed WAMP transport (at the WAMP level), but this isn’t finished either.

So as it stands today, you will need multiple connections if you want to connect to multiple realms.

And yes: if you use realms for tenants, having 1 backend component per realm is the recommended pattern (we use that in our apps) - this also helps with really separating tenants (otherwise, you’d need to be very careful not to leak info or break tenant separation).

Hope that helps,
Cheers,
/Tobias

Am Freitag, 7. Oktober 2016 23:03:23 UTC+2 schrieb pe...@koodaamo.fi:

I have a multi-tenant web application server serving customers that each also have a remote on-premise server. The web app & on-premise servers communicates using WAMP via a router running somewhere. To isolate customers from one another, there’d be a realm per customer.

I guess it is possible to build a WAMP “megaclient” that instantiates a component per customer / realm. Is that how it should be done? But does that mean also a separate connection per customer to the router? Is there any way to multiplex the connections over a single (say, websocket) transport, so that a single connection would suffice?

Seems there’s a IETF draft for websocket multiplexing: https://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11.

0 Likes

#4

Hi, just as a matter of interest, is there something that using “realms” gives you in terms of security that could not be achieved using a custom authenticator and custom authorizer ?

… I use a multi-tenant model which involves tagging each user to a customer id in the user db, so when someone authenticates, it stores (effectively) a ‘soft’ realm in the form of a customer id against the connection (i.e. connection metadata). The same comment would hold with regards to being careful about security and leakage, but essentially is this the same functionality as you would get from using different realms ??

0 Likes

#5

I believe WAMP routing of events and RPC is per realm, is it not? We have (lots of) various per-customer events and services that components register that should only be accessible for that customer. Building access restriction specifically into all the components etc. would be a lot more effort than relying on per-customer realms, AFAIK.

lauantai 12. marraskuuta 2016 2.27.59 UTC+2 Gareth Bult kirjoitti:

···

Hi, just as a matter of interest, is there something that using “realms” gives you in terms of security that could not be achieved using a custom authenticator and custom authorizer ?

… I use a multi-tenant model which involves tagging each user to a customer id in the user db, so when someone authenticates, it stores (effectively) a ‘soft’ realm in the form of a customer id against the connection (i.e. connection metadata). The same comment would hold with regards to being careful about security and leakage, but essentially is this the same functionality as you would get from using different realms ??

0 Likes

#6

Ahh, Ok, I think I see what you’re doing.

The alternative approach is to treat each customer as a ‘group’ rather than as a routing domain, then route messages per group. This works well for Internet based applications where one user may belong to more than one group and may want to be a member of and/or manage more than one group at any given time. Maybe not useful to you right now, but might be something to bear in mind … I guess the main difference would be that instead of pub/sub on a fixed topic, you make the topic dynamic, so for example instead of publishing to ‘com.message.all’, it might become ‘com.message.’, then instead of subscribing to ‘com.message.all’ within a specific domain, you would all run on the same domain and subscribe to ‘com.message.’.

(so technically, routing is per topic, whereas realms are a form of ‘hard’ partitioning)

In practice I also employ a decorator against each registration that checks the caller has access to the data they are requesting based on a simple group membership test. Whereas it may sound ‘bulky’, I’ve been using this approach for years and have a number of live applications out in the wild and it works very well. For me the real ‘killer’ feature is that in context, you don’t need to change your config for a new ‘customer’, it’s just a new group record in a database.

0 Likes