Promotic
WikipediaLinkedInYoutubeTwitterFacebook

User management, permissions and login system

The system of users allows designers to create protected PROMOTIC applications. In the application there is a configurable list of all local and network users of the application with appropriate passwords. The PROMOTIC system also includes the local and network user management for running applications. If there is a need to create a protected application, the operation will be executed only if the current user has the necessary rights. If not, the operation fails with an error message.
 

Subsystem consists from following logical parts:

1) Definition of application user groups list that allows creation of all logical application user groups (e.g. $ADMIN, $OPER, GUESTS etc.). Configuration is performed in the development environment, on the Users page.
2) The definition of a users list of the application that allows to create a list of all application users with the definition of the user type (local and/or network), to set passwords for users and define user group membership. In the development environment the configuration is performed on the Users page. In the running application either by means of the Pm.WndEditUsers method in the users edit window or directly by Pm.AddUser and Pm.RemoveUser methods.
3) Definition of permissions for protected operations of the application, enabling to protect the critical part of the application from an unauthorized access of the application attendance (for example opening or closing a panel, stopping the application, etc.). Permissions are configured in Permissions page of appropriate objects (for example Permissions, see: Description of the page Permissions). 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 operators 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, the original local user is logged out and replaced by the new one. If the operation fails, the original 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, representing 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 cn be a member of any group thus managing some basic access rights also for the user that is not currently logged in.

 
The User object in a local application:

In a running application, there is a permanent object of the User type, representing 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 User object is used (currently logged real or substitute user). The operation is performed only if the User has the necessary rights. 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 (InternetExplorer, Firefox, Chrome...) is a remote client and HTML pages generated by the PmWeb 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 (PmWorkspace) then the operator 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 client of the application 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 PmData.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 automaticaly. 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, representing 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 cn be a member of any group thus managing some basic access rights 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 the configurator "Strict mode of network users login into the application requiring the use of both name and password". 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 User object while evaluating the request permission:

While evaluating the request, the User type object is created, representing 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 User 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 has the necessary rights. Otherwise the operation fails with an error message.

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

1) User 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 User object type, representing 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 (User type objects). The number of simultaneously logged network users into the PROMOTIC server is basically limited only by the number of network client licences.

 
Detailed explanation of the interaction between the server and the client whil validating the user:

For the Internet Explorer client type, the following rules arevalid:

1) Internet Explorer either is or is not logged into the PROMOTIC server (with name and password).
2) Internet Explorer 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 the Internet Explorer first sends the request without the name/password request.
4) If the Internet Explorer receives the 401-Unauthorized code rejection (the server requests name and password), then:
a) If the Internet Explorer is logged into the PROMOTIC server, it generates automatically a new request including the name and password.
b) If the Internet Explorer is not logged into the PROMOTIC server, it displays the standard login window prompting for name and password and then generates a new request containing the name and password.
 
For a client represented by a PROMOTIC component, each request is sent with 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 the configurator "Strict mode of network users login into the application requiring the use of both name and password").
a) In case of the strict mode, after receiving remote request with no name/password, the request is denied immediately with the 401-Unauthorized code.
b) In cse of a non-strict mode, 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), the operation is executed and one User type object is created, representing the logged network user . If the permission is not sufficient, 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 system 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 operaton is authorized to the one (or two) users (according to name/pass and the IP address). If the rights of the user(s) are sufficient, the operation is executed and one User type object is created, representing the logged network user.

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

The evaluation itself (over the User 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, 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. I.e. 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 (PmWorkspace) and the toolbar window (PmPanel). 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 users, because the Internet Explorer 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 networkuser (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 local non-logged user.
$NOUSER_NET: system user, represents a net non-logged user.

Examples of usage

The examles 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 the configurator "Strict mode of network users login into the application requiring the use of both name and password"). 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 the non-strict login mode is used (see the configurator "Strict mode of network users login into the application requiring the use of both name and password"). 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 the configurator "Strict mode of network users login into the application requiring the use of both name and password"). 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 withou 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 the configurator "Strict mode of network users login into the application requiring the use of both name and password"). 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 aprts 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.
© MICROSYS, spol. s r. o.Tavičská 845/21 703 00 Ostrava-Vítkovice