Describes the basics of Remote Manager's User Management.

The User Admin Service at a Glance

The User Admin service is responsible for managing the user accounts in Remote Manager. When a user logs in and tries to access a resource, first the User Admin service authenticates it i.e. checks if its name and credentials are correct. If they are, the requested resource (not the User Admin) authorizes i.e. checks if the requester has the right to perform the desired action on a particular device.

The authorization of a user depends on the role it has in the system. There are two types of roles- user and group.

The idea of separating roles into groups is to facilitate the authorization process. All users who are members of a group have all sets of rights associated with this group. So, if a user demands access to a bundle's resources, the bundle can check if the user is part of an authorized group and can grant/refuse permissions instead of searching in a long list of authorized users. For example: the smart alarm device can be switched on only by mom, dad or grandma. They all form the group called "adults". When a user tries to switch the alarm on, the bundle managing the alarm can check if the user belongs to "adults". If the user does not belong to this group, the bundle will forbid the action.

The members of a group can be users, as well as other groups. There are two kinds of members: basic and required.

• A required member of a group can be only a group, and not a user. If a group is a required member of another group, all members of the parent group must also be members of the required member group. For example: if "adults" and "local citizens" are required member groups of "voters", a child or a foreigner will not ne allowed to vote.

  
  

• A basic member can be a user or a group. A role must include at least one basic member of the group to get its access rights. However, it is not necessary to include all basic members. For example: if the "lawyers" group is a basic member of "voters", all lawyers have the right to vote but it is not necessary to be a lawyer to have the right to vote.

Remote Manager User Management Mechanism

All Remote Manager users and groups are defined in terms of the whole system, including all backend servers and managed devices. However, this does not mean that all users and groups (dynamic and parametric) can access every component of the RM system.

Backend User Admin Service

The central point of control of user information in the whole system is the Backend User Admin service, running on management servers. The RM User Admin Services residing on the backend are responsible for controlling and synchronizing user information about the entire system. They store this information in a record in the users database, and modify it each time they are notified about changes in the properties of a user. When a service on a management server receives a message from a device announcing changes in its roles, it notifies the RM User Admin Service on the control center to propagate this information to all management servers that are interested.

The console and custom admin modules are able to remotely invoke the methods of the User Admin Service and therefore manage user information - add/remove/alter users and groups. The frontend API contains methods for both creating and managing roles, as well as obtaining RM specific information.

Types of authentication

Remote Manager supports two types of authentication:

• via username and password,

• via integration with external identity providers through verification of JSON web tokens. For more information and a detailed developer guide visit Single Sign-on Integration.

  Be aware that JWTs are used only for authentication but not for authorization (user management).

  
  

  Remote Manager allows user authentication by means of a JWT except such with a 'none' algorithm.

Types of Groups

There are four types of groups: normal, parametric, dynamic and custom.

• Normal – The members of the groups are specified at the time of creation of the group, or are added later.

• Parametric – A parametric group is a group, whose name complies to the following syntax:

  <parametric_group>::=<function>(<argument>)

  <argument>::=<value>|<parameter_name>|<mask>

  The first part of the definition is called function and the second part (in the brackets) is called argument. Generally the parametric groups are used for defining relations between classes of roles, that have identical functions. The argument can be one of the listed below:

  • value – specified string not containing "(", ")", ">", "<" and "*" characters. For example:

    UserA -basic-member-of- Device-Manager(mobile-001) therefore if we have the following query:

    UserA -has-role- ?-Device-Manager(mobile-001), then the User Admin will return true.

  • parameter name – when the argument is a parameter name, if having a query for implication of a role with identical function and with a fixed value, then the parameter will be replaced with this value for the role and all of its members - basic and required. Further the role with the substituted argument is resolved like a normal group. For example:

    Device-Owner(<device>) -basic-member-of- Device-Manager(<device>) UserA -basic-member-of- Device-Owner(mobile-001)

    So having the query:

    UserA -has-role-?- Device-Manager(mobile-001), the parameter <device> will be replaced with the value "mobile-001".

    Then the following statement:

    Device-Owner(mobile-001) -basic-member-of- Device-Manager(mobile-001), will be considered as correct and the query will return true.

  • mask – when an argument is a mask (i.e. string containing one or more "*" symbols), the argument may be replaced with any value that matches to the correspondent mask, but only for the role itself and not for its members.

    UserB -basic-member-of- Device-Manager(A*)

    when having a query by invoking the hasRole() method, according to the LDAP filter rules the "ABCD" value matches to the "A*" mask. Therefore, the query

    UserB -has-role-?- Device-Manager(ABCD) will return true.

• Dynamic – The members of the dynamic groups are determined at run-time according to predefined rules. These rules are defined on the basis of user-specific properties as well as time-definition requirements. You can define rules using an LDAP filter.

• Custom – The members of the custom groups are specified by a custom bundle that can be installed on the backend. A description how to do it is available in the User Management Developer Guide.

Default RM Users and Groups

The following roles are available in the system by default.

Access Rights

Remote Manager restricts access to the maintained users. To be able to view and change the data of other users and groups, the user should have the Permission - User Management role. By default, only members of the administration group and the system user have the right to modify the set of users in RM.

• Permission - User Management(<role_name>) – The role grants user management rights for creating, updating, and deleting users and groups.

• Permission - User View(<role_name>) – The role grants rights for viewing for users and groups.

• Permission - User Create – The role grants rights for creating users and groups.

Users Storage

The users in the group are persistently stored on an RDBMS server by a Database Service, called Users Database.

As the Users Database supports mixed storage, it is also possible to load users from a directory server. In this case, the Users Database should be configured with an RDBMS server, holding the specific users.

User Interface

The RM Users Management provides user interface for management of users and groups in the console. The users and groups are managed from the Users Management section.

User Management APIs

The User Management APIs are described in the User Management Developer Guide.