Article contents:
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:
List of server resource IDs:
2) Lists of client permissions (web interface):
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:
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".
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 — used for contacts profile of user;
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.
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:
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," mail="mail4@my.com" phone="123456789" /> |
Here:
Closing the session is carried out by the "authclose" command with session key:
The read request for the user account contains the following fields:
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," mail="mail4@my.com" phone="123456789" /> |
Here:
The request to create a new account (or modify an existing one) contains the following fields:
The request to delete an existing user record contains the following fields:
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.
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:
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.
The request contains the following fields:
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.
The request contains the following fields:
The response of the system is as follows:
|
or
|
Here:
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,
# # 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):
... $INCLUDE- dictionary.local ... |
The server client list is located in /etc/raddb/clients.conf. The client record looks like this:
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:
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:
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.