linotp.lib.policy.evaluate module¶
policy evaluation
- class linotp.lib.policy.evaluate.PolicyEvaluator(all_policies)¶
Bases:
objectpolicy 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