Detailed information

Conception

The main terms are: object, access class, access rule, role and operation.

Object - logical object of an application, which is protected by "Force-Field". It could be a document that should be available only for a certain group of users, or a single project, or a task in a CRM-system. Developers of an application are free to decide what should be considered as an object protected by "Force-Field".

All objects of an application are organized into a hierarchical structure. It must contain a root object that builds the top level of the structure. Each object has only one parent object, but can have several child objects.

Access class defines access permissions for an object. Access class contains rules; relying on them the decision whether a user may or may not perform particular operation with this object is taken.

Classes support inheritance of instructions. In that case a child class inherits all rules from the base class. Sometimes you need to set special access rules for a certain object. In that case you could create an implicit class. It can be either independent, or based on an existent access class.

Access rules - a number of instructions that enable system to decide whether a user may or may not access an object.

It's possible that the class associated with a certain object doesn't contain any access rule matching given situation. If this class is not based on other class the operation is considered as forbidden.

Access rule supports explicit inheritance of decisions. In that case component checks if it is allowed to perform the requested operation with the parent object. The result (admittance or prohibition) is used to answer to the request.

Access rules are processed in the order they have in the corresponding access class.

Role - is used to simplify the management of access permissions.

Users are organized into groups (called roles). For example, users who work with articles on a web-site are organized into the "editor" role. In that case you don't need to set access permissions for each user separately, an access rule is valid for all users who play the role "editor".

List of roles the same user plays towards different system objects is inherited in compliance with hierarchical structure of objects. For example, if on the top level of the structure a user plays the role named "user" and on the deeper level another role named "editor" is added - the user is considered to play both roles at this level.

"Force-Field" supports 3 built-in roles: "everyone", "user" and "owner".

"Everyone" - any user, even not authenticated one; "user" - all authenticated users.

"Owner" is the user who actually owns this object. If the owner of an object isn't specified, the owner of the parent object is considered as owner.

Operations - actions which could be performed with an object. E.g. reading, editing, removing, synchronizing. "Force-Field" supports a single built-in operation "everything" that means all possible actions with a protected object.

Checking of access permissions

"Force-Field" is responsible for checking if it is allowed to perform a particular operation with an application object. The result of its job is the decision whether a user may or may not do it. How an application will interpret the decision received from "Force-Field" is considered to be details of application functioning.

It's important to understand the access checking mechanism of the "Force-Field".

User access a certain object to perform some operations; e.g.: "read" or "edit". Access permissions of the user are checked in the context of this object.

The checking is based on the rules contained in the access class associated with this object. System looks for a rule matching the current situation (i.e. matching role or user, requested operation) in this class; if no rule is found - starts analyzing the parent class. Further information you can find in the "Conception" section.