Module g4ds.authorisationcontroller

Deals with all ussues concerning authorisation / permissions.

Grid for Digital Security (G4DS)

1. Actors
2. Targets
3. Operations

In fact, an actor performs a certain action on a certain target.

• g4ds (describes all actions for G4DS)
• g4ds.control (descibes all actions for the control system of G4DS)
• g4ds.control.member (describes all actions for member control subsystem of g4ds)
• g4ds.control.member.requestmdl (is the action for requesting a member description)

Rules may either apply to an action itself or to a set of actions using the group identifier of any hierarchy.

In practise, the entire approach is based on policy files which are parsed at booting up time of G4DS and then applied to a permission matrix. The policy files have to be placed on the location as defined in the g4ds config file (config.POLICY_DIRECTORY). By default the files are loaded which are defined in the config file (config.POLICY_FILES).

The access matrix is two dimensional. Each entry inside the matrix contains an ordered list of couples (action | reaction).

For building the matrix the following steps are performed:

All requested policy files are loaded into memory using dictionaries. Afterwards the dictionaries are processed in order starting with the ruleset defined in the config file with value config.POLICY_MAJOR_RULESET_ID. Hence, the order of the policy files does not matter (at least as long as no result set id is used severeal times). The processor iterates the list of rules in the major ruleset ordered by rule id (so keep your rules in order!!!). Whenever a rule has the reaction type 'direct', the value is put directly into the access matrix. (In fact, for each possible combination of the rule for actor / target one item is appended to the list of rules for the corrosponding couple.) Whenever the rule has the reaction type 'redirect', the processing is continued with this list immedeately and, after finishing the redirected list, continued after the redirected reaction. Redirection are allowed in all rulesets; hence they may be cascaded.

For validating one request, the following steps are performed:

The authorisation controller is performing a lookup in the access matrix and this way loading the list for the requested couple of actor / target. This list is then iterated (by order as established at bootup time) and the first rule hitting the requested action is taken. Regarding the action stored for this rule the the function will return the value.

• '*' - all possible values
• 'authorities_communities' - All authorities for a community
• 'authorities_services' - all authorities for a service
• 'Cxxxxxx' (in conjunction with type attribute 'membergroup') - All members of the community with ID Cxxxxxx
• 'Sxxxxxx' (in conjunction with type attribute 'membergroup') - All members of the service with ID Sxxxxxx

Author: Michael Pilgermann

Contact: mailto:mpilgerm@glam.ac.uk

License: GPL (General Public License)