Permission Checking

When a user tries to access a resource, Iotellect Server browses his 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!