Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Article contents:

Permissions in the system

Each user profile in the system can access system resources in read-only or read-write modes.

Each resource in the system is mapped to its corresponding access identifier.

Access control is performed using lists. A list is a text string consisting of access identifiers, separated by commas.

Accordingly, there are two types of lists in the user profile: access lists for reading and write access lists (meaning both writing and reading).

There are three types of permission lists in the system:

1) Server permission lists:

  • sread - list with read access rights
  • swrite - list with write access rights;

List of server resource IDs:

  • accesskeys — management of iButton access keys and compatible;
  • cameras — control of video cameras;
  • canbus — can bus control;
  • devvirt — virtual devices management (timers, pings, triggers);
  • elements — element management;
  • groups — group management;
  • gsm — gsm modem control;
  • languges — installed localization files management;
  • log — system log management;
  • logics — logic control;
  • modules — modules management;
  • notify — notification management (mail, trap, sms);
  • relays — relay control (global functions);
  • sdcard — sd card management;
  • system — runtime management (OC Linux);
  • users — users management;
  • view — control of the web interface appearance;
  • all — any existing resources

2) Lists of client permissions (web interface):

  • cread — access list for reading;
  • cwrite — write access list;

The list of client IDs (web interface) is generated and used exclusively by the client (web interface) in accordance with logical organization;

3) Permissions lists for groups of objects:

  • gread — list of group IDs with read-only access;
  • gwrite — list of group IDs with write access;

Lists of permissions for groups consist of group IDs and are intended to restrict the client (web interface) access to group objects.

The format of the list is the IDs (positive integer) available in the group system, separated by commas, with special control words:

  • all — full access, to all groups and elements not in groups;

  • none — access is completely prohibited.

By default, there are no groups in the system, elements and modules are not in a groups, and access to them is possible only with rights "all".

General description of the authentication and authorization procedure for the users

Information about user profiles is stored as records in the user database SQLite3. Path to the database file is /mnt/jffs/etc/users.sqlite.

Registered user profile data is stored in the SkyControlUsers table of the user database. User profile is a record in this table. Each record consists of the following fields:

  • ID — a unique user identifier, an integer value, starts with 1;

  • Valid — the sign of the valid record, an integer value, is 1 for the current record and 0 for the blocked (remote) record;

  • Name — unique name of the registered user;

  • Pass — hash of the secret character set, which serves to authorize the user;

  • RegDate — user registration date;

  • SRead — list of access to read server;

  • SWrite — list of access to the server record;

  • CRead — access list for reading the client;

  • CWrite — list of access to the client's record;

  • GRead — access list for reading groups;

  • GWrite — list of access to record groups;

  • RFU1 — reserved;

  • RFU2 — reserved.

Initially, there is only one user entry in the database with the name guest and the password corresponding to the hash of the "guest" character set (the SHA-1 algorithm is used).

The user is authenticated by comparing the password he entered with the password in the user database, and also by the coincidence of the Name name. The password is a hash code entered by the user. Simultaneous access to the system of several clients is possible by one user record.

Upon successful user authentication, a unique session ID (field k) is sent to the client. All further calls to the server are made with this identifier.

Upon successful authentication, the session identifier, client IP address and other service information is stored by the system in a special session record. When the system is rebooted, all session entries will be lost, so you will need to re-authenticate.

Users authentication and authorization

User authorization in the system is performed every time you log in to determine the permissions for the user to access the system resources.
During the authorization process, the user receives a session key, as well as permissions. Execution of requests in the system is performed with the key of the session until the expiration of this key or reauthorization.
The authorization request contains the following fields:

  • querytype — request type: auth — user authorization in the system;
  • name — authorized user name;
  • h — hash of the password of the authorized user (SHA-1 is used, but any one can be used to choose the web developer).

If the authorization is successful (the saved and transmitted hash match), an example of the answer is:

<user id="1" k="491791596" name="guest" sread="all," swrite="elements," cread="all," cwrite="all," gread="3001, 3002," gwrite="3001," />

Here:

  • id — unique user ID;
  • k — session key;
  • name — user name;
  • sread — list of access to read server;
  • swrite — list of access to the server record;
  • сread — access list for reading the client;
  • сwrite — list of access to the client's record;
  • gread — access list for reading groups;
  • gwrite — список доступа на запись групп;

Reading user account data

The read request for the user account contains the following fields:

  • querytype — request type: getuser — read account;
  • k — the key of the current session;
  • id — a unique user ID whose record is required to be read, in the absence of an identifier field, a list of all users of the system is displayed in the query.

The response of the system is as follows:

<users> <user id="1" name="guest" sread="all," swrite="elements," cread="all," cwrite="all," gread="3001, 3002," gwrite="3001," />
...</users>

Here:

  • id - unique user ID;
  • k - session key;
  • name - user name;
  • sread - list of access to read server;
  • swrite - list of access to the server record;
  • withread-access - list for reading the client;
  • сwrite - list of access to the client's record;
  • gread - access list for reading groups;
  • gwrite - list of access to record groups;

Create / modify user account

The request to create a new account (or modify an existing one) contains the following fields:

  • querytype - request type: adduser - create a user account in the system;
  • k - the key of the current session;
  • id - optional fiel unique user ID, whose record requires to be changed; in the absence of it, a new account is created;
  • name - the user name;
  • h - hash of the user's password (MD5, SHA, etc. to the choice of the web developer);
  • sread - list of read access to the server;
  • swrite - list of access to the server record;
  • сread - list of access to read client;
  • сwrite - list of access to the client's record;
  • gread - access list for reading groups;
  • gwrite - list of access to record groups;

Deleting a user account

The request to delete an existing user record contains the following fields:

  • querytype - request type: deluser - delete account;
  • k - the key of the current session;
  • id is the unique identifier of the user you want to remove from the system, the user can not delete his own account.

When you delete records, they are not erased from the table, while the Valid field is cleared to 0. Restoring the Valid field back to 1 after removing the entry in the API is not provided. The user can not delete his own account, under which he logged on.

The user authorized through the Radius server can not delete and edit existing local user records, or create new entries.

Authentication and authorization via the RADIUS server

User authorization is also possible via the RADIUS server

The RADIUS client settings are located in the /mnt/jffs/etc/radius/ directory. The directory contains the following files:

  • dictionary - Radius dictionary containing standard parameters attribute-value;
  • dictionary.local - Radius dictionary containing special manufacturer parameters (Vutlan), in this case, user access permissions. Special manufacturer parameters (Vendor Specific Attribute) must be coordinated with the server part of Radius;
  • radius.conf - Radius client configuration file that contains the address, port, and secret password of the Radius server.

To configure authentication and authorization through the RADIUS server, appropriate API commands are provided.

When you install a new configuration of authentication and authorization through the Radius server, the system automatically reboots, after which the changes take effect.

Configure authentication and authorization through the RADIUS server

The request contains the following fields:

  • querytype - request type: setradius - Radius configuration;
  • k - the key of the current session;
  • enable - Enable or disable Radius atomization, can be set to 1 or 0;
  • addr - address of the remote Radius server;
  • port - port of the remote server Radius (usually 1812);
  • secret - the password for accessing the remote Radius server.

After successful processing of the request, the system will perform an automatic reboot, after which the changes will take effect.

When you enable authorization through a remote server, the authorization process for a new user will take place in two stages:

1) search for a user in the local database of the device;

2) if the user is not found in the local database, the remote Radius server is contacted to authorize the user.

View authentication and authorization settings via the RADIUS server

The request contains the following fields:

  • querytype - request type: getradius - Radius configuration;
  • k - the key of the current session.


The response of the system is as follows:

<radius enable="1" addr="192.168.1.88" port="1812"/>

or

<radius enable="0"/>

Here:

  • enable - a sign shows if Radius authorization is enabled or disabled;
  • addr - server address;
  • port - the server port.

Radius server settings

To configure the Radius server, you need to install a vendor dictionary, configure access (address and password) for the server clients (Sky-Control devices), and fill out a list of users with the appropriate attributes.

The manufacturer's dictionary (for example, the dictionary.local file) must be placed in the /etc/raddb/ directory,

dictionary.local
#
# Vutlan dictionary of parameters.
#
VENDOR        Vutlan        39052
ATTRIBUTE    SRead            10    string        Vutlan
ATTRIBUTE    SWrite           11    string        Vutlan
ATTRIBUTE    CRead            12    string        Vutlan
ATTRIBUTE    CWrite           13    string        Vutlan
ATTRIBUTE    GRead            14    string        Vutlan
ATTRIBUTE    GWrite           15    string        Vutlan
ATTRIBUTE    RFU1             16    string        Vutlan
ATTRIBUTE    RFU2             17    string        Vutlan

and also make sure that the dictionary file is included in the main dictionary (file dictionary):

dictionary
...
$INCLUDE-    dictionary.local
...

The server client list is located in /etc/raddb/clients.conf. The client record looks like this:

/etc/raddb/clients.conf
client 192.168.1.88 { 
   secret = password123 
}

The record specifies the client's ip-address and password for communication with the server.


User records are in the ./etc/raddb/mods-config/files/authorize file and have the following appearance:

/etc/raddb/clients.conf
username01 Cleartext-Password := "35675e68f4b5af7b995d9205ad0fc43842f16450" 
	SRead = "all,", 
	SWrite = "all,", 
	CRead = "all,", 
	CWrite = "all,", 
	GRead = "all,", 
	GWrite = "all,", 
	RFU1 = "something strange", 
	RFU2 = "anover something strange too"

The record specifies the user name, password (hash code of user input password), system access permissions and (in this case) reserved attributes.

If the attribute is not used, it must be removed from the record. It is not allowed to store empty attributes of the form:

RFU2 = ""

since the Radius client does not handle this situation correctly.

In the example of the user's entry, all devices that are authorized through a single Radius server will receive the same configuration of the user's permissions. If there is a need to give the user different rights on different devices, then you need to add an IP address check of the authorized device.

Such records will look, for example, like this:


/etc/raddb/clients.conf
username01 Cleartext-Password := "35675e68f4b5af7b995d9205ad0fc43842f16450", NAS-IP-Address == "192.168.1.88"
	SRead = "all,", 
	SWrite = "all,", 
	CRead = "all,", 
	CWrite = "all,", 
	GRead = "all,", 
	GWrite = "all,"

username01 Cleartext-Password := "35675e68f4b5af7b995d9205ad0fc43842f16450", NAS-IP-Address != "192.168.1.88"
	SRead = "all,", 
	SWrite = "devvirt,elements,log,logics,modules,notify,relays,sdcard,system,view,", 
	CRead = "all,", 
	CWrite = "all,", 
	GRead = "all,", 
	GWrite = "3001,3002,"

Here, when authorizing username01 through a device with IP address 192.168.1.88, user will get full access to the device (all fields are all). When authorizing the same username01 from other devices (all IP addresses except 192.168.1.88), the user will be restricted in the rights to write the resources and device groups.



Permissions in the system

Each user profile in the system can access system resources in read-only or read-write modes.
Each resource in the system is mapped to its corresponding access identifier.
Access control is performed using lists.A list is a text string of access identifiers, separated by commas.
There are two types of lists in the user profile: access lists for reading and writing access lists.
There are three types of permission lists in the system:

1) Server permission lists:

  • sread - list with read access rights
  • swrite - list with write access rights;

List of server resource IDs:

  • accesskeys - management of iButton access keys and compatible;
  • cameras - management of video cameras;
  • CANbus - CAN bus control;
  • devvirt - management of virtual devices (timers, pings, triggers - you need separate permissions for each ???);
  • elements - element management;
  • groups - group management;
  • gsm - control of the GSM modem;
  • languges - management of installed localization files;
  • log - management of the system log;
  • logics - logic schemes management;
  • modules - module management;
  • notify - notification management (mail, trap, SMS - you need separate permissions for each ???);
  • relays - relay control (global functions);
  • sdcard - management of the SD-card;
  • system - runtime environment management (OC Linux);
  • users - user management;
  • view - control the appearance of the web interface;
  • all - any existing resources;
  • accesskeys -
  • cameras - management of video cameras;
    CANbus - CAN bus control;
    devvirt - management of virtual devices (timers, pings, triggers - you need separate permissions for each ???);
    elements - element management;
    groups - group management;
    gsm - control of the GSM modem;
    languges - management of installed localization files;
    log - management of the system log;
    logics - logic schemesmanagement;
    modules - module management;
    notify - notification management (mail, trap, SMS - you need separate permissions for each ???);
    relays - relay control (global functions);
    sdcard - management of the SD-card;
    system - runtime environment management (OC Linux);
    users - user management;
    view - control the appearance of the web interface;
    all - any existing resources;

2) Lists of client permissions (web interface):

  • cread - list of access to read;
  • cwrite - access list for writing;

The list of resource identifiers of the client (web interface) is generated and used exclusively by the client (web interface) in accordance with its logical organization;

3) Permission lists for groups of objects:

  • gread - list of identifiers of groups with read-only access;
  • gwrite - a list of group IDs with read-only access;

Lists of permissions for groups consist of group identifiers and are intended to restrict the client (web interface) access to group objects.

The format of the list is the identifiers (positive integer) available in the group system, separated by commas, with special control words:

  • all - full access, to all groups and elements not in groups;
  • none - access is completely denied.

By default, there are no groups in the system, elements and modules are not in groups, and access to them is possible only with the rights of all.

General description of the authentication and authorization procedure for the user

Information about user profiles is stored as records in the user database. The database uses SQLite3. The path to the database file is /mnt/jffs/etc/users.sqlite.

Registered user profile data is stored in the SkyControlUsers table of the user database. The user profile is an entry in this table. Each entry consists of the following fields:

  • ID - unique user identifier, integer value, starts with 1;
  • Valid - the sign of the valid record, the integer value, is 1 for the current record and 0 for the blocked (remote) record;
  • Name - the unique name of the registered user;
  • Pass - hash code of the secret character set, which serves to authorize the user;
  • RegDate - user registration date;
  • SRead - access list for reading the server;
  • SWrite - list of access to the server record;
  • CRead - access list for reading the client;
  • CWrite - list of access to the client's record;
  • GRead - access list for reading groups;
  • GWrite - list of access to record groups;
  • RFU1 - reserved;
  • RFU2 - reserved.

Initially, there is only one user entry in the database named guest, and the password corresponding to the hash code of the "guest" character set (the SHA-1 algorithm is used).

User authentication is performed by comparing the Pass password entered with the password in the user database, and also by matching the Name name. The password is a hash code entered by the user of the string. Simultaneous access to the system of several clients is possible using one user record.

If the user is successfully authenticated, the client receives a unique session identifier (field k). All further calls to the server are made with this identifier.

Upon successful authentication, the session identifier, client IP address and other service information is stored by the system in a special session record. When the system is rebooted, all session entries will be lost, so you will need to re-authenticate.

Authentication and authorization of the user

User authorization in the system is performed every time you log in to determine the permissions for the user to access the system resources.

During the authorization process, the user receives a session key, as well as permissions. Execution of requests in the system is performed with the key of the session until the expiration of this key or reauthorization.

The authorization request contains the following fields:

  • querytype - request type: auth - authorization of the user in the system;
  • name - the name of the authorized user;
  • h is the password hash of the authorized user (SHA-1 is used, but any one can be used by the choice of the web developer).

If the authorization is successful (the saved and transmitted hash match), an example of the response is:

<user id="1" k="491791596" name="guest" sread="all," swrite="elements," cread="all," cwrite="all," gread="3001, 3002," gwrite="3001," />

Here:

  • id - unique identifier of the user in the system;
  • k - session key;
  • name - the user name;
  • sread - list of read access to the server;
  • swrite - list of access to the server record;
  • сread - list of access to read client;
  • сwrite - list of access to the client's record;
  • gread - access list for reading groups;
  • gwrite - list of access to record groups;

Reading user account data

The request to read the user account contains the following fields:

  • querytype - request type: getuser - read account;
  • k - the key of the current session;
  • id - unique identifier of the user whose entry is required to be read, in the absence of an identifier field, a list of all users of the system is displayed in the query.

The response of the system is as follows:

<users> <user id="1" name="guest" sread="all," swrite="elements," cread="all," cwrite="all," gread="3001, 3002," gwrite="3001," />
...</users>

Here:

  • id - unique identifier of the user in the system;
  • name - the user name;
  • sread - list of read access to the server;
  • swrite - list of access to the server record;
  • сread - list of access to read client;
  • сwrite - list of access to the client's record;
  • gread - access list for reading groups;
  • gwrite - list of access to record groups;

Create / modify user account

The request to create a new account (or modify an existing one) contains the following fields:

  • querytype - request type: adduser - create a user account in the system;
  • k - the key of the current session;
  • id - optional field, unique user ID, whose record needs to be changed, in the absence of which, a new account is created;
  • name - the user name;
  • h - hash of the user's password (MD5, SHA, etc. to the choice of the web developer);
  • sread - list of read access to the server;
  • swrite - list of access to the server record;
  • сread - list of access to read client;
  • сwrite - list of access to the client's record;
  • gread - access list for reading groups;
  • gwrite - list of access to record groups;

Deleting a user account

The request to delete an existing user record contains the following fields:

  • querytype - request type: deluser - delete account;
  • k - the key of the current session;
  • id - unique identifier of the user you want to remove from the system, the user can not delete his own account.

When you delete records, they are not erased from the table, while the Valid field is cleared to 0. Restoring the Valid field back to 1 after removing the entry in the API is not provided. The user can not delete his own account, under which he logged on.

The user authorized through the Radius server can not delete and edit existing local user records, or create new entries.

Authentication and authorization via the RADIUS server

User authorization is also possible via the RADIUS server

The RADIUS client settings are located in the /mnt/jffs/etc/radius/ directory. The directory contains the following files:

  • dictionary - Radius dictionary containing standard parameters attribute-value;
  • dictionary.local - Radius dictionary containing special manufacturer parameters (Sky-Control / Vutlan), in this case, user access permissions. Special manufacturer parameters (Vendor Specific Attribute) must be coordinated with the server part of Radius;
  • radius.conf - Radius client configuration file that contains the address, port, and secret password of the Radius server.

To configure authentication and authorization through the RADIUS server, appropriate API commands are provided.

When you install a new configuration of authentication and authorization through the Radius server, the system automatically reboots, after which the changes take effect.

Configure authentication and authorization through the RADIUS server

The request contains the following fields:

  • querytype - request type: setradius - Radius configuration;
  • k - the key of the current session;
  • enable - Enable or disable Radius atomization, can be set to 1 or 0;
  • addr - address of the remote Radius server;
  • port - port of the remote server Radius (usually 1812);
  • secret - the password for accessing the remote Radius server.

After successful processing of the request, the system will perform an automatic reboot, after which the changes will take effect.

When you enable authorization through a remote server, the authorization process for a new user will take place in two stages:

1) search for a user in the local database of the device;

2) if the user is not found in the local database, the remote Radius server is contacted to authorize the user.

View authentication and authorization settings via the RADIUS server

The request contains the following fields:

  • querytype - request type: getradius - Radius configuration;
  • k is the key of the current session.

The response of the system is as follows:

<radius enable="1" addr="192.168.1.88" port="1812"/>

or

<radius enable="0"/>

Here:

  • enable - a sign that shows if Radius authorization is enabled or disabled;
  • addr - server address;
  • port is the server port.

Radius server settings

To configure the Radius server, you need to install a vendor dictionary, configure access (address and password) for the server clients (Sky-Control devices), and fill out a list of users with the appropriate attributes.

The manufacturer's dictionary (for example, the dictionary.local file) must be placed in the /etc/raddb/ directory,

dictionary.local
#
# Vutlan dictionary of parameters.
#
VENDOR        Vutlan        39052
ATTRIBUTE    SRead            10    string        Vutlan
ATTRIBUTE    SWrite           11    string        Vutlan
ATTRIBUTE    CRead            12    string        Vutlan
ATTRIBUTE    CWrite           13    string        Vutlan
ATTRIBUTE    GRead            14    string        Vutlan
ATTRIBUTE    GWrite           15    string        Vutlan
ATTRIBUTE    RFU1             16    string        Vutlan
ATTRIBUTE    RFU2             17    string        Vutlan

and also make sure that the dictionary file is included in the main dictionary (file dictionary):

dictionary
...
$INCLUDE-    dictionary.local
...

The server client list is located in /etc/raddb/clients.conf. The client record looks like this:

/etc/raddb/clients.conf
client 192.168.1.88 { 
   secret = password123 
}

The record specifies the client's ip-address and password for communication with the server.


User records are in the ./etc/raddb/mods-config/files/authorize file and have the following appearance:

/etc/raddb/clients.conf
username01 Cleartext-Password := "35675e68f4b5af7b995d9205ad0fc43842f16450" 
	SRead = "all,", 
	SWrite = "all,", 
	CRead = "all,", 
	CWrite = "all,", 
	GRead = "all,", 
	GWrite = "all,", 
	RFU1 = "something strange", 
	RFU2 = "anover something strange too"

The record specifies the user name, password (hash code of user input password), system access permissions and (in this case) reserved attributes.

If the attribute is not used, it must be removed from the record. It is not allowed to store empty attributes of the form:

RFU2 = ""

since the Radius client does not handle this situation correctly.

In the example of the user's entry, all devices that are authorized through a single Radius server will receive the same configuration of the user's permissions. If there is a need to give the user different rights on different devices, then you need to add an IP address check of the authorized device.

Such records will look, for example, like this:

/etc/raddb/clients.conf
username01 Cleartext-Password := "35675e68f4b5af7b995d9205ad0fc43842f16450", NAS-IP-Address == "192.168.1.88"
	SRead = "all,", 
	SWrite = "all,", 
	CRead = "all,", 
	CWrite = "all,", 
	GRead = "all,", 
	GWrite = "all,"

username01 Cleartext-Password := "35675e68f4b5af7b995d9205ad0fc43842f16450", NAS-IP-Address != "192.168.1.88"
	SRead = "all,", 
	SWrite = "devvirt,elements,log,logics,modules,notify,relays,sdcard,system,view,", 
	CRead = "all,", 
	CWrite = "all,", 
	GRead = "all,", 
	GWrite = "3001,3002,"

Here, when authorizing username01 through a device with IP address 192.168.1.88, it will get full access to the device (all fields are all). When authorizing the same username01 from other devices (all IP addresses except 192.168.1.88), the user will be restricted in the rights to write the resources and device groups.

  • No labels