Security and Permissions

Tibbo AggreGate has flexible and highly customizable security architecture. Most system resources have an associated permission level. A permission level describes who may access the resource. Currently, there are three permission levels: None, User and Administrator.

Resources having associated permission levels include:

Every user account has a permissions table that defines a user's permission levels for groups of contexts specified by context masks.

Permission Levels

A Permission level defines if access to some resource is allowed. It works like this: if the permission level of a user requesting access includes the permission level of the requested resource, access is granted. Otherwise, it is denied.

LinkServer operates with three permission levels:

If you wish to check the permission level required to access a particular context, variable, function, event or action, please see Context Reference.

Example 1:

If the permission level of a user requesting access to a certain resource is User and the required permission level for the resource is Admin, access will be denied because User level does not include Admin.

Example 2:

If the permission level of a user requesting access to a certain resource is User and required permission level for the resource is User, access will be granted because User level includes User.

Default Permission Level Of A Context

Every context has a default permission level. In order to be able to execute some operations with this context, a user must have this permission level or a higher one for it. Specific variables, functions, events or actions may require other permission levels than a default level.

The default permission level defined for almost all context in the LinkServer is User. Here is a list of all exceptions (contexts whose default permission level differs from User):

Example 1

Default permission level of the Root Context of LinkServer is None. It means that even non-authenticated users may execute some actions with this context. But the Restart Server and Stop Server actions that are defined in this context require Admin permission level in this context. Thus, only users whose permissions table define Admin permission level to the Root context will be able to stop and restart the server.

Example 2:

Default permission level of the User context is User. But the Delete action defined in this context has an Admin permission level. Thus, a user having the User permission level for this context will be able to edit the account properties, view its status and execute other actions, but will not be able to delete it. The Admin permission level is required for that.

Permissions Table

Every user account has a permissions table property. This table is used to determine the effective permission level. The Effective permission level of a user in a certain context is the permission level which he uses to attempt and gain access to that context. If the effective permission level of a user includes the permission level a resource, his attempt will succeed and access to the resource will be granted.

The permissions table has two columns: Context Mask and Permission Level. When a user tries to access some resource, LinkServer uses the permissions table to decide whether access should be granted or not. See the permission checking section for details.

The last line of the permissions table must define permission level for all contexts, i.e. contain "*" Context Mask.

DEFAULT PERMISSIONS TABLE

When a new user account is created, LinkServer builds a default permissions table for it. The contents of this table depends on the account name, and on the contents of two LinkServer global properties: Additional Permissions For New Users and Default User Permissions . If all items are enabled in Default User Permissions, and the Additional Permissions table is empty, the permission table for new accounts will be quite simple:

The first line of this permissions table declares User-level access to all contexts that are defined under the user's own User context (e.g. users.NAME_OF_USER.alerts etc.).

Access to contexts of all other LinkServer users is denied by the second line, setting the None-level permissions for them. Thus, the effective permission level for the context users.user123.widgets will be None (Of course, if the new account is not user123).

The third line defines User-level to all other contexts that are not related to user accounts. This prevents a new user from executing administrative actions. For example, a new user will not be able to re-configure the External Device Server because the Default Permission Level of the External Device Server context is Admin. Stopping and restarting of the LinkServer will be also prohibited because the Stop server and Restart server actions (defined in the Root Context) require Admin-level access to this context.

The items in Default User Permissions property are listed under Default User Permissions. If they're all disabled, the permissions table of a new account will contain several additional restrictive records:

These additional records prevent user from accessing two global contexts (Global Common Data container and Reports) along with some of his own contexts (Alerts, Queries etc.).

All records from Additional Permissions For New Users table are added in the top of permissions table and thus have highest priority. Assuming that we have two records in Additional Permissions table:

If all items of a Default User Permissions are enabled, we'll have the following permissions table for a new user:

Permission Checking

When a user tries to access a resource, LinkServer browses his permissions table line by line, starting from the first one.

If the context path of the accessed resource matches or extends the context mask defined in the current line of the permissions table, the permission level defined in this line will be used as the effective permission level for this path. Once a matching line is found, no other lines are matched. So, for example, if you start the table with the * context (i.e, that's the first line in the table) no other lines will ever be checked, because that line matches all contexts. That's why * is always the last line in the table.

The effective permission level determined at the previous step is then compared with the permission level required by the resource being accessed. If the effective permission level includes the permission level of resource, access is granted. Otherwise, it is denied.

If the context path of the accessed resource doesn't match or extend any mask defined all throughout the table, the effective permission level for the resource being accessed is defined by the last line in the permissions table, because it always defines the permission level for all contexts (* Context Mask).

Example 1

Supposing that the permissions table of the user john looks like this:

1. John tries to access user.abc.alerts. The permission level required to access that resource is User. The first line in the table, users.abc.alerts, doesn't match or extend the users.test mask (the first line), so we move on to the second line, users.* and see that it does extend users.test. This second line specifies None as the permission level, and so access will be denied.

2. John tries to access event_filters.filter1, requiring a User permission level. John's effective permission for event_filters.filter1 will be defined by the third line in the table, and thus access will be granted.

3. John tries to access users.test.queries, requiring an Admin permission level. His effective permission level for that context is defined by the first line in the table. It will be User (lower than Admin), and thus John will be denied access to users.test.queries.

Example 2

Permissions table of default administrator looks as follows:

The effective permission level of the default administrator for any context is Admin, because all context paths extend the * mask. So the administrator may execute any operation in any context.

Temporarily Disabling Access To Some Objects

When a user's permission table is adjusted so as to keep them from accessing some of their own resources, the resources are not actually destroyed or affected in any way. In fact, some other user may have access to these resources even if their owner has no access to them.

Example

john, the guy from the last example, has an Alerts context, users.john.alerts. This path always exists. Initially John can access his Alerts, because Default User Permissions let him do so. He logs onto LinkServer and creates an alert, alert1. Then, the administrator adjusts John's permissions table so that John can no longer see his Alerts context (for example, by adding a record with Context Mask users.john.alerts and Permissions None to the beginning of the table). This does not destroy alert1. It doesn't even stop it from working. Some other LinkServer users may still have access to this alert, configure and monitor it. If the administrator lets John access his alerts again, alert1 will show up under his Alerts context.