linotp.lib.policy.evaluate module¶
policy evaluation
- class linotp.lib.policy.evaluate.PolicyEvaluator(all_policies)¶
Bases:
object
policy evaluation engine
- the policy evaluation is defined by an access request like:
{‘scope’: ‘admin’, ‘user’: ‘Hugo@realm’}
which is checked against all policies. As result the list of all matching policies is returned.
for refactoring the current policy evaluation
getPolicy()
could be replaced by three simple steps: by starting the policy class and adding the filters
pe = PolicyEvaluator(Context.policies) pe.set_filters(param)
followed by the evaluation:
matching_policies = pe.evaluate()
For post post processing more filters could be added - be aware filters are named and could be overwritten - and the evaluation could be made on an policy set:
pe.set_filters({‘client’: ‘192.168.178.1’}) pe.evaluate(previous_policies)
- [
Currently the filter only return a boolean value, but this could be extendend to be a tuple of (match, exact or wildcard) which will help to determin the most precise policy
]
- [
In addition to the categorization exact match/ wildcard match the initial set of policies for a request should be made. The request specific policy set will be determined at request start match for the primary access vector, which should be the:
user, client, time and in some cases the realm
]
- add_filter(key, value, value_compare)¶
- low level filter interface which adds a tuple of
key, value and comparering_method
- like
(‘user , ‘hugo’, user_list_compare)
- add_match_type(matches: Dict, matches_dict: Dict, policy: str)¶
helper to add the matches into a common dict.
- the dict will contain
{match_key: {match_type: set(of policy_names)}}
- for example:
{ ‘user’: {
‘exact:match’:set(p1,p2,p3), ‘regex:match’:set(p4), ‘wildcard:match’:set(p6) },
‘realm’: {…} }
- Parameters
matches – target dict for gathering all matches
matches_dict – the per policy match evaluation
policy – the name of the policy
- evaluate(policy_set=None, strict_matches=True)¶
evaluate - compare all policies against the access request
implementation detail: - The evaluate iterates over all given policies. - During the iteration all filter comparisons are made against
the one policy. This allows an early exit, thus if one filter does not match, all further comparison of the given policy could be skipped.
during the filter definition the comparison function is defined, thus all filter evaluation steps could be treated equal by just calling the comparison function with the actual value.
If strict_matches=True, there is a special treatment of the user matching in policies, which classifies the policies in those with a pure wildcard match, a regex match and an exact matching. If there are exact matching, this set of policies is prefered over those with a regex match, which is prefered over the set of pure wildcard ‘*’ match. Thus in case of a wildcard match, all policies are returned. If strict_matches=False, the policies get intersected over all matching policies.
- Parameters
policy_set – optional, base policies against which all filter are evaluated
- Returns
the set of matching policies
- filter_for_action(action)¶
usability wrapper for adding a filter for actions
- Parameters
user – the action
- Returns
nothing -
- filter_for_active(state=True)¶
usability wrapper for adding state filter for filtering active policies
- Parameters
state – policy state - boolean
- Returns
nothing -
- filter_for_client(client)¶
usability wrapper for adding client value for client filtering
- Parameters
client – client ip as string
- Returns
nothing -
- filter_for_name(name)¶
usability wrapper for adding a filter for the policy name
- Parameters
name – policy name - string
- Returns
nothing -
- filter_for_realm(realm)¶
usability wrapper for adding realm value for realm filtering
- Parameters
realm – realm string
- Returns
nothing -
- filter_for_scope(scope)¶
usability wrapper for the policy scope
- Parameters
state – policy state - boolean
- Returns
nothing -
- filter_for_time(time=None)¶
usability wrapper for adding time value for time filtering
- Parameters
time – datetime object or None, which referes to now()
- Returns
nothing -
- filter_for_user(user)¶
usability wrapper for adding a user filter
- Parameters
user – the user, either of type User or string
- Returns
nothing -
- has_policy(param, strict_matches=True)¶
check if a policy for example ‘scope:admin’ exists
- Param
dict with filter conditions
- Returns
list of matching policies
- reset_filters()¶
remove all filters
- select(all_matches, *args, **kwargs)¶
helper to intersect the identified sets of matches.
if no match could be made with one set, try the next one. if no intersection with any set, we return the initial one
- Parameters
all_matches – set of initial entries
*args –
list of sets, whereby the ordering defines the matching precission e.g.:
set(exact), set(regex), set(wildcard)
- Returns
set of matches
- set_filters(params)¶
set up a set of filters from a dictionary
interface to ease the migration
- linotp.lib.policy.evaluate.action_compare(policy_actions, action)¶
check if given action is in the policy_actions
- remarks: we only do the policy detection, the action evaluation is done
by using the get_action_value
- Parameters
policy_actions – the condition described in the policy
action – the name of the action, which could be a key=val
- Returns
booleans
- linotp.lib.policy.evaluate.bool_compare(policy_condition, value)¶
check if given value is boolean and matches of policy conditions
- Parameters
policy_condition – the condition described in the policy
value – the string representation of a boolean value
- Returns
booleans
- linotp.lib.policy.evaluate.cron_compare(condition, now)¶
compare a cron condition with a given datetime
- Parameters
condition – a cron condition
now – the datetime to compare with
- Returns
boolean - is allowed or not
- linotp.lib.policy.evaluate.ip_list_compare(policy_conditions, client)¶
check if client ip matches list of policy conditions
- Parameters
policy_condition – the condition described in the policy
client – the to be compared client ip
- Returns
booleans
- linotp.lib.policy.evaluate.string_compare(policy_condition, value)¶
check if given string value matches the conditions
- Parameters
policy_condition – the condition described in the policy
value – the string value
- Returns
booleans
- linotp.lib.policy.evaluate.time_list_compare(policy_conditions, now)¶
compare a given time with a time description in the policy
for the time description we use the cron format, which allows to define time frames like access from Mo-Fr and from 6:00 to 18:00:
6-18 * * 1-5 *
| | | | || | | | +– Year (range: 1900-3000)| | | +—- Day of the Week (range: 1-7, 1 standing for Monday)| | +—— Month of the Year (range: 1-12)| +——– Day of the Month (range: 1-31)+———- Hour (range: 0-23)+———— Minute (range: 0-59)
- Remark: time conditions are separated by ‘;’ as the ‘,’ is part of
the cron expression
- linotp.lib.policy.evaluate.user_list_compare(policy_conditions, login)¶
check if login name matches list of user policy conditions
- Parameters
policy_condition – the condition described in the policy
login – the to be compared user - either User obj or string
- Returns
booleans
- linotp.lib.policy.evaluate.value_list_compare(policy_conditions, action_name)¶
check if given action_name matches the conditions
- Parameters
policy_condition – the condition described in the policy
action_name – the name of the action, which could be a key=val
- Returns
booleans
- linotp.lib.policy.evaluate.wildcard_icase_list_compare(policy_conditions, value, ignore_case=True)¶
check if given string value matches the conditions
- Parameters
policy_condition – the condition described in the policy
value – the string value
- Returns
booleans
- linotp.lib.policy.evaluate.wildcard_list_compare(policy_conditions, value)¶
check if given string value matches the conditions
- Parameters
policy_condition – the condition described in the policy
value – the string value
- Returns
booleans