linotp.lib.policy.processing module¶
policy processing functions
currently the external interfaces - has_client_policy - get_client_policy - search_policy
are migration wrappers, which trigger both, the legacy policy and the new policy processing to support the direct comparison of the results.
When the evaluation of the new policy engine is completed the methods starting with new_ could be moved in place
- linotp.lib.policy.processing.getPolicy(param, only_active=True)¶
Function to retrieve the list of policies.
attributes:
name: (optional) will only return the policy with the name
user: (optional) will only return the policies for this user
realm: (optional) will only return the policies of this realm
scope: (optional) will only return the policies within this scope
- action: (optional) will only return the policies with this action
The action can also be something like “otppin” and will return policies containing “otppin = 2”
- Returns
a dictionary with the policies. The name of the policy being the key
- linotp.lib.policy.processing.get_client_policy(client, scope=None, action=None, realm=None, user=None, find_resolver=True, userObj=None, active_only=True)¶
This function returns the dictionary of policies for the given client.
1. First it searches for all policies matching (scope, action, realm) and checks, whether the given client is contained in the policy field client. If no policy for the given client is found it takes the policy without a client
2. Then it strips down the returnable policies to those, that only contain the username - UNLESS - none of the above policies contains a username
then we try to find resolvers in the username (OPTIONAL)
if nothing matched so far, we try the extended policy check
- linotp.lib.policy.processing.has_client_policy(client, scope=None, action=None, realm=None, user=None, find_resolver=True, userObj=None, active_only=True)¶
This function returns the dictionary of policies for the given client.
1. First it searches for all policies matching (scope, action, realm) and checks, whether the given client is contained in the policy field client. If no policy for the given client is found it takes the policy without a client
2. Then it strips down the returnable policies to those, that only contain the username - UNLESS - none of the above policies contains a username
then we try to find resolvers in the username (OPTIONAL)
if nothing matched so far, we try the extended policy check
The difference to the get_policy is, that it restores the already installed filters for an existance check
- linotp.lib.policy.processing.is_authorized(admin_user: User, scope: str, action: str) bool¶
This internally used function checks whether the currently authenticated administrative user is authorized to perform an action in the given scope.
This method can only be used for administrative users and therefore does not take REALMS into account!
- Parameters
admin_user – the admin user to check
scope – policy scope to use (system, audit, monitoring, reporting, tools)
action – action to check in the scope (e.g. read or write)
- returns:
- authenticatedboolean
boolean value whether user is authorized
- linotp.lib.policy.processing.search_policy(param, only_active=True)¶
Function to retrieve the list of policies.
attributes:
name: (optional) will only return the policy with the name
user: (optional) will only return the policies for this user
realm: (optional) will only return the policies of this realm
scope: (optional) will only return the policies within this scope
- action: (optional) will only return the policies with this action
The action can also be something like “otppin” and will return policies containing “otppin = 2”
- Returns
a dictionary with the policies. The name of the policy being the key