Authorization

Authorization is the most important topic for every application used by several (or even many) users with different tasks, roles and (security) contexts.

Within the system authorization is done with a special access granting rule system where nearly any object and resource in the system could get an appropriate rule attached.

Where to apply

Access granting rules can be defined at several different places.

Application Definition

Within an Application Definition a section “access” could be added. This will get taken into account for every single action and data operation.

Key Value Store Collection

If there is a collection “_access” in the Key Value Store and setting “access_db” in section “sharing” of the Application Definition is “true”, then the appropriate records will get taken into account additionally for every data operation.

Key Value Store Data Records

If the data record for an operation has a section “access”, then this will get taken into account for this data record.

How to write

The access granting rules are written as an array of rule( object)s where each rule defines a condition which grants access to the appropriate resource, action and/or operation.

If there is no rule granting access, then the appropriate resource, action and/or operation is not permitted to the current authenticated user.

{
	"access": [
		{
			"scope": [
				"*"
			],
			"allow": [
				{
					"level": 7
				}
			]
		},
		{
			"scope": [
				"customers.get",
				"customers.index"
			],
			"allow": [
				{
					"level": 1,
					"group": "sales"
				}
			]
		}
	]
}

Rule

Each rule contains an array of scope( string)s and an array of condition( object)s to allow access.

Scope

A scope is given in a special syntax selecting the module, collection and/or method for the resource, action and/or operation the permission is asked for.

Every condition( object) of a rule with a matching scope( string) within its priority is evaluated.

That means, if there are matching rules of priority 1, all of them (and only these) are taken into account.

If not, then the same for priority 2. If there are no matching rules of priority 1 and priority 2, then all rules of priority 3 will be used and so on.

If there no matching rules, permission cannot be granted.

Please pay attention to the context ("module" or “collection”) of the above mentioned methods.

{
	"access": [
		{
			"scope": [
				"*"
			],
			"allow": [
				{
					"level": 7
				}
			]
		},
		{
			"scope": [
				"customers"
			],
			"allow": [
				{
					"level": 1,
					"group": "sales"
				}
			]
		},
		{
			"scope": [
				"customers:leads.update"
			],
			"allow": [
				{
					"level": 3,
					"group": "sales"
				}
			]
		}
	]
}

In the example above everything (using scope “*") is restricted to access level 7 (for security this is a good way to default).

All authenticated users of group “sales” are allowed to use module “customers”.

But only authenticated users of group “sales” with access level 3 are allowed to updated leads data.

Condition

The conditions are given as an array of condition( object)s. Each condition( object) describes the set of values which all have to match.

If several of the above mentioned fields are given in one condition( object), then all must match to have the condition grant access.