Account Management

Owned by israel drori (Unlicensed)
Last updated: 13 Dec 2023 by Alon Men

ZEN Master features a multi-tier access control mechanism that enables granular control of the access privileges down to the object level. It manages access to all system objects, including Resources (e.g., ZECs, Broadcaster Clusters, Receivers, Licenses, Task Sets, Incidents, Live Events, Maps, etc.), Sources, Channels (e.g. adaptive channels, pass-through channels), Targets, and Reports.

The access control is managed through the following entities:

  • Tags – Each object (Resource, Source, Channel, Target, Report) is assigned one or more Tags. The assignment of the Tag is performed during the creation/configuration of the object. The same Tag can be assigned to several different objects.
  • Roles – A role defines a set of privileges in the system. A role is associated with one particular Tag, enabling access to objects associated with that Tag. The role also designates what actions can be performed on each object type (i.e. Resources, Sources, Channels, Targets, and Reports). Actions include Read (the ability to view data from the object), Write (the ability to edit the object’s configuration), Notify (the ability to receive email notifications/alerts regarding the object). A Tag can be associated with one or multiple roles.
  • Users and User Groups – A user receives privileges in the system by being assigned one or multiple roles. Users can be assigned to User Groups. A user can be assigned a role either directly or through a user group to which he is assigned.
    One or multiple users are designated as Administrators. An Administrator can access and interact with all objects without need for assignment of specific roles. He can also manage SSH Keys, transcoding profiles and users.

Summary:

A user can only access a specific object in the system if he is assigned a role that -

  • is associated with the Tag that is assigned to that particular object, and
  • has privileges that allow access to that object type.

For Example:

The diagram above illustrates the access privileges model. Notice the following:

  • Users/User Groups and Roles relationships - a user can be assigned to multiple roles (one to many). Each role may have a different set of permissions (e.g., read, write, notify), but not necessarily as the role's relationship to tags will also determine the access to the various objects.  
    • User 1 is assigned to Role 1 directly and to Role 2 by being part of User Group 1, which is assigned to Role 2. 
    • User 2 is assigned to Role 2 by being part of User Group 1
    • User 3 is assigned to both Role 2 and Role 3. Since Roles are cumulative, User 3 will have both Read and Write permissions on the objects related to Tag 2.  
  • Roles and Tags relationships - each role can be assigned to a single tag only (one to one). However, more than one role can be assigned to the same tag.
    • Role 1 is assigned to Tag 1. 
    • Role 2 and Role 3 are both assigned to Tag 2.
    • Tag 4 is not related to any Roles. In this sense, it is used to group objects. This is useful, for example, when you want to search by tag for multiple objects share the same tag.   
  • Tags and Objects relationships - each tag can be assigned to multiple objects and each object can have multiple tags (many to many). 
    • Tag 1 is related to Objects 1, 2, and 3.
    • Tag 2 is also (like Tag 1) related to Object 3. 
    • Tag 4 is related to Objects 5 and 6 for grouping purposes only, as it is not related to a Role. 

From an end-to-end perspective:

  • User 1 has Read Write and Notify permissions on Objects 1, 2, and 3 as well as Read-only permission on Object 4. 
  • User 2 has Read-only access permission on Objects 3 and 4.
  • User 3 has Read and Write permissions on Objects 3 and 4.