Users

Iotellect is designed to host scalable multi-user, multi-tenant applications. Ordinarily, some persons manage platform servers, some develop apps in low-code mode, some deploy and test those apps, and, finally, end users operate those apps on everyday basis. These administrators/developers and application end users (i.e. system operators) can all belong to the same company, or end users can be paying customers who purchased an Iotellect-based product or service. In such a complex environment it's extremely important to ensure overall security and restrict access to important data.

Access of all user types the platform is implemented via through user accounts. For someone to gain access to Iotellect using one of its interfaces (Web UI, API, etc), they must be authenticated and authorized by the server.

Immediately following Iotellect installation, at least one account exists in the system, default administrator. Other accounts are created on-demand.

The only default operation that does not require prior authentication is self-registration. Howerver, some dashboards and resources may be later open for anonymous users, i.e. users who didn’t complete any authorization and authentication.

Iotellect Server may have an unlimited number of user accounts. System resources are usually owned by the user who creates them. User permissions are configured by editing a permissions table defining the user's access level to each of the system resources. This lets administrators implement complex security schemes which actually reflect the user's role in the organization.

Some examples:

• Allowing one user to access/view/modify devices and resources (alerts, reports...) that belong to another user, i.e. resource sharing.

• Allowing one user (team leader) to modify the permissions of some other users (team members).

• Restricting the user's access to his own devices and resources, e.g. enabling read-only access to devices or reports.

• Temporarily suspending the user's account by revoking all permissions.

• Every record of the permissions table may define the user's access level for one resource, a group of resources, or even a sub-tree of dependent resources.

Configurable user permissions also make operators' life simpler by allowing them to view only resources that are relevant to their job. For example, the following permission schema is often used for Time and Attendance control system:

• The system administrator has full permissions.

• Company executives have access to reports.

• HR staff may view/configure employee profiles and custom shifts.

• Security personnel are allowed to view real-time entry/exit events and event history.

• IT engineers may edit report templates, create new reports, browse event history and modify employee database.

• Every user account has a set of preferences, such as time zone, date/time format, and preferred language.

Related tutorial: Granting One User Access to Objects of Another User

A user account can either match a single physical person (e.g. John Doe or Mary Shelley) or a certain role of system operators (e.g. "Los Angeles Zone Operator", "Report Designer" or "Network Engineer"). Physical person accounts (normal) can either have their own permission tables or inherit permissions from role-based accounts.

See Normal and Role-based Users for details.

Large Iotellect installations are operated by thousands of individuals, each of them inheriting one of many roles. Creating and maintaining individual user accounts for them all is too laborious. However, it's possible to authenticate users through an external system (such as LDAP or Microsoft Active Directory), while authorization (assigning user permissions) will use role-based Iotellect Server user accounts.

See External Authentication for details.

User self-registration is very helpful during the first stages of system deployment, or when providing a public cloud service. System users may create their own accounts and provide some personal information (name, e-mail, company/department, phone no., etc). Once registered, they get their own login/password pair.

See User Self-Registration for details.

Every user account owns different system objects: Alerts, Widgets, etc. The user's permission table may prevent him from accessing the contexts of other users' objects or even some of his own objects. Objects that are accessible by newly created users are defined by Default User Permissions global Iotellect Server setting.

Two contexts are used to administer users. One is the general Users context, for actions related to all user accounts. The other is the User context, corresponding to a single user account.

Was this page helpful?

Tell us more

Send

Thank you!