Autobahnjs / Crossbar PubSub Authorization

#1

Hi,

I have a subscribing client (browser with Autobahnjs) and publishing server (node with Autobahnjs), connected via Crossbar.

If I understand properly neither the client or server have any knowledge of each other. Crossbar handles the subscription from the client and routes publications from the server.

So if I have multiple clients, and want to make sure that they can only subscribe to authorized topics what are the options? I guess:

A. Authorization somehow handled by crossbar - this page seems a little light:

https://github.com/crossbario/crossbar/wiki/Authorization

or

B. Intially some RPC call from client to server with authentication and authorization in the server code, resulting in an agreed (via the RPC call) new pubsub topic (some crypto to generate some randomness). Seems a little hokey as there is still nothing to stop another client from subscribing if they figured out / guessed

or

C. I’ve completely misunderstood / missed something obvious.

By the way I have to say that I’m very impressed with Crossbar and the Autobahnjs components so far - I’ve been following with interest the various discussions on “real use” stories and examples.

Personally I’m trying to use them together with Reactjs and a back end graph database (Titan with its interface exposed through Rexster). If I get through it all I hope I can help contribute :wink:

0 Likes

#2

Hi Mike,

Hi,

I have a subscribing client (browser with Autobahnjs) and publishing
server (node with Autobahnjs), connected via Crossbar.

If I understand properly neither the client or server have any knowledge
of each other. Crossbar handles the subscription from the client and
routes publications from the server.

Exactly.

So if I have multiple clients, and want to make sure that they can only
subscribe to authorized topics what are the options? I guess:

A. Authorization somehow handled by crossbar - this page seems a little
light:
https://github.com/crossbario/crossbar/wiki/Authorization

Yes;) The reason is: it's not there yet. Once it is, the permissions as e.g. here

https://github.com/crossbario/crossbar/blob/master/crossbar/crossbar/templates/hello/python/.crossbar/config.json#L18

in a Crossbar configuration will control if a client is allowed to subscribe to a specific topic, publish to a specific topic, call a specific procedure and register a specific procedure. Either via literal URI match or URI pattern match.

or

B. Intially some RPC call from client to server with authentication and
authorization in the server code, resulting in an agreed (via the RPC
call) new pubsub topic (some crypto to generate some randomness). Seems
a little hokey as there is still nothing to stop another client from
subscribing if they figured out / guessed

I wouldn't recommend such a scheme. The natural place to enforce authorization is the router. The router is the one actually doing the call and event routing, and it is hence the right place to put restrictions regarding routing into effect.

The goal with Crossbar is to have above, simple yet flexible authorization scheme from configuration "good enough" for most cases.

or

C. I've completely misunderstood / missed something obvious.

No, it seems you have a good grasp of this stuff already.

By the way I have to say that I'm very impressed with Crossbar and the
Autobahnjs components so far - I've been following with interest the
various discussions on "real use" stories and examples.

Great! Thanks. pls spread the word ..

Personally I'm trying to use them together with Reactjs and a back end
graph database (Titan with its interface exposed through Rexster). If I
get through it all I hope I can help contribute :wink:

Awesome, we need more hands. Also PR ..

Please keep us updated on your project and of course issues you encounter with Crossbar.

Cheers,
/Tobias

···

Am 23.06.2014 17:32, schrieb Mike Raistrick:

--
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 Tobias,
thanks for that.

I agree that having Crossbar handle the authorization is the best way to go. Have you got a rough timeframe in mind for when this might be there? The proposed scheme seems to meet my particular needs quite well.

From thinking about this the last few days, I think the main trick is to find the flexibility / simplicity balance that you mention.

For example I guess one common requirement with PubSub authorization is that certain properties within an object to be published should only be exposed to certain roles.

So with the permissions sheme outlined in config.json, there would need to a different uri per role with each uri having “allowed” properties in the publication?

Thanks again,

Mike

···

On Mon, Jun 23, 2014 at 11:50 PM, Tobias Oberstein tobias.o...@gmail.com wrote:

Hi Mike,

Am 23.06.2014 17:32, schrieb Mike Raistrick:

Hi,

I have a subscribing client (browser with Autobahnjs) and publishing

server (node with Autobahnjs), connected via Crossbar.

If I understand properly neither the client or server have any knowledge

of each other. Crossbar handles the subscription from the client and

routes publications from the server.

Exactly.

So if I have multiple clients, and want to make sure that they can only

subscribe to authorized topics what are the options? I guess:

A. Authorization somehow handled by crossbar - this page seems a little

light:

https://github.com/crossbario/crossbar/wiki/Authorization

Yes;) The reason is: it’s not there yet. Once it is, the permissions as e.g. here

https://github.com/crossbario/crossbar/blob/master/crossbar/crossbar/templates/hello/python/.crossbar/config.json#L18

in a Crossbar configuration will control if a client is allowed to subscribe to a specific topic, publish to a specific topic, call a specific procedure and register a specific procedure. Either via literal URI match or URI pattern match.

or

B. Intially some RPC call from client to server with authentication and

authorization in the server code, resulting in an agreed (via the RPC

call) new pubsub topic (some crypto to generate some randomness). Seems

a little hokey as there is still nothing to stop another client from

subscribing if they figured out / guessed

I wouldn’t recommend such a scheme. The natural place to enforce authorization is the router. The router is the one actually doing the call and event routing, and it is hence the right place to put restrictions regarding routing into effect.

The goal with Crossbar is to have above, simple yet flexible authorization scheme from configuration “good enough” for most cases.

or

C. I’ve completely misunderstood / missed something obvious.

No, it seems you have a good grasp of this stuff already.

By the way I have to say that I’m very impressed with Crossbar and the

Autobahnjs components so far - I’ve been following with interest the

various discussions on “real use” stories and examples.

Great! Thanks. pls spread the word …

Personally I’m trying to use them together with Reactjs and a back end

graph database (Titan with its interface exposed through Rexster). If I

get through it all I hope I can help contribute :wink:

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

mailto:autobahnws+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
Awesome, we need more hands. Also PR …

Please keep us updated on your project and of course issues you encounter with Crossbar.

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

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

0 Likes

#4

Hi Mike,

Hi Tobias,
thanks for that.

I agree that having Crossbar handle the authorization is the best way to
go. Have you got a rough timeframe in mind for when this might be there?

In the coming weeks ..

The proposed scheme seems to meet my particular needs quite well.

From thinking about this the last few days, I think the main trick is
to find the flexibility / simplicity balance that you mention.

Absolutely. No single solution will fit all cases, but there should be a good coverage using the proposed authorization scheme.

For example I guess one common requirement with PubSub authorization is
that certain properties within an object to be published should only be
exposed to certain roles.

Authorization based on application data content is outside the scope of what any authorization mechanism in Crossbar would sanely do.

So with the permissions sheme outlined in config.json, there would need
to a different uri per role with each uri having "allowed" properties in
the publication?

Sorry, I don't understand. If you want to have certain properties (= application data attribtues) only received but a subset of subscribers, you need to publish 2 events to 2 different URIs. You then limit again via URI.

There is no way to say: publish THIS event, but only include attribute THIS.x1 in the event sent to subscribe S1 if S1 has role R1.

That would (among others) require the router to understand the application payload. And that means application logic in the router. And that is a no go. WAMP is explicitly designed to keep the router free of any app code/logic ..

Cheers,
/Tobias

···

Am 25.06.2014 10:42, schrieb Mike Raistrick:

Thanks again,

Mike

On Mon, Jun 23, 2014 at 11:50 PM, Tobias Oberstein > <tobias.o...@gmail.com <mailto:tobias.o...@gmail.com>> wrote:

    Hi Mike,

    Am 23.06.2014 17:32, schrieb Mike Raistrick:

        Hi,

        I have a subscribing client (browser with Autobahnjs) and publishing
        server (node with Autobahnjs), connected via Crossbar.

        If I understand properly neither the client or server have any
        knowledge
        of each other. Crossbar handles the subscription from the client and
        routes publications from the server.

    Exactly.

        So if I have multiple clients, and want to make sure that they
        can only
        subscribe to authorized topics what are the options? I guess:

        A. Authorization somehow handled by crossbar - this page seems a
        little
        light:
        https://github.com/crossbario/__crossbar/wiki/Authorization
        <https://github.com/crossbario/crossbar/wiki/Authorization>

    Yes;) The reason is: it's not there yet. Once it is, the permissions
    as e.g. here

    https://github.com/crossbario/__crossbar/blob/master/crossbar/__crossbar/templates/hello/__python/.crossbar/config.json#__L18
    <https://github.com/crossbario/crossbar/blob/master/crossbar/crossbar/templates/hello/python/.crossbar/config.json#L18>

    in a Crossbar configuration will control if a client is allowed to
    subscribe to a specific topic, publish to a specific topic, call a
    specific procedure and register a specific procedure. Either via
    literal URI match or URI pattern match.

        or

        B. Intially some RPC call from client to server with
        authentication and
        authorization in the server code, resulting in an agreed (via
        the RPC
        call) new pubsub topic (some crypto to generate some
        randomness). Seems
        a little hokey as there is still nothing to stop another client from
        subscribing if they figured out / guessed

    I wouldn't recommend such a scheme. The natural place to enforce
    authorization is the router. The router is the one actually doing
    the call and event routing, and it is hence the right place to put
    restrictions regarding routing into effect.

    The goal with Crossbar is to have above, simple yet flexible
    authorization scheme from configuration "good enough" for most cases.

        or

        C. I've completely misunderstood / missed something obvious.

    No, it seems you have a good grasp of this stuff already.

        By the way I have to say that I'm very impressed with Crossbar
        and the
        Autobahnjs components so far - I've been following with interest the
        various discussions on "real use" stories and examples.

    Great! Thanks. pls spread the word ..

        Personally I'm trying to use them together with Reactjs and a
        back end
        graph database (Titan with its interface exposed through
        Rexster). If I
        get through it all I hope I can help contribute :wink:

    Awesome, we need more hands. Also PR ..

    Please keep us updated on your project and of course issues you
    encounter with Crossbar.

    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+unsubscribe@__googlegroups.com
        <mailto:autobahnws%2...@googlegroups.com>
        <mailto:autobahnws+_...@googlegroups.com
        <mailto:autobahnws%2...@googlegroups.com>>.
        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+unsubscribe@__googlegroups.com
    <mailto:autobahnws%2...@googlegroups.com>.
    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

Hi Tobias,

···

On Wed, Jun 25, 2014 at 4:49 PM, Tobias Oberstein tobias.o...@gmail.com wrote:

Am 25.06.2014 10:42, schrieb Mike Raistrick:

So with the permissions sheme outlined in config.json, there would need

to a different uri per role with each uri having “allowed” properties in

the publication?

Sorry, I don’t understand. If you want to have certain properties (= application data attribtues) only received but a subset of subscribers, you need to publish 2 events to 2 different URIs. You then limit again via URI.

Yep that’s exactly what I meant

There is no way to say: publish THIS event, but only include attribute THIS.x1 in the event sent to subscribe S1 if S1 has role R1.

That would (among others) require the router to understand the application payload. And that means application logic in the router. And that is a no go. WAMP is explicitly designed to keep the router free of any app code/logic …

Makes perfect sense.

Thanks again! Time to get coding…

Cheers

Mike

0 Likes