Differences

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

--- devel:documentation:security:dev:authorization [2020/06/22 08:19]
tomiskar [Default settings of permissions for an identity profile]
+++ devel:documentation:security:dev:authorization [2020/07/10 08:42]
svandav [Default settings of permissions for an identity profile]
@@ 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)
-    * ''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:
@@ Line 379: / Line 378: @@
 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 437: @@
     * 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 ( It's good to have autocomplete permission to IdmAutomaticRoleAttribute and IdmRoleTreeNode.). The permission is possibly in wrong place.
+  * 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.
 <note tip>From version 9.7.3 isn't feature manually disabled and manually enabled for user allowed by permission Identity ''UPDATE''. But exits own permissions for each operation (''MANUALLYDISABLE'' or ''MANUALLYENABLE'')</note>