Home | Trees | Index | Help |
|
---|
Package g4ds :: Module authorisationcontroller |
|
Deals with all ussues concerning authorisation / permissions.
Grid for Digital Security (G4DS)
Theoratically, there are 3 types of objects for the permission model:In fact, an actor performs a certain action on a certain target.
Actors are always members. Targets might be either of members, communities or services. (in practise described by their ids). Operations are strings, which are organised in a hierarchy. Follow this example: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.
For the roles inside the rules you may use wildcards. Supported wildcards are:Author: Michael Pilgermann
Contact: mailto:mpilgerm@glam.ac.uk
License: GPL (General Public License)
Classes | |
---|---|
AuthorisationController |
Handles all stuff about permissions. |
Function Summary | |
---|---|
Singleton Implementation. |
Variable Summary | |
---|---|
dict |
REACTION_DICT : Dictionary of interpreted reaction strings |
String |
REACTION_NEG : String, indiicatng a negative reaction in the policies |
String |
REACTION_POS : String indicating a positive reaction in the policies |
Function Details |
---|
getAuthorisationController()Singleton Implementation. Returns the instance to the AuthorisationController class. |
Variable Details |
---|
REACTION_DICTDictionary of interpreted reaction strings
|
REACTION_NEGString, indiicatng a negative reaction in the policies
|
REACTION_POSString indicating a positive reaction in the policies
|
Home | Trees | Index | Help |
|
---|
Generated by Epydoc 2.0 on Sat Oct 22 22:52:46 2005 | http://epydoc.sf.net |