Permission Checking

When a user tries to access a resource, Iotellect Server determines whether access should be granted by calculating the effective permission level for the request and comparing it with the permission level required by the resource.

If Use Role-Based Permissions is enabled for the user (under Account Settings), Iotellect Server first tries to resolve the access request using the Role-Based Permissions.

The Role-Based Permissions check can return one of following results:

• Allowed — a matching role rule is found, and its permission level includes the permission level required by the resource.

• Denied — a matching role rule is found, but its permission level does not include the permission level required by the resource.

• Undefined — no matching role rule applies to the access request.

If the Role-Based Permissions result is Allowed or Denied, this result is final for the current access request. In this case, the user's regular Permissions table is not checked for the same request.

If Use Role-Based Permissions is disabled for the user, or if Role-Based Permissions are enabled but return Undefined for the access request, Iotellect Server checks the user's regular Permissions table line by line, starting from the first (topmost) one.

If the context path of the resource being accessed 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 in 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 required by the 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).

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

1. John tries to access users.abc.alerts. The permission level required to access that resource is Manager. The first line in the table, users.test, doesn't match or extend the users.abc.alerts mask, so we move on to the second line, users.* and see that it extends 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 Manager 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 Administrator permission level. His effective permission level for that context is defined by the first line in the table. It will be Manager (lower than Administrator), and thus John will be denied access to users.test.queries.

Permissions table of the default administrator:

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.

If the user's permissions are not sufficient to perform a requested operation, it will fail with the "No permissions" error.

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

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 Iotellect Server 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 Iotellect Server users may still have access to this alert, and be able to configure and monitor it. Once the administrator lets John access his alerts again, alert1 will show up under his Alerts context.

Was this page helpful?

Tell us more

Send

Thank you!