Proving Write Permissions Remotely

[mwfarb]

Problem: Currently, Application/Program clients and the web client itself, do not have a way to prove that any other user client has permissions to write to the scene. This ACL rule is stored in each client's JWT and in the server's user DB. Here are two uses cases:

1. Python program ARB, running with User A's auth, wants to know if web-client User B in the scene can write to the scene so that it can enable ARB's control panel for User B.
2. Web-client User A wants to know if User B has enough permission to be rendered invisible or hidden in the scene.

Issue: We should not republish User B's JWT for ARB/User A, since allowing User B JWT to leave User B's client and control begins to degrade security.

Insight: Let the remote User B use their JWT encoded ACL topic tree to prove their write permission by attempting to publish an message to the scene topic and allow User A to act if the message is allowed to be published at the broker level and picked up in User A's subscription.

Workflow Handshake Pseudo-code: User A owns the Scene A. All messages are published and subscribed to the scene objects MQTT topic. User B client wants to be rendered hidden for User A, or User B wants to use ARB's control panel to edit the scene. Each application/client may set it's own string as Service X to avoid conflicts from multiple sources, perhaps using a random GUID.

1. User A Client/Program receives subscribed message: User B camera has joined
2. User A Client/Program publishes message: Send proof User B can publish to Scene A for Service X
3. User B Client receives ^^ message, and publishes message: User B requests access to Service X
4. If User A Client/Program does receive ^^ message, the broker JWT User B used to connect has allowed them to publish to the scene topic, and User A can enable the ARB panel for User B or render User B hidden.
5. If User A Client/Program does not receive ^^ message, the broker JWT User B used to connect has not allowed them to publish to the scene topic, and no further action is allowed.

Implementation:

• Modify ARENA-core to receive request message, and send ack message.
• Add hidden user feature to ARENA-core.
• Add examples to docs ARENA and ARENA-py.
• Add a helper method(s)/callback(s) to ARENA-py.

[hi-liang]

Some questions, some of which will lead to more questions:

• Under what conditions would userA as webclient want to automatically send the permission challenge for a joined user?

• Is the challenge sent via chat channels (or in any way direct to userB)?

• What is visibility of the response? Is there benefit of it being in a restricted channel only visible to privileged users?

• For benefit of only a persistent-type programA, could userB simply announce their permission on entry to the write-restricted topic?

[nampereira]

Maybe naive, but I'm wondering why we can't ask account?

[mwfarb]

This is good! Your questions lead me to believe some of my assumptions are flawed.

Some questions, some of which will lead to more questions:

• Under what conditions would userA as webclient want to automatically send the permission challenge for a joined user?
• Is the challenge sent via chat channels (or in any way direct to userB)?
• What is visibility of the response? Is there benefit of it being in a restricted channel only visible to privileged users?
• For benefit of only a persistent-type programA, could userB simply announce their permission on entry to the write-restricted topic?

Mainly, we cannot use the publish of a challenge to the scene topic, as it only proves that the named object_id in the topic tree can pass through, and the topic tree could get more complicated. What we really want is a proof that the user has access to the whole wildcard scene/# topic, and for that I think @nampereira is close.

[mwfarb]

Maybe naive, but I'm wondering why we can't ask account?

I think we can. I was thinking I wanted to avoid a REST call to probe user account data, but there may be a way to help limit that. What we really want it something with these properties:

• User A asks account if User B has publish access to topic .../scene/#
• User A presents account with some token (perhaps a new token/scheme) of User B's that account can verify belongs to User B.

[mwfarb]

Maybe presenting the following is enough for account:

• topic to check (i.e. scene or other realm/s/mwfarb/test5/#)
• idTag from user camera (i.e. 0123456789_mwfarb)

Since the session nonce is randomly generated, it may discourage probing based on known usernames.

Effects:

• Might require us to keep the nonce in memory on account, to check that user session is active.
• Can respond with simple true/false.

[mwfarb]

Compare 2 Program models, which may help us derive the right structure:

• laser-pointer: where we want clicks by users to allow all users to write lines.
• arb: where we want clicks by only users with write permissions to create/update/delete objects.