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-in 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 PROMOTIC system locally or from network and must pass the
authentication process (identity check) that verifies the name and password. After successfull user authentication a specific
logged-in user (local or network) is created in the PROMOTIC system, 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 methods
Pm.LoggedUser and
Pm.GetUserInfo. A reference to currently logged-in user is also here:
Data binding UP - 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 name and password).
-
Authorization:
The process of checking whether the authenticated (logged-in) user has permission to do something (for example by usage of user groups).
Subsystem consists from following logical parts:
1) Groups of users: It allows 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" tab. It is crucial for each logged-in user to which groups of users 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: Authentication of the local user and network user is done by PROMOTIC. It allows to create a list of all application PROMOTIC users with the definition of the user type (local user and/or network user) and to set passwords for users and define user group membership.
The configuration is performed
either in the in the development environment on the "
Users" tab,
or in the running application by the
Pm.WndEditUsers method in the user edit window,
or directly by methods
Pm.AddUser and
Pm.RemoveUser.
b) Windows users: Authentication of the local user and network user is done by Windows. It allows using the Windows user login credentials. Consequently it is possible to use the list of local and global Windows groups of users (where the Windows user is a member) to create a list of user groups.
In each user group it is possible to enter a name corresponding to Windows group of users. 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" tabof appropriate objects (for example
Permissions, see: "
Permission" tab).
Setting permissions for individual operations makes use of created groups of users.
4) Login of local users of the application (local user authentication).
5) Login the network users of the application (validating the identity of the network user).
6) Validating the permissions of the logged-in user in order to execute the protected operation.
Login of local users of the application (local user authentication)
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. In the running application the local user can log in either from the 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 the 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 logged-in 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-in 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 the network user)
The login name and password is sent with each network request.
If the remote client is Web browser (
Chrome,
Firefox,
Edge,
InternetExplorer ...) 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 (the
PmaWorkspace object), 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 allow connection to remote Web server component (for example in parameters of the
PmaData.ReadFromWeb method, 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 into the application: the
strict and
non-strict mode (see the "
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) see
Example of non-strict Web setting.
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 information of the logged-in 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-in 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 not logged 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 return 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 licences.
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 automatically 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 for entering name and password and then generates a new request including the name and password.
:
1) Processing the request without the login name and password differs in the PROMOTIC server according to the strict or non-strict mode (see the "
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, all users are permitted by the
$ANY/
$ANY_NET group or the not 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). Regardless of whether the corresponding network user has been found or not, the PROMOTIC server will try to find another network user with the 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-in 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 user or network user that evoked the request. In case of combination of the network user defined by name/password and IP address there can be two identifiers.
3) Comparing the user identifier with the user groups according to permissions. The operation is enabled 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 group, will cause no need to log in by name/password for permission validation bind to this group (similarly to 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 groups of users 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 multiple locations in the application.
Note! In the running 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 object) and the window with toolbar (
PmaPanel object). 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 window itself, at the moment the user tries to access the protected page.
System users and user groups overview:
$ANY:
system user group, represents any local or network user (logged-in, not logged).
$ANY_LOCAL:
system user group, represents any local user (logged-in, not logged).
$ANY_NET:
system user group, represents any network user (logged-in, not logged).
$ADMIN:
system user group, represents user group with administrator permissions.
$OPER:
system user group, represents user group 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 only 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 "
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 only once and then it provides the name/password on request each time. It is the recommende application mode.
Part of the application protected by login, another part (administrative) protected by login: For this purpose, the non-strict login mode is used (see the "
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 the "
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 the "
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.
Changing the initial panel after a new user logs in
Practical example of switching the initial panel in the
main frame after a new user logs in (locally and on the web).
Example:
There must be one permanently open panel in the application. Typically the
Toolbar and in it in the
onPanelStartEnd event will be the following script:
JavaScriptSelect and copy to clipboard
var sPath = pMe.PmPanel.Methods.GetUserInfo();
if (Pm.IsValid(sPath))
{
Pm.CreateView(null, sPath, "", "target:main;").Open();
}A new designer method GetUserInfo is created in the methods of this panel which returns the path to the desired panel according to the id of the user that is logging in.
JavaScriptSelect and copy to clipboard
switch (pContext.User.Id)
{
case "USER_OPER": return "/Reports/PanelReport";
case "USER_ADMIN": return "/Trend/PanelTrend";
default: return "/MainPanel";
}This solution is now only suitable for web clients. For local users it is still necessary in the
onUserLogonEnd event of the
PmaRoot object to add the following:
JavaScriptSelect and copy to clipboard
if (pEvent.User.Type == 1)
{
var sPath = pMe.Pm("/Workspace/Toolbar").Methods.GetUserInfo();
if (Pm.IsValid(sPath))
{
Pm.CreateView(null, sPath, "", "target:main;").Open();
}
}