Multi-Tenancy
AggreGate may have an unlimited number of user accounts mapping a complex hierarchy of tenants or structure of a large corporation. Every attempt to access the server’s unified data model is validated according to permissions of an authorized user. Active system objects (such as alerts or models) inherit permissions of their owners once they access the unified model.
User Permissions
User permissions are configured by editing a permissions table defining the user's access level to each of system resources. This lets administrators implement complex security schemes which reflect the user's role in the organization. Some examples:
- Allowing one user to access/view/modify devices and resources (alerts, reports, etc.) that belong to another user, i.e. resource sharing.
- Allowing one user (team leader) to modify 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 a permissions table may define the user's access level for one resource, a group of resources or even a subtree of dependent resources.
Example:
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:
- System administrator has full permissions.
- Company executives have access to reports.
- HR staff may view/configure employee profiles and custom shifts.
- Security personnel is 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.
Normal and Role-based Users
A user account can either match a single physical person (e.g., John Doe or Mary Shelley) or a specific role of system operators (e.g., "Log-Angeles Zone Operator", "Report Designer" or "Network Engineer"). Physical person accounts can either have own permission tables or inherit permissions from role-based accounts.
External User Authentication
Large installations are operated by hundreds 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 LDAP server (such as Microsoft Active Directory), while authorization (assigning of user permissions) will use role-based AggreGate Server user accounts.
User Self-registration
User self-registration is very helpful during initial stages of system deployment. System users may create their accounts and provide some personal information (name, e-mail, company/department, phone number, and so on). Once registered, they get their own login/password pair.
Self-registration can save lots of time for an administrator during initial deployment. When the system installation is over and production use starts, self-registration should be disabled for the sake of security.
