Differences

This shows you the differences between two versions of the page.

--- devel:documentation:security:dev:authorization [2020/06/22 13:45]
apeterova VsRequests permission
+++ devel:documentation:security:dev:authorization [2020/08/05 09:05]
tomiskar
@@ Line 41: / Line 41: @@
 <note important>**Policies are assigned to individual roles and thanks to that the logged in user also gets them (relation identity - IR - role - policy).**</note>
   * ''AuthorizationEvaluator'' - authorization "evaluator" - it is basically an implementation of the individual types of the rule described above. Each evaluator carries information about which domain type and which setting it supports. Some can also be universal for more domain types (e.g. children of''BaseEntity''). In order to simplify the implementation of a rule, the class ''AbstractAuthorizationEvaluator'' has been created, which can be simply inherited when adding another rule. The main evaluators will be described below. The main evaluator methods, which must be implemented (or overloaded from ''AbstractAuthorizationEvaluator''):
+    * **''getPermissions(policy, authorizable)''** - **returns a set of operations** (the set ''BasePermission''), which the currently logged in **identity can perform** with a given domain object according to the given policy (e.g. READ, UPDATE)
+    * **''getPredicate(...)''** - returns a jpa criteria **predicate**, which can be "stuck" onto a **where clause** => the query then returns a result which can be paged and ordered. The result contains data, which we have permissions for according to the given policy. It is recommended to write the predicates as subqueries with ''exists'', to prevent problems with joining tables (if, of course, it is not something simple).
     * ''supports(authorizableType)'' - which doamin type is supported by the evaluator
     * ''supportsPermissions()'' - returns true if the assigned permissions are supported. False - it defines them itself internally (e.g. ''AbstractTransitiveEvaluator'').
     * ''getAuthorities(policy)'' - **returns a set of operations** (the set''BasePermission''), which the currently logged in **identity could perform** according to the given policy (e.g. READ, UPDATE).
-    * ''getPermissions(policy, authorizable)'' - **returns a set of operations** (the set ''BasePermission''), which the currently logged in **identity can perform** with a given domain object according to the given policy (e.g. READ, UPDATE)
+  * ''AuthorizableService'' - an interface for labeling a service working with entities that it supports evaluating of policies for permissions for data. This has been added mainly because of backward compatibility - permissions for data are linked to individual agendas one by one. The policies can thus be configured only for domain types with services supporting this interface.
-    * ''evaluate(policy, authorizable, permission)'' - this is just sort of a shortcut - it returns true if the currently logged in identity can perform the given operation according to the given policy (in practice - ''contains'' to the set above)
-    * ''getPredicate(...)'' - returns a jpa criteria **predicate**, which can be "stuck" onto a **where clause** => the query then returns a result which can be paged and ordered. The result contains data, which we have permissions for according to the given policy. It is recommended to write the predicates as subqueries with ''exists'', to prevent problems with joining tables (if, of course, it is not something simple).
-  * ''AuthorizableService'' - an interface for labeling a service working with entities that it supports evaluating of policies for permissions for data. This has been added mainly because of backward compatibility - permissions for data are linked to individual agendas one by one. The policies can thus be configured only for domain types with services supporting this interface.
   * ''AuthorizationManager'' - loads and evaluates the set policies for the logged in identity throughout the application:
     * loads all the active policies according to the assigned user roles
@@ Line 95: / Line 94: @@
   * ''CHANGEPERMISSION'' - permission is evaluated, when identity's permissions is changed => ''CHANGEPERMISSION'' on contract gives permissions ''READ'', ''CREATE'', ''UPDATE'', ''DELETE'' to identity's role requests.
+===== Cache =====
+Cache is used for evaluating authorization policies and permissions by ''AuthorizationManager'':
+  * **''core:authorization-policy-cache''** - Cache stores active authorization policies of currently logged user. Cache is evicted after user log out. When authorization policies configuration is changed, then user is logged out and cache is evicted (after permissions removal only). Cache expiration is 2 hour, e.g. if user forgot to log out.
+  * **''core:permission-cache''** - Cache stores permissions (for data) of currently logged user. Cache is evicted after user log out. Cache expiration is 1 minute - if data structure is changed, then permissions are actualized after this duration. When authorization policies configuration is changed, cache is evicted (completely).
 ===== Base authorization evaluators =====
@@ Line 379: / Line 385: @@
 Permissions to identity roles. User can manipulate with his own roles. With basic settings for user you dont need this, beacause exist evaluator **IdentityRoleByIdentityEvaluator** and every identity can read all roles for identities that can read.
+==== SelfContractEvaluator ====
+@since 10.4.0
+Permissions to contracts. User can manipulate with his own contracts.
 ==== Universal request agenda (IdmRequest - evaluators) ====
@@ Line 433: / Line 444: @@
     * Code lists (IdmCodeList) | Displaying in autocomplete, selections | BasePermissionEvaluator
     * Code lists - items (IdmCodeListItem) | Displaying in autocomplete, selections | [[#codelistitembycodelistevaluator|CodeListItemByCodeListEvaluator]] or [[#codelistitembycodeevaluator|CodeListItemByCodeEvaluator]]
-  * Permission to read automatic role requests in workflow approval: Requests for automatic roles (IdmAutomaticRoleRequest) | Read, Update, Create, Delete | AutomaticRoleRequestByWfInvolvedIdentityEvaluator ( Add also autocomplete permission to IdmAutomaticRoleAttribute (if you use automatic roles by attributes) and IdmRoleTreeNode (if you use automatic roles by organizations.).
+  * Permission to read automatic role requests in workflow approval: Requests for automatic roles (IdmAutomaticRoleRequest) | Read, Update | AutomaticRoleRequestByWfInvolvedIdentityEvaluator. For create new or delete an automatic role request add another evaluator (for example BasePermissionEvaluator to choosed users). Add also autocomplete permission to IdmAutomaticRoleAttribute (if you use automatic roles by attributes) and IdmRoleTreeNode (if you use automatic roles by organizations.).
   * Permission to autocomplete form definitions (eav attributes on detail for identities, roles, etc): Forms - definitions (IdmFormDefinition) | Displaying in autocomplete, selections | BasePermissionEvaluator
   * Permission to read and solve one's requests on virtual systems: Requests on virtual systems (VsRequest) | Administration | VsRequestByImplementerEvaluator ([[tutorial:adm:modules_vs#permissions]]). If you don't want to display the VS requests agenda to all your users, then we recommend setting this permission to some other role which you will assign only to the VS implementers.