9.3. User rights management

This section discusses how to manage access rights of users for various services in a domain. Softnet supports two kinds of access control: Role-Based Access Control (RBAC) and Plain Access Control (PAC). Which kind of access control is used by a given site depends on the Site Structure applied to the site. The Site Structure, as you know, is provided by the service application hosted on a device and set up on the site.

To demonstrate operations with user access rights, the “Office Automation” demo project is used. This is how the project’s domain looks before assigning access rights to users.

9.3.1. Managing user rights on a site that uses RBAC

If the service application set up on the site employs role-based access control, the list of roles are displayed on the site in the “supported roles” section. In the image below, IP cameras support three user roles: “Administrator”, “Operator” and “User”:

In the SITE CONFIGURATION panel, the user roles displayed in the “supported roles” section can be assigned to domain users. Users with one or more roles are displayed in the “users” section of the site. Users without any roles are displayed in the DENIED USERS section. To the left of each domain user, there is a “>>” button that, when clicked, opens the user role editor. You can check the roles you want to assign to the user and click the “save” button. In the image below, the role editor is opened for Stewart, and the “User” role is checked:

Clicking the “save” button assigns the role to the user and moves it to the “users” section of the site:

Stewart is a Contact user associated with the contact Ben Stewart. Now he can create client entities and set up client applications that can interact with IP cameras with the rights of the “User” role. Here you can see another complete example of granting access to IP cameras to a contact.

In addition, we assign the “Administrator” role to Owner, and the “Operator” role to GuardPost. After this we have the following view of the “users” section:

9.3.2. Managing user rights on a site that uses Plain Access Control

If the service application set up on the site employs plain access control, users have a full access to the service by the fact of being added to the site. PAC is used when the service application does not require different levels of access, or the application implements its own access control mechanism.

In the SITE CONFIGURATION panel, users added to the site explicitly are displayed in the “explicit users” section. Some users may be added to the site implicitly, which is the subject of the next subsection below. Users without access rights are displayed in the DENIED USERS section. In the following image, Owner is explicitly added to the site “Alarm System” of our demo project:

In the DENIED USERS section, to the left of each domain user, there is an “add” button that, when clicked, adds a user to the site. Those users that are already added to the site has a “rem” button that, when clicked, removes a user from the site.

9.3.3. Default access rights & dedicated users

Each site has an option to specify the default rights for users to access the service. However, this only applies to users who are not marked as dedicated. The dedicated users acquire only those rights that you assign them explicitly. Using default rights may be convenient if you have more than a few users in the domain. This allows you to assign some minimum access rights to all users without having to do so explicitly for each user. Let’s look at how to apply default access rights, first when using RBAC and then when using PAC.

1) If the site employs Role-Based Access Control, you can specify a default role for all domain users by setting the “user default role” option to one of the roles declared on the site. Each user that is given a default role will have it underlined. However, if some of the users must not have the default rights, you can make them dedicated. Note that dedicated users are also underlined.

Let’s recall our demo site “Surveillance System”. Earlier, we explicitly assigned roles to three users, and two Contact users remained in the DENIED USERS section (Guest not considered):

Let’s make “User” the default role and see what happens:

Each user acquired the “User” role. As the default role, it is underlined except for the Assistant, which is explicitly assigned this role. Assume we do not want Stewart to have any access to the IP cameras, then we make it dedicated so that it could not acquire the default role:

After clicking “save” we have the following view (note that Stewart is underlined as dedicated user):

2) If the site employs Plain Access Control, you can set the “Implicit users” option to “allowed” to add the domain users to the site implicitly. The option is displayed in the “access defaults” section. However, you may want to prevent certain users from being added to the site by applying this option. In this case, you can make them dedicated. Note that implicit and explicit users have equal access rights to the service.

Let’s consider the demo site “Alarm System”. Currently, the “Implicit users” option is set to “denied”:

Clicking the “allow” button makes the “Implicit users” option allowed:

Users implicitly added to the site are moved to the “implicit users” section. To the left of each user in this section, an “exp” button is displayed, clicking on which makes the user explicitly added to the site and moves it to the “explicit users” section. Note that because Stewart is a dedicated user, the default access settings are not applied to it.

TABLE OF CONTENTS