Promotic
WikipediaLinkedInYoutubeTwitterFacebook

Users, user groups, permissions and login system

The system of users allows designers to create protected PROMOTIC applications.

PROMOTIC includes both local and network user loging (authentication) system for running applications. If there is a need to create a protected application (local or network), then the operation will be executed only if the current logged user has the necessary permission (belongs to specified user groups)(authorization). If the user does not have the required permission then the operation fails with an error message.

 

User logs into the system locally or from network and must pass the authentication process (identity check) that verifies the user name and password. After successfull user authentization a specific logged-in user (local or network) is created, represented by the PmUser object. If two users log in using the same name and password from individual computers then two different logged-in users are created with different IP address. A list of currently logged-in users can be seen in the INFO system and can also be obtained by using the methods Pm.LoggedUser and Pm.GetUserInfo. A reference to currently logged-in user is alos here: Data binding UP - Data binding to the logged user property.

Each logged-in user is connected with a list of user groups where the user is a member. Such member user group list is crucial for each user because it represents his permissions for specific actions (protected operations). Each protected operation has a specific list of user groups that are authorized to perform such operation. This means that assigning the user to specific user groups defines what the user can or cannot do in the application.

 
Basic terms:
- Authentication: The process of user authentication (login)(for example by name and password).
- Authorization: The process of checking whether the authenticated (logged-in) user has permission to do something (for example by usage of the "user groups").
 

Subsystem consists from following logical parts:

1) User groups: Allow to create a list of all logical application user groups (e.g. $ADMIN, $OPER, GUESTS etc.). Configuration is performed in the development environment, on the "Users" page. It is crucial for each logged-in user to which user groups it is assigned. Because application security is done based on these user groups (not to specific users) which in turn allows new users to be added and removed (even in runtime) without modifing the application.
2) Users:
a) PROMOTIC users: Allow to create a list of all application users with the definition of the user type (local and/or network) and to set passwords for users and define user group membership.

The configuration is performed in the in the development environment on the "Users" page. In the running application either by the Pm.WndEditUsers method in the user edit window, or directly by Pm.AddUser and Pm.RemoveUser methods.

b) Windows users: Allow using the Windows user login credentials. Consequently it is possible to use the list of local and global Windows user groups (where the Windows user is amember) to create a list of PROMOTIC user groups. In each PROMOTIC user group it is possible to enter a name corresponding to Windows user group. Logged-in user that is authentized in Windows is then in the PROMOTIC system fully corresponding to a logged-in PROMOTIC user. This concept allows application user management and definition of user permissions by Windows resources (domains, Active Directory, etc.). In such case the PROMOTIC system no longer manages the individual users.
3) Permissions for protected operations of the application: It allows to protect the critical part of the application from an unauthorized access of the application users (for example opening or closing a panel, stopping the application, etc.).

Permissions are configured on the "Permissions" pageof appropriate objects (for example Permissions, see: Description of the Permission page).

Setting permissions for individual operations makes use of created groups of users.

4) Login of local users of the application (local user identity validation).
5) Login the network users of the application (validating the identity of a network user).
6) Validating the permissions of the logged user in order to execute the protected operation.

Login of local users of the application (local user identity validation)

The users of the running local application can use the PROMOTIC features to log in as the local user of the application with an unique name and password, and so get the appropriate permissions according to its location in the user groups. The local user can log in either from the PROMOTIC toolbar or the application designer can prepare other tools for the local login activation (the Pm.WndLogon or Pm.Logon methods are to be called).

The local user login can be either completed successfully or fail. If the login is successful, then the original local user is logged out and replaced by the new one. If the operation fails, then the original local user stays logged in.

 
System substitute not logged local user $NOUSER_LOCAL:

After the local user logs out the $NOUSER_LOCAL user is logged in automatically, that represents the not logged local user. This way the system ensures, that there is an user logged in all the time (real or substitute). User $NOUSER_LOCAL is always present in the application, cannot be deleted or renamed, but the content can be configured. User $NOUSER_LOCAL is a normal user, from the group membership configuration (used for permissions validation) and priority point of view. It can be a member of any group thus managing some basic permissions also for the user that is not currently logged in.

 
The PmUser object in a local application:

In a running application, there is a permanent object of the PmUser type, that represents the currently logged local user. This object contains the runtime information of the current user (for example user private data) and also contains the reference to the configuration of corresponding local user (for example name, group membership, priority) (see Users). If the local user is logged out then it refers to $NOUSER_LOCAL user. For local application operation validation the PmUser object is used (currently logged real or substitute local user). The operation is performed only if the user (PmUser object) has the necessary permissions. Otherwise the operation fails with an error message.

Login the network users of the application (validating the identity of a network user)

The login name and password is sent with each network request. If the Web browser (Chrome, Firefox, Edge, InternetExplorer ..) is a remote client and HTML pages generated by the PmaWeb object are displayed, then the user is prompted by the standard window to enter the name of the network user and the password that are then sent to PROMOTIC application together with the request. If the main window of the network application is a workspace (PmaWorkspace), then the user of running network application can use the resources of the PROMOTIC system to login as network user with assigned name and password and this way obtain the corresponding permissions according to its user group. If the PROMOTIC application client is a remote client, then the name of the network user and the password is set directly in individual components that enable connection to remote Web server component (for example in parameters of the PmaData.ReadFromWeb method, in the "Parameters for type: Remote connection over WEB" configurator, etc.). The PROMOTIC Web server detects the IP address of the remote client automatically. The PROMOTIC system then uses the name, password and IP address of the network user for authorization check of the specific operation.
 
System substitute not logged network user $NOUSER_NET:

If a request with no login name and password comes, then the $NOUSER_NET user is logged in automatically, that represents the not logged network user. This way the system ensures that each remote request will always have its user (real or substitute). User $NOUSER_NET is always present in the application, cannot be deleted or renamed, but the content can be configured. User $NOUSER_NET is a normal user, from the group membership configuration (used for permissions validation) and priority point of view. It can be a member of any group thus managing some basic permissions also for the user that is not currently logged in.

 
Strict and non-strict login policy:

There are two ways of managing network user logins in the application. The strict and non-strict mode see "Strict mode of network users login into the application requiring the use of both name and password" configurator. In case of the strict mode, the $NOUSER_NET user is irrelevant because the strict policy always requires an user login before opening the permission. In case of non-strict mode, the $NOUSER_NET user is used for each network request with no name and password (not logged user).

 
Creating the PmUser object while evaluating the request permission:

While evaluating the request, the object of the PmUser type is created, that represents the logged (or substitute) user. This object contains the runtime data of the currently logged user (for example user private data) and also contains the reference to the configuration of corresponding network users (one or two) (for example name, group membership, priority) (see Users). In case of not logged network user it holds the reference to $NOUSER_NET user. The PmUser object is used for validating the permissions of network operations (currently logged or not logged network user and possibly the user defined by IP address). The operation is performed only if the user (PmUser object) has the necessary permissions. Otherwise the operation fails with an error message.

From the configuration point of view, there are two network user types:

1) The users defined by name and password (the IP address may be also included). In the non-strict mode, the $NOUSER_NET user is also included in this type.
2) The users defined only by an IP address.

The important fact is, that the network request may simultaneously correspond to two users. The first of the first type (name and password) and the second type (IP address only). If the request corresponds with two users, then one user satisfying the permission is sufficient for the validation. The PmUser object, that represents the logged (or substitute) user, then contains the reference to the configuration of both corresponding network users. The properties and methods then retourn the values modified according to the context (more important of the two objects, merging the values, etc.).

There can be multiple network users logged into the application simultaneously (PmUser objects). The number of simultaneously logged network users into the PROMOTIC server is basically limited only by the number of network client licenses.

 
Detailed explanation of the interaction between the server and the client whil validating the user:
For the PROMOTIC application client type, each request is sent with name and password.
For the Web browser client type, the following rules arevalid:
1) It either is or is not logged into the PROMOTIC server (with name and password).
2) It remebers all visited pages on the server and for every access sends the name and password together with the request, if the name and password have been requested during the last access (is not waiting for the 401-Unauthorized code rejection).
3) When accessing the page, that have not been visited so far, first sends the request without the name/password request.
4) If it receives the 401-Unauthorized code rejection (the server requests name and password), then:
a) If is logged into the PROMOTIC server, then it generates automatically a new request including the name and password.
b) If is not logged into the PROMOTIC server, then it displays the standard login window prompting for name and password and then generates a new request including the name and password.
 
There are the following rules for PROMOTIC server:
1) Processing the request without the login name and password differs in the PROMOTIC system according to the strict or non-strict mode (see "Strict mode of network users login into the application requiring the use of both name and password" configurator).
a) If the strict mode, then after receiving remote request with no name/password, the request is denied immediately with the 401-Unauthorized code.
b) If a non-strict mode, then after receiving the remote request with no name/password, the operation is opened with was delivered (not logged user $NOUSER_NET and IP address). If the permission is sufficient (based only on IP address, or all users are permitted by the $ANY/$ANY_NET group or the non-logged user had the permission), then the operation is executed and one object of the PmUser type is created, that represents the logged network user . If the permission is not sufficient, then the request is denied with the 401-Unauthorized error code.
2) Processing the request with provided name and password. The PROMOTIC server will try to find the network user with corresponding name/password (the IP address is also checked if required). Regardles if the corresponding network user has been found or not, the PROMOTIC server will try to find another user wit hthe correct IP address (if there is a user which has the permissions based only on the IP address). Then the operation is authorized to the one (or two) users (according to name/pass and the IP address). If the permissions of the user(s) are sufficient, then the operation is executed and one object of the PmUser type is created, that represents the logged network user.

Validating the permissions of the logged user in order to execute the protected operation

The evaluation itself (over the PmUser object)follows these steps:
1) Determine if the request for an operation was created locally or in the network.
2) Determine the identifier of the local or network user that evoked the request. In case of combination of the network users defined by name/password and IP address there may be two identifiers.
3) Comparing the user identifier with the user groups according to permissions. The operation is allowed if the user is a member of one of the mentioned user groups. If there are two identifiers present, the comparison is executed for each one and one successful result is sufficient for operation execution.

All comparations when finding an occurance of the user identifier in the list of authorized groups, ends with the success immediately after finding the group where the user is a member. If the whole list is passed and the user is not found in it, then the search ends with the failure and the operation is not allowed.

System users and user groups overview

The system users and user groups do not differ from the normal users and user groups from the permission validation point of view. It means that the system user groups can be used for validating the protected operations, while the system users can be inserted into the user groups. It is not recommended to use the $ANY, $ANY_LOCAL and $ANY_NET user groups for the permissions of protected operations. It is recommended to use the system user groups $OPER and $ADMIN instead and eventually own created groups. Including the $NOUSER_LOCAL or $NOUSER_NET users into the specific user grouop, will cause no need to log in by name/password for permission validation bind to this group (similar as using the $ANY). Removing the $NOUSER_LOCAL or $NOUSER_NET users from specific user group, will cause the permission validation to require the user to be logged in. This concept allows to modify the behavior of the whole application just by including or removing the $NOUSER_LOCAL and $NOUSER_NET users in specific user groups while there is no need to modify the particular permissions for protected operations. On the other hand, using the $ANY, $ANY_LOCAL and $ANY_NET user groups in the protected operation permissions would require to modify particular settings separately on miltiple locations in the application.

Note! In the local application, it must be ensured, that the basic application parts, used for displaying the local user login dialogs are enabled also for non-logged user. The reason is that the local application uses the currently logged local user to validate the permissions. The most important are the application main window (PmaWorkspace) and the window with toolbar (PmaPanel). This configuration is done as default after creating a new PROMOTIC application, by including the $ANY_LOCAL user group into the main and toolbar object permissions. This way the application allows the user to activate the application components used for user login. This is not required for network user because the Web browser displays the login dialog itself, at the moment the user tries to access the protected page.

 
System users and user groups overview:
$ANY: system group of users, represents any local or network user (logged-in, non-logged).
$ANY_LOCAL: system group of users, represents any local user (logged-in, non-logged).
$ANY_NET: system group of users, represents any network user (logged-in, non-logged).
$ADMIN: system group of users, represents group of users with administrator permissions.
$OPER: system group of users, represents group of users with permissions of normal user.
$NOUSER_LOCAL: system user, represents a non-logged local user.
$NOUSER_NET: system user, represents a non-logged network user.

Examples of usage

The examples are to be used just as inspiration for using the specific users. There are multiple possibilities and possible combinations available. It is possible to use non-logged users, users logged by name/password, remote users on specific IP address, or to combine the permissions for name, password and IP address together for one user. The combinations may also be created dynamically, when the user logs in by name/password from a specific IP address (one user only by name/password and the second user just by IP) and thus having two configuration users simultaneously and having the permissions of both (the resulting combination of permissions can then be much higher).
 
The whole application is protected by login: For this purpose, the strict login mode is used (see "Strict mode of network users login into the application requiring the use of both name and password" configurator). This way it is requested for all network users to log in by name/password. The non-logged user $NOUSER_NET is irrelevant for this mode. In the permissions, it is not recommended to use the $ANY and $ANY_NET user groups, that would soften the need for login. In the network application, the Web browser logs in just once and then it provides the name/password on request. It is the recommende application mode.
 
Part of the applicaion protected by login, another part (administrative) protected by login: For this purpose, the non-strict login mode is used (see "Strict mode of network users login into the application requiring the use of both name and password" configurator). The non-logged user $NOUSER_NET is included into the $OPER user group (for the unprotected application part), but is not included into the $ADMIN user group. This way it is ensured, that the normal part of the application enabled for the $OPER user group, will not require login for the network user. When trying to access the administrator parts of the application, enabled only for $ADMIN user group, the network user will be requested to log in.
 
The whole application is not protected by login: For this purpose, the non-strict login mode is used (see "Strict mode of network users login into the application requiring the use of both name and password" configurator). The non-logged user $NOUSER_NET is included into the $OPER and $ADMIN user groups. This way it is ensured, that both normal and administrative parts of the application are accessible for the network user without the need to log in.
 
Part of the application protected by users from specific IP addresses, the administrative part protected by login: For this purpose, the non-strict login mode is used (see "Strict mode of network users login into the application requiring the use of both name and password" configurator). The non-logged user $NOUSER_NET is not included into any user group. We will create the network users for specific IP addresses and include them into the $OPER group. This way it is ensured, that the network user can access the normal parts of the application from the correct IP without the need to log in. The administrative application parts will be accessible only after successful user login.
 
The administrative part of the application protected by login from specific IP address: We will create the network users with administrative permissions with both login and IP validation and include them into the $ADMIN user group. This way it is ensured, that the administrative application parts will be accessible only by users that are correctly logged in from the specified IP address.

History:
Pm9.00.02: New logging-in by names and passwords of Windows users, so the user management is then provided by Windows resources.

The logged-in user is then a member of PROMOTIC user groups based on his membership in corresponding Windows user groups.

PROMOTIC 9.0.7 SCADA system documentation - MICROSYS, spol. s r.o.

Send page remarkContact responsible person
© MICROSYS, spol. s r. o.Tavičská 845/21 703 00 Ostrava-Vítkovice