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)¶

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.
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

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)¶

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)¶

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

linotp.lib.policy.evaluate module¶

Table of Contents

Previous topic

Next topic

This Page