Every user account has a permissions table property. This table is used to determine the permission level effective for a given context. This is the permission level with which attempts to gain access to that context. If the effective permission level of a user includes the permission level of a resource, access will be granted.
The permissions table has two columns: Context Mask and Permission Level. When a user tries to access some resource, AggreGate Server uses the permissions table to decide whether access should be granted or not. See permission checking for details.
|
The context mask and permission level are similar to the "Security Domain" and "User Role" concepts that are widely used to describe the architecture of many security systems. |
The last line of the permissions table must define permission level for all contexts, i.e. contain the "*" Context Mask.
|
Every resource (variable, function, event, action) of a context has its own permission level, but there is no way to give users a dedicated permission level to a certain context resource. It's only possible to set a user's permission level for the context as a whole. This means that the system provides pre-defined scenarios of interaction with a context, and permission levels for context resources are assigned to avoid access conflicts in these scenarios. For example, if a certain context action changes some variables of this context, the action's permission level must include the permission levels of any accessed variables, otherwise the action may internally fail with Access Denied error even though the user was allowed to execute it. |
