Authentication and authorization. User management.

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 read only;
cwrite — access list for modification;

List of client resource IDs:

dashboard — quick access to dashboard by PIN code (cread);
time — ability to change the timeline for "Chart" view (cwrite).

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.

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 — used for contacts profile of user;
RFU2 — used for additional parameters (PIN code, etc.).

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).

The authorization request by PIN code contains the following fields:

querytype — request type: authpin — user authorization in the system by PIN;
name — authorized user name;
n — PIN code, lenght from 4 to 8 digits.

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

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 - group write access list.

Closing the session is carried out by the "authclose" command with session key:

querytype — request type: authclose — close the user session in the system;
k — session key.

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:

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 - 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;
mail - e-mail address for user contact;
phone - phone number for user contact;
pin - PIN code for quick access to dashboard (lenght from 4 to 8 digits).

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;
mail - e-mail address for user contact;
phone - phone number for user contact;
pin - PIN code for quick access to dashboard (lenght from 4 to 8 digits).

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.