Authorization model

This article aims to explain the authorization model available in YourSixOS. Authorization is the act of allowing a certain principal access to a certain resource, e.g. allowing user John Doe to live stream camera CAM-E01.

Overview

Principals

Different principals are authorized resource access in different ways. There are two principals available in YourSixOS:

• Central stations
• Users

Their different means of authorization are explained in granular detail in sections below.

Users (main application)

This section describes how to authorize users access to resources. Users only exist as a principal in the main application.

User roles

A user may have one, two or three roles: user, admin and/or superadmin. Roles provide the first masked base set of permissions, as follows:

Role	Permission set
user	May use (view, control, etc.) if having scopes on any resource
admin	May add users. May administer resources if having administer scope on any resource
superadmin	Can do everything

Roles may be stacked, in which combination is performed using OR-logics, meaning that the more roles a user has, the more access the user will have.

User

The user role is used as a base role. The user role provides no access alone and must be combined with scopes on individual or layered resources in order to be authorized any access.

Administrator

The admin role is used as a base role for administrators. The administrator role authorizes a user to create additional users, but only authorizes passing the user role.

The admin role can also be used to authorize administration of individual or layered resources. In order for authorizaiton to be fulfilled, the user granted the admin role must also be granted the administer resource scope.

Super administrator

The superadmin role is used as a root-level role for administrators that shall be able to do everything in the account, including creating additional users and passing any role to them (including the superadmin role).

Resource scopes

Resource scopes are essentially resource-based permissions, acting as ACLs.

Scopes operate on resources in a layered approach, meaning that a scope on a parent resource will apply to child resources. For example; if permission is given for Live view on Site X to John Doe, John Doe will be able to stream live view from any camera on Site X.

Different resources may come with different scopes, but all scopes are available on parent resource types. For example; barriers come with the ability to be controlled. Barriers thus have a scope called barrier-control. That scope is available also on site-level, applying to all barriers under that site. Sites may have additional scopes, but site-level scopes are not inherited by child resources. In essence; scopes are honored but not inherited downstream.

Site scopes

• administer: Administering the site, including changing site settings and creating child-resources under the site. The administer-scope is, as described generically above, applied to child resources too.

Alarm group scopes

• arm/disarm: Setting the arm-disarm override state on the alarm group.

Device scopes

WARNING

The device-level administer scope comes with a gotcha: it implies all other available scopes except accessdevice.

• administer: Allows administration of the device, including changing some device settings (excluding hardware settings which are set by integrators).
• accessdevice: Allows opening a tunnel directly to the device's built-in UI.
• stream: Allows streaming video from the device.
• playback-video: Allows playback of recorded video from the device.
• export-video: Allows exporting recorded video from the device.
• playback-audio: Allows playback of recorded audio from the device.
• ptz: Allows PTZ control.
• talkdown: Allows performing an audio talkdown using the device (assumes device has audio output capability).
• events: Allows viewing (searching and timeline) events from the device.

Thing scopes

The available scopes varies per thing, see thing types below.

Barriers

• events: Allows viewing (searching, timeline and live feedback) events from the barrier.
• control: Allows controlling the barrier (accessing, unlocking and locking).

Peripherals

• events: Allows viewing (searching, timeline and live feedback) events from the peripheral.
• control: Allows controlling the peripheral (pulsing and setting). Assumes peripheral is of type output.

Integrators

The Integrator is a variant of organization where its users are external to the organization they manage. Other than that, the authorization model works similarly to organizaton users, with the exception of a different role set.

Integrators are used to manage organizations, whereas organizations are the top-most level resource (basically, a security system).

Integrator roles

An integrator user may have one, two or three roles: technician, admin and/or superadmin. Roles provide the first masked base set of permissions, as follows:

Role	Permission set
technician	May perform work on any resource of any managed organization if having scopes to do so.
admin	May add users within the integrator. May work on any resource of any managed organization.
superadmin	Can do everything within the integrator and all managed organizations

Technician

The technician role is used as a base role. The user role provides no access alone and must be combined with scopes on individual or layered resources in order to be authorized any access.

Administrator

The admin role is used as a base role for integrator administrators. The administrator role authorizes a user to create additional users, but only authorizes passing the technician role.

The admin role authorizes a user to perform work on any resource on any managed organization without further scope assignment.

Super administrator

The superadmin role is used as a root-level role for administrators that shall be able to do everything in the integrator, including creating additional users and passing any role to them (including the superadmin role).

Resource scop

Integrator resource scopes work in the same way as organization-level resource scopes.

Central stations

Central stations are authorized access in four stages:

1. A central station partners up with YourSix and is setup with credentials that establishes trust (authenticates) between the central station with YourSixOS.
2. An integrator partners up with YourSix and gets an account in YourSixOS.
3. YourSixOS authorizes the integrator and the central station to work together.
4. Once step 3 has been performed, the integrator can now authorize that central station access to individual sites.

Once the central station has been authorized access to a specific site, there is no further or more granular authorization needed. Now the central station can carry out all the operations allowed by the central station application.

Read more about central stations.