Link Search Menu Expand Document

ARENA Security Overview

The root of trust for ARENA MQTT messages and other resources derives from the ACL permissions stored in the user database applied to an ARENA JWT.

Authenticated or Anonymous

The ARENA supports 2 basic modes of access: an Authenticated account to control scenes, and a more restricted Anonymous login to view scenes only.

  • Web Authenticated: Users can view and edit ARENA scenes, and video conferences.
  • Web Anonymous: Users can only view ARENA scenes, video conferences, and additional features are restricted. Users can only update their own avatar 3d object.
  • CLI Authenticated: Users can run ARENA command line applications to alter the scene interactively.

Authority Flow

The user database is consulted to generate the ARENA JSON Web Token (jwt1), then each client can use the jwt1 to connect to the MQTT broker. The scene persistence database generates its own JWT (jwt2) to subscribe to published messages. This means that the ACL for scenes can only be stored in the user database, since the scene persistence database depends on the token (jwt1) generated by the user database for published messages to succeed.

Web and CLI Client Authority Flow

  1. A user supplies their login credentials on the ARENA web client by visiting the web host in a browser or when launching an ARENA Python application.
  2. Login credentials are checked in the ARENA User database and an ACL-appropriate ARENA JWT (jwt1) is returned. The jwt1 will include a specific list of topics the user is allowed to publish and subscribe to.
  3. (Web only) A Jitsi server connection is established using jwt1 which includes authority for this scene as a meeting room.
  4. Any static graphical object data for the scene is loaded from the object persistence database if the jwt1 permits subscribing to this scene.
  5. A MQTT broker connection is established with a subscription to messages for scene graphical updates, user text chat, and runtime management topics. Now the user can publish MQTT messages to change scene graphics, which is generally only permitted by the scene creator via jwt1.
  6. If MQTT messages for the scene requested to be persistent and not ephemeral in the scene, the persistence database has subscribed to the MQTT broker with an all-scene subscription JWT (jwt2) so it may save those published message payloads.
  7. The user is subscribed via MQTT to all graphical updates to the scene, user text chats, and app updates, creating a synchronized real-time 3d-experience for users.
  8. Optionally, a user may add/delete scenes from the persistence database, requiring the appropriate topic level permission from jwt1.

User IDs

ARENA web visitors are uniquely identified by their camera object-id, which includes their username and a server-issued session-id.

As all 3D objects in the ARENA are identified by names, camera IDs have 3 underscore separated components, e.g: camera_1234567890_er1k. The last part is your username, the middle part is a unique ID. To restrict user-spoofing, the user database service assigns a unique session-id at the time the ARENA JWT is issued.

Staff users may override the random user ID to test experimental cameras and equipment. You can specify the scene address URL parameter e.g. &fixedCamera=er1k which will ignore the server assigned ID.

Scene Permissions

All scenes have a few default permissions to allow public viewing and private editing.

  • Public Write: Open permission to subscribe to the entire scene (default: enabled).
  • Public Read: Open permission to publish to the entire scene (default: disabled).
  • Allow Anonymous: Open to allow Anonymous login users (default: enabled).
  • Editors: List of usernames namespace owner has added as editor (default: none).

MQTT Permissions List

The list of topics the ARENA JWT permits you to publish and subscribe to can be viewed on those pages which make direct MQTT broker connections.

  • Scene View: Permissions link on the Settings panel.
  • Scene Builder: Permissions link on the right navigation menu in the top of the page.
  • Network Graph: Permissions link on the right navigation menu in the top of the page.
  • Runtime Visualization: Permissions link on the right navigation menu in the top of the page.

User database access

User database access is controlled by use of third party Oauth2 from Google at the moment.

MQTT Broker access

The ARENA JWT is required to connect to the broker and the custom claims of the JWT describe exactly which topics any user can publish or subscribe to.

Jitsi Server access

The ARENA JWT is required to allow any client to publish video conferencing data to our Jitsi servers. The ARENA JWT includes fields denoting the Jitsi room representing the scene.

Persistence database access

The ARENA JWT is required to save any scene objects or other scene settings. The topic structure which allows permissions for publish to a scene is used to determine if commands to delete a scene should be permitted or denied. It is also used to determine if a user can publish commands to the MQTT bus and in turn anything the persistence database is subscribed to.