14.0:documentation:security:dev:authorization

Authorization policiessecurityauthorizationrolepolicydefaultuserrolepermissions

An authorization policy determines which permissions a user in CzechIdM has.

A policy is assigned to a role and everyone with this role gains the permissions determined by the policy as well.

assigning permissions in CzechIdM via ordinary roles enables managing permissions for CzechIdM by a standard mechanism

The default role "User" gives implicit permissions, which all the users in CzechIdM have. This role is not assigned explicitly, it is simply default and is always applied (see the following chapter).

A new agenda of authorization policies = permissions for data and agendas has been tied to a role. Assigning permissions makes available both agendas on the front-end (or rather REST endpoints on the back-end) and permissions for data (make records in these agendas available) to the logged in user. Permissions for agendas (REST endpoints) are assessed according to the set permissions.

The main idea is that if an agenda supports a permission for data, then we cannot see any data in the default state. To see some data we need to get / comply with a configured policy, which we get based on our assigned roles. Between policies is OR operator ⇒ we adding permissions for data.

How permissions for agendas and permissions for data work together:

To see some data, we need to have at least one role with a policy assigning the permissions.

Real life example:

Let there be an agenda of identities. To be able to select from the identity dial (e.g. in filters) we need to be assigned a permission for an agenda of autocomplete for identities Identity - AUTOCOMPLETE or Displaying in autocomplete, selections for instance with the evaluation type BasePermissionEvaluator.

Base interfaces and classes

BasePermission - a base permission; can be added in modules; basic permissions for the IdM core, which are identical for both permissions for access into agendas and for permissions for data:
- ADMIN - administration - includes all operations ⇒ wildcard - there is no need to list all the operations (see IdmAuthorityHierarchy)
- READONLYADMIN - from IdM 13.0.14, universal read permission - includes all passive operations (AUTOCOMPLETE, COUNT, READ), applicable for APP group only, defining user that can view anything in IdM but cannot perform any change (read only administrator)
- COUNT - number of records - The number of entities that match the filter. We do not have to have permissions for reading a agenda and details.
- AUTOCOMPLETE - displaying of data in the autocomplete. We do not have to have permissions for reading a agenda but we need to select it somewhere from a menu (e.g. when requesting a role we can select it but if we had only this permission, we would not see the role in the role agenda). This permission enables reading a "trimmed" detail (we might limit this).
- READ - a permission for reading the whole log - the log is displayed in the agenda.
- CREATE - creating of new logs in the agenda
- UPDATE - log updating
- DELETE - log deleting
- EXECUTE - execute operations (start, cancel etc.)
GroupPermission - a group (target) permission (e.g. USER, ROLE …). A group of base permissions. This group is assigned specific domain classes (e.g. IdMRole) and determines which base persemissions it contains ⇒ what can be done with the given type.
By linking a group with a base permission we get an authority - for example ROLEREAD, IDENTITYWRITE.

A Special group is APP, which is meant for the application administrators or for special permissions - the authority APPADMIN is created by linking a group with a base permission. The authority owns all the permissions in the application. Other permission is APPSKIPCASADMIN you can use this permission to enable login directly via IdM even if login via CAS is enabled.</note> * AuthorizationPolicy - a policy according to which the permissions for a specific agenda (attribute groupPermission) and specific domain type (attribute authorizableType) are evaluated. It determines an evaluator (AuthorizationEvaluator) with specific settings (attribute ConfigurationMap) and which base permissions (attribute basePermissions) can be acquired if the evaluation passes. <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 ofBaseEntity). 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 setBasePermission), which the currently logged in identity could perform 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. * 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 * connects predicates according to the policies into the where clause when searching or auto-completing data (AuthorizableService.findSecured(…)) * evaluates available operations over the given domain objects on the level of REST controllers. <note important> Configured authorization policy is persisted with selected AuthorizationEvaluator implementation class ⇒ when evaluator implementation is renamed or moved into different package, then authorization policy with modified evaluator has to be reconfigured too (or change script has to be provided). </note> <note important> When implementing getPermissions or getPredicate evaluator's method, don't forget to check identity is logged in securityService.isAuthenticated(), if evaluator cannot be used in public endpoints. </note> <note important> When implementing getPredicate evaluator's method, don't forget to check policy has evaluated permission assigned hasPermission(policy, permission). </note> ===== Additional base permissions ===== For some entities was added additional base permissions, which extends BasePermission above. ==== Identity ==== * PASSWORDCHANGE - permission is evaluated, when identity's password is changed. * MANUALLYDISABLE- Deactivate identity manually. Enables bulk action and quick dashboard button. * MANUALLYENABLE- Activate identity manually. Enables bulk action and quick dashboard button. * CHANGEPERMISSION - permission is evaluated, when identity's permissions is changed ⇒ CHANGEPERMISSION on identity gives permissions READ, CREATE, UPDATE, DELETE to identity's role requests. * CHANGEPROJECTION - @since 10.2.0 - Change identity form projection. * CHANGEUSERNAME - @since 10.3.0 - Change identity login. * CHANGENAME - @since 10.3.0 - Change identity firt name, surname and titles. * CHANGEPHONE - @since 10.3.0 - Change identity phone. * CHANGEEMAIL - @since 10.3.0 - Change identity eamil. * CHANGEEXTERNALCODE - @since 10.3.0 - Change identity personal number. * CHANGEDESCRIPTION - @since 10.3.0 - Change identity description. * SWITCHUSER - @since 10.5.0 - logged user can login as selected user (switch user). ==== Role ==== * CANBEREQUESTED - role, which can be requested. Used in role request and bulk actions for assign role. * CHANGEPERMISSION - @since 11.1.0 - create role request for changing identity permissions on related role - usable for role guarantees. ==== Identity role ==== * CANBEREQUESTED - role, which can be requested. Used in copying assigned roles by other identity. ==== Identity contract ==== * CHANGEPERMISSION - permission is evaluated, when identity's permissions is changed ⇒ CHANGEPERMISSION on contract gives permissions READ, CREATE, UPDATE, DELETE to identity's role requests. * CANBEREQUESTED - @since 11.1.0 create role request for changing (ADD only) identity permissions on related contract. ===== 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 ===== ==== AbstractAuthorizationEvaluator ==== Adds the default implementation of the AuthorizationEvaluator methods. It is used as a parent for the other evaluators. ==== AbstractTransitiveEvaluator ==== Serves as a parent for evaluating permissions according to the derived objects - for example, I have a permission for the assigned role if I have a permission for the identity, etc. See the children of this abstract class below (IdentityContractByIdentityEvaluator). === Parameters === * Use permissions (include-permissions) - Only selected permissions can be used from owner permissions transitively. Configuration property has to be used in evaluator configuration properties (in evaluator form attributes) and getPredicate method has to check evaluated permission is selected (see IdentityContractByIdentityEvaluator for example). ==== BasePermissionEvaluator ==== Serves for assigning the configured permission for the configured domain type - for all the data of the given type. It can be used when we want to give an access to an agenda including the access to all data. It is used, for example, for an admin with the configuration - any type (permissions for all the Identifiable children) + BasePermission.ADMIN . It can also be used for assigning the base permission for displaying data during autocomplete (see BasePermission.AUTOCOMPLETE above). <note>BasePermissionEvaluator is also used for simple sharing of an agenda which does not support permissions for data yet. Agendas which do not support permissions for data yet are not linked to the domain object, which can be see on the front-end as well. No other evaluator can be selected for these agendas</note> ==== UuidEvaluator ==== "Shares" the object with the given uuid. It is suitable when we are not able to configure another, more general rule - simply put - when somebody needs to see only one log from the whole agenda, it can be "shared" via the identifier (it would be nice not to enter the uuid directly in the configuration but to use autocomplete … coming soon). ==== CodeableEvaluator ==== "Shares" the object with the given identifier so that it is possible to enter uuid of the code of the given entity. For this evaluator, it is necessary to choose the entity type for which it is intended - does not work across entities. ==== SelfIdentityEvaluator ==== Gives currently logged user a permission to work with his own identity. ==== IdentityByFormProjectionEvaluator ==== @since 10.3.0 A permission for identities by user type. === Parameters === * User type (form-projection) - Add permission to selected user type or to default type (user without type is specified). ==== SubordinatesEvaluator ==== A permission for contracts which are my subordinates. Overloadable filters are used for evaluating subordinates or managers. ==== SubordinateContractEvaluator ==== @since 10.3.0 A permission for identities which are my subordinate contracts. Overloadable filters are used for evaluating subordinate contracts or contract managers. ==== IdentityContractByIdentityEvaluator ==== Gives a permission for industrial relations according to the permission for identity ⇒ e.g. if I have a permission to read an identity, I have a permission to read its IR. AbstractTransitiveEvaluator is used here. === Parameters === * Use permissions (include-permissions) - Only selected permissions can be used from identity permissions transitively. <note warning>Prevent to combine with IdentityByContractEvaluator - configure one of them.</note> ==== IdentityByContractEvaluator ==== @since 10.3.0 Gives a permission for identity according to the permission for identity contract ⇒ e.g. if I have a permission to read an contract, I have a permission to read its identity. <note warning>Prevent to combine with IdentityContractByIdentityEvaluator - configure one of them.</note> ==== ContractGuaranteeByIdentityContractEvaluator ==== Gives a permission for guarantees of a industrial relation (setting a guarantee "directly") according to the permission for a industrial relation ⇒ e.g. If I have a permission to read IR, I have a permission to read its guarantees. AbstractTransitiveEvaluator is used here. If I have a permission to edit IR, I have a permission to edit (add or delete) its assigned guarantees. ==== IdentityRoleByIdentityEvaluator ==== Gives a permission for assigned roles according to the permission for the identity ⇒ e.g. If I have a permission to read an identity, I have a permission to read its assigned roles. AbstractTransitiveEvaluator is used here. If I have a permission to edit the identity, I have a permission to edit (add or delete) its assigned roles. ==== IdentityRoleByContractEvaluator ==== @since 10.3.0 Gives a permission for assigned roles according to the permission for the contract ⇒ e.g. If I have a permission to read an contract, I have a permission to read its assigned roles. AbstractTransitiveEvaluator is used here. If I have a permission to edit the contract, I have a permission to edit (add or delete) its assigned roles. Logged identity can see / edit roles assigned to managed contracts only. ==== IdentityRoleByRoleEvaluator ==== @since 9.7.12 Gives a permission for assigned roles according to the permission for the role definition ⇒ e.g. If I have a permission to read an role, I have a permission to read its assigned roles. AbstractTransitiveEvaluator is used here. If I have a permission to edit the role, I have a permission to edit its assigned roles. It's usable mainly with can be requested permission - enables copying assigned roles from other identity. === Parameters === * Can be requested only (can-be-requested-only) - Add permission for role requests only (can be requested). Usable, when assigned roles need to be copied from another user. Other permissions will not be added.<note tip>If you want to enable copying all assigned roles (the same behavior < @9.7.12), then configure BasePermissionEvaluator with Can be requested permission to all assigned roles (IdmIdentityRole).</note> ==== RoleGuaranteeEvaluator ==== Gives a permission to work with roles which I guarantee. Role guarantee can be configured by: * identity - concrete identity can be selected as role guarantee * role - identities with selected role assigned will be role guarantees. This evaluator solves both ways (or). Evaluator can be used for UC, when role guarantee can assign his roles to users (@since 11.1.0). The authorization policies have to be set as follows: * Permission to work with guaranteed roles: Roles (IdmRole) | View in select box (autocomplete), Read, Update, Delete, Can be requested, Change roles | RoleGuaranteeEvaluator * Permission to all identities: Users (IdmIdentity) | Read | BasePermissionEvaluator * Permission to assign new role to all contracts: Contracted positions (IdmIdentityContract) | Can be requested | BasePermissionEvaluator * Permission to read all assigned roles: Assigned roles (IdmIdentityRole) | - | IdentityRoleByIdentityEvaluator * Permission to assign guaranteed roles: Assigned roles (IdmIdentityRole) | Can be requested only:true | IdentityRoleByRoleEvaluator ==== AuthorizationPolicyByRoleEvaluator ==== Gives a permission for authorization policies according to the permission for a role ⇒ e.g. if I have a permission to read a role, I have permission the authorization policies assigned to it. If I have a permission to edit a role, I have a permission to edit (add or delete) authorization policies assigned to it. ==== RoleTreeNodeByRoleEvaluator ==== Gives a permission for automatic roles according to the permission for a role ⇒ e.g. if I have a permission to read a role, I have a permission to read the automatic roles assigned to it. if I have a permission to edit a role, I have a permission to edit (add or delete) the automatic roles assigned to it. ==== ConfigurationEvaluator ==== Gives a permission for application configuration (read, set…). If we want to get permissions for the secured configuration items, we need to set the parameter secured to true. ==== RoleCanBeRequestedEvaluator ==== Assigns permissions for a role according to the role attribute "canBeRequested". This means that if I have a role with this evaluator, I will get permissions only for those roles the attribute of which "canBeRequested" is set to true. ==== RoleAccountByRoleEvaluator ==== Gives a permission for accounts in system according to the permission for the role ⇒ e.g. If I have a permission to read a role, I have a permission to read its accounts in system. AbstractTransitiveEvaluator is used here. ==== RoleCatalogueAccountByRoleCatalogueEvaluator ==== Gives a permission for accounts in system according to the permission for the role catalogue ⇒ e.g. If I have a permission to read a role catalogue, I have a permission to read its accounts in system. AbstractTransitiveEvaluator is used here. ==== SelfRoleRequestEvaluator ==== Gives currently logged user a permission to work with his own role requests. This functionality can be configured another way - by combination RoleRequestByIdentityEvaluator and SelfIdentityEvaluator with adding permission CHANGEPERMISSION. CHANGEPERMISSION on identity gives permissions READ, CREATE, UPDATE, DELETE to identity's role requests automatically. ==== RoleRequestByIdentityEvaluator ==== Gives a permission for role requests according to the permission for the identity ⇒ e.g. If I have a permission to read a identity, I have a permission to read its role requests. CHANGEPERMISSION on identity is wildcard here - it gives permissions READ, CREATE, UPDATE, DELETE to identity's role requests. AbstractTransitiveEvaluator is used here. ==== RoleRequestByWfInvolvedIdentityEvaluator ==== Gives a permission to work with role requests which I has to approve. All involved identities (approver, applicant, implementer …) will have this permission. This policy is needed for workflow approval, where approver doesn't have a permission to read applicant. Approver will be applicant's manager (guarantee) in more cases, but even some "stranger" can have approval task assigned. ==== TreeAccountByRoleEvaluator ==== Gives a permission for accounts in tree node according to the permission for the role ⇒ e.g. If I have a permission to read a role, I have a permission to read its accounts in tree node. AbstractTransitiveEvaluator is used here. ==== FormAttributteByDefinitionEvaluator ==== Gives a permission for form attributes according to the permission for the form definition ⇒ e.g. If I have a permission to read a form definition, I have a permission to read its attributes. AbstractTransitiveEvaluator is used here. ==== FormAttributteByCodeListEvaluator ==== @since 9.4.0 Gives a permission for form attributes according to the permission for the code list ⇒ e.g. If I have a permission to read a code list, I have a permission to read its attributes. ==== CodeListItemByCodeListEvaluator ==== @since 9.4.0 Gives a permission for code list items according to the permission for the code list ⇒ e.g. If I have a permission to read a code list, I have a permission to read its items. ==== CodeListItemByCodeEvaluator ==== @since 10.3.0 Gives a permission for code list items according to the permission for the code list and item codes. === Parameters === * Code list (codelist) - Items from selected code list. * Items (item-codes) - Add permission to code list items by their codes. All items from selected code list will be used as default (use comma as separator - more item codes are supported). ==== VsRequestByImplementerEvaluator ==== For show requests only for assigned implementers. With this evaluator can user show and edit only requests where is implementer (directly or from roles). ==== ReadAccountByIdentityEvaluator ==== <note important>This evaluator assignes only READ permission.</note> For show accounts only for identities witch have relation (via identity-account entity) on the accounts. With this evaluator can user show accounts where is owner. ==== IdentityAccountByAccountEvaluator ==== For show identity-accounts only for identities witch have permissions on the accounts. With this evaluator can user show and edit only identity-accounts where is owner for the accounts. ==== ReportByReportTypeEvaluator ==== @since 12.2.0 Gives currently logged identity permission to work with a specified report. The report is specified by executor name (e. g., 'identity-report'). Only one report can be used; if you need to give access to multiple reports, create the permission multiple times. This evaluator limits which report executors are returned as available by ReportManager. For generated reports, the user is able to see EVERY report of the type which was created. To download a report, a simple READ permission is not enough, a CREATE or ADMIN permission is needed. ==== SelfReportEvaluator ==== Gives currently logged identity a permission to work with his own reports ⇒ logged identity is report creator. ==== IdentityFormValueEvaluator ==== @since 8.2.0 <note tip>Since version 8.2.0, it is possible to define permissions not only for identity as a whole, but also for individual attributes. This means that it is now possible for one user to view (or edit) all his attributes, and only one attribute for the other.</note> <note important>The permissions control for a particular attribute is now only available for extended attributes (EAV).</note> Permissions to identity form attribute values. By definition (main if not specified) and attrinute codes (all if not specified). Evaluating authorization policies for identity extended form attributes has to be enabled by configuration. Configure permissions for form definitions together with this evaluator - FORMDEFINITION_AUTOCOMPLETE is needed for read / update form values in this definition. === Parameters === * Form definition (form-definition) - Select definition, which contains attributes. Main definition will be used as default. * Attributes (attributes) - Add permission to attributes. All attributes from selected form definition will be used as default. All attributes or attribute codes (use comma as separator). * Logged user only (self-only) - Add permission to currently logged user only. Logged user doesn't get permissions to other users attributes. * By permission to update user (owner-update) - Add permission to attributes of users, which can be updated by the logged user (for example, when logged user can update identity, then he can update attributes too). * By permission to read user (owner-read) - Add permission to attributes of users, which can be read by the logged user (for example, when logged user can read identity, then he can update attributes). ==== IdentityContractFormValueEvaluator ==== @since 10.2.0 <note tip>Since version 10.2.0, it is possible to define permissions not only for contract as a whole, but also for individual attributes. This means that it is now possible for one user to view (or edit) all his attributes, and only one attribute for the other.</note> <note important>The permissions control for a particular attribute is now only available for extended attributes (EAV).</note> Permissions to contract form attribute values. By definition (main if not specified) and attrinute codes (all if not specified). Configure permissions for form definitions together with this evaluator - FORMDEFINITION_AUTOCOMPLETE is needed for read / update form values in this definition. === Parameters === * Form definition (form-definition) - Select definition, which contains attributes. Main definition will be used as default. * Attributes (attributes) - Add permission to attributes. All attributes from selected form definition will be used as default. All attributes or attribute codes (use comma as separator). * By permission to update contract (owner-update) - Add permission to attributes of contracts, which can be updated by the logged user (for example, when logged user can update contract, then he can update attributes too). * By permission to read contract (owner-read) - Add permission to attributes of contracts, which can be read by the logged user (for example, when logged user can read contract, then he can update attributes). ==== RoleCatalogueRoleByRoleEvaluator ==== @since 9.0.0 Permissions to assigned role catalogue relations by role. If i have permission to role, i have permission to role catalogue relations. ==== RoleCompositionBySubRoleEvaluator ==== @since 9.0.0 Permissions to business roles by sub role. If i have permission to role, i have permission to business roles (compositions) with this role defined in sub role relation. ==== RoleCompositionBySuperiorRoleEvaluator ==== @since 9.0.0 Permissions to business roles by superior role. If i have permission to role, i have permission to business roles (compositions) with this role defined in superior role relation. ==== RoleGuaranteeByRoleEvaluator ==== @since 9.0.0 Permissions to assigned guarantees (by identity) by role. ==== RoleFormAttributeByRoleEvaluator ==== @since 9.4.0 Permissions to role attributes (subdefinition) by role. ==== RoleGuaranteeRoleByRoleEvaluator ==== @since 9.0.0 Permissions to assigned guarantees (by role) by role. ==== ContractPositionByIdentityContractEvaluator ==== @since 9.1.0 Permissions to assigned other contract positions by identity contract. If i have permission to identity contract, i have permission to other contract positions. ==== SelfProfileEvaluator ==== @since 9.2.0 Gives currently logged user a permission to work with his own profile. ==== ProfileByIdentityEvaluator ==== @since 9.2.0 Permissions to profiles by identity. If i have permission to identity, i have permission to their profile. === Parameters === * By permission to read user (identity-read) - Add permission to profile of users, which can be read by the logged user (for example, when logged user can read identity, then he can update her profile). ==== SelfIdentityRoleEvaluator ==== @since 9.3.0 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) ==== Universal request agenda ==== RoleByRoleCatalogueEvaluator ==== @since 10.3.0 for LTS version is available similar evaluator in extras module. Documentation for the evaluator is available there. ==== IdentityByTreeNodeEvaluator ==== @since 10.3.0 for LTS version is available similar evaluator in extras module. Documentation for the evaluator is available there. ===== Default policies ===== The configuration of default permissions for agendas and data for all logged in users is carried out through the default role according to the application configuration. The default role can have, similarly to other roles, configured permissions for agendas and data. After logging in, these permissions will be filled in the context of the logged-in user (authorities and authorization policies) - the role itself does not figure in the assigned roles of the user. The default role can be used mainly for adding base permissions for the autocomplete (of roles, identities) and the like. <note tip>The business roles are supported with the default role ⇒ the user will get all authorization policies from default and all sub roles.</note> ===== Examples of configuration ===== ==== Default settings of permissions for an identity profile ==== This is a typical setting for the userRole - regular user as defined in the installation package. If we want to read an identity profile including its assigned roles and IR, to enable password change and to request roles, it is possible to set the default role authorization policies as follows: * Permission to read one's own identity: Users (IdmIdentity) | Displaying in autocomplete, reading, Change password, Change roles | SelfIdentityEvaluator * Permission to read the assigned identity roles: Roles assigned to users (IdmIdentityRole)| - | IdentityRoleByIdentityEvaluator * Permission to request roles (which can be requested): Role (IdmRole) | Can be requested | RoleCanBeRequestedEvaluator (since the version 9.7.12) * Permission to request roles by copy them from other identity (which can be requested): Assigned roles (IdmIdentityRole) | Can be requested only: true | IdentityRoleByRoleEvaluator * Permission to read contracts according to identity: Industrial relations (IdmIdentityContract) | Use permissions: View in select box (autocomplete), Read, Change roles | IdentityContractByIdentityEvaluator * Permission to read other contract positions according to contract: Other contract positions (IdmContractPosition) | - | ContractPositionByIdentityContractEvaluator * Permission to read guarantees of IR: Industrial relation guarantees (IdmContractGuarantee) | - | ContractGuaranteeByIdentityContractEvaluator * Permission to read one's own role requests: Role requests (IdmRoleRequest) | Read, Delete, Update, Create | SelfRoleRequestEvaluator * Permission to read role requests according to identity: Requests for assigned roles (IdmRoleRequest) | - | RoleRequestByIdentityEvaluator * Permission to read role requests in workflow approval: Requests for assigned roles (IdmRoleRequest) | Read, Update, Create, Delete | RoleRequestByWfInvolvedIdentityEvaluator * Permission to read and execute for tasks: Workflow - tasks | Read, Execute | BasePermissionEvaluator (since the version 7.7.0) * Permission to read and change indetity profile: Identity profile (IdmProfile) | Read, Update, Create | SelfProfileEvaluator (since the version 9.2.0) * Enabling the autocomplete for entities: * Users (IdmIdentity) | Displaying in autocomplete, selections | BasePermissionEvaluator * User profile (picture) (IdmProfile) | Displaying in autocomplete, selections | BasePermissionEvaluator * Role (IdmRole) | Displaying in autocomplete, selections | BasePermissionEvaluator * Role catalog (IdmRoleCatalogue) | Displaying in autocomplete, selections | BasePermissionEvaluator * Industrial relations (IdmIdentityContract) | Displaying in autocomplete, selections | BasePermissionEvaluator * Structure types (IdmTreeType) | Displaying in autocomplete, selections | BasePermissionEvaluator * Tree nodes (IdmTreeNode) | Displaying in autocomplete, selections | BasePermissionEvaluator * Accounts (AccAccount) | - | ReadAccountByIdentityEvaluator (← use this only when using acc module) * Identity accounts (AccIdentityAccount) | - | IdentityAccountByAccountEvaluator (← use this only when using acc module) * Connected systems | Displaying in autocomplete, selections | BasePermissionEvaluator * Scheduler (IdmLongRunningTask) | Displaying in autocomplete, selections | BasePermissionEvaluator * Code lists (IdmCodeList) | Displaying in autocomplete, selections | BasePermissionEvaluator * Code lists - items (IdmCodeListItem) | Displaying in autocomplete, selections | CodeListItemByCodeListEvaluator or CodeListItemByCodeEvaluator * Permission to read and solve one's requests on virtual systems: Requests on virtual systems (VsRequest) | Administration | VsRequestByImplementerEvaluator (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> <note tip>From version 9.7.12 it's required CANBEREQUESTED permission for copying roles into request by other identity.</note> === Manager and subordinates === If you want to enable the managers of the users to read their subordinates and change their permissions on managed contracts only: * add following permissions to the userRole: * Users (IdmIdentity) | View in select box (autocomplete), Read | SubordinatesEvaluator * Contracts (IdmIdentityContract) | View in select box (autocomplete), Read, Change roles | SubordinateContractEvaluator * Assigned roles (IdmIdentityRole) | - | IdentityRoleByContractEvaluator<note tip>This configuration is available from version 10.3.0. If you are using some older version, add one permission instead: * Users (IdmIdentity) | View in select box (autocomplete), Read, Change roles | SubordinatesEvaluator With this setting manager will see even other contracts, which not manages (⇒ all identity contracts) and can assign role to other contract. This is the reason, why new authorization policies and setting was introduced in version 10.3.0. </note> ==== Default settings of permissions for delegations ==== Default settings of permissions for delegations are defined in the role 'Delegation (delegationRole)'. <note tip>You can see a detailed configuration of evaluators with comments here: InitDelegationRoleProcessor</note> ==== Settings of permissions for the Helpdesk role ==== The Helpdesk role as defined in the installation package should have following additional permissions: * Permission to read and change passwords of all identities: Users (IdmIdentity) | Displaying in autocomplete, selections, reading, change password, count | BasePermissionEvaluator * Permission to read audit: Audit | Read | BasePermissionEvaluator * Permission to see sent notifications: Notifications | Read | BasePermissionEvaluator * Permission to see provisioning operations (queue): Provisioning - operations in queue (SysProvisioningOperation) | Read | BasePermissionEvaluator * Permission to see provisioning archive: Provisioning - archive (SysProvisioningArchive) | Read | BasePermissionEvaluator ==== Settings of permissions for virtual system implementer ==== The virtual system implementer (~approver) role should have following additional permissions: * Permission to admin virtual system requests: Requests on virtual systems (VsRequest ) | Administration (all) | VsRequestByImplementerEvaluator ==== Default settings of permissions for a role detail ==== If we want to read and edit roles where we are a guarantee, including the assigned permissions, automatic roles and accounts on target system, the authorization policies can be set as follows: * Permission to read guaranteed roles: Role (IdmRole) | Reading, Editing | RoleGuaranteeEvaluator * Permission to read configured role guarantees: * Role authorizers - by identity (IdmRoleGuarantee) | - | RoleGuaranteeByRoleEvaluator * Role authorizers - by role (IdmRoleGuaranteeRole) | - | RoleGuaranteeRoleByRoleEvaluator * Permission to read automatic roles (tree) by role: Automatic roles (IdmRoleTreeNode) | - | RoleTreeNodeByRoleEvaluator * Permission to autocomplete automatic roles (tree): Automatic roles (IdmRoleTreeNode) | Displaying in autocomplete, selections | BasePermissionEvaluator * Permission to read automatic roles (attributes) by role: * Automatic roles (attributes) (IdmAutomaticRoleAttribute) | Displaying in autocomplete, selections, Read | BasePermissionEvaluator * Rules for automatic roles (attributes) (IdmAutomaticRoleAttributeRule)| Read | BasePermissionEvaluator * Permissions to read request for automatic roles (both): * Requests for automatic roles (IdmAutomaticRoleRequest) | Read | BasePermissionEvaluator * Requests for automatic roles (rules of the attributes) (IdmAutomaticRoleAttributeRuleRequest) | - | AutomaticRoleRuleRequestByRequestEvaluator * 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 read permissions by role: Permission (IdmAuthorizationPolicy) | - | AuthorizationPolicyByRoleEvaluator * Permission to read accounts: Accounts in system | Read | BasePermissionEvaluator * Permission to read accounts relations by role: Role accounts (AccRoleAccount) | - | RoleAccountByRoleEvaluator * Permission to read assigned catalogue items by role: Role catalog - assigned roles (IdmRoleCatalogueRole) | - | RoleCatalogueRoleByRoleEvaluator * Permission to read defined business roles (role composition): * Business roles definition (IdmRoleComposition) | - | RoleCompositionBySuperiorRoleEvaluator * Business roles definition (IdmRoleComposition) | - | RoleCompositionBySubRoleEvaluator * Permission to autocomplete form definitions: Forms - definitions (IdmFormDefiniton) | Displaying in autocomplete, selections | BasePermissionEvaluator * Role attributes (subdefnition) (IdmRoleFormAttribute) | - | RoleFormAttributeByRoleEvaluator ==== Default settings of permissions for a code list admin ==== If wee want to configure application code list, the authorization policies can be set as follows: * Permission to admin code lists: Code lists (IdmCodeList) | Admin | BasePermissionEvaluator * Permission to admin code list items by code lists: Code lists - items (IdmCodeListItem) | - | CodeListItemByCodeListEvaluator * Permission to admin code list extended attributes: Forms - attributes (IdmFormAttribute) | - | FormAttributteByCodeListEvaluator ==== Settings of permissions of identity basic attributes ==== If we want to enable for currently logged identity change all basic identity attributes (e.g. login, first name, surname), the authorization policies can be set as follows: * Permission to update identity and attributes: Users (IdmIdentity) | Update, Change phone, Change personal number, Change note, Change login, Change user type (projection), Change email, Change first name, surname and titles | BasePermissionEvaluator <note tip>Can be combined with subordinates evaluator to enable update attributes for managers only. When identity is created, then CREATE permission is needed only - additional permissions are evaluated for UPDATE identity only.</note> <note important>This configuration is required from version 10.3.0 for update basic identity attributes.</note> ==== Settings of permissions of identity form (extended) attribute values ==== If we want to enable for currently logged identity read / update for some form attributes (e.g phone) from some form definition (e.g. from main definition) on identity detail (tab more information), the authorization policies can be set as follows: * Permission to autocomplete main form definition: Forms - definitions (IdmFormDefinition) | Displaying in autocomplete, selections | UuidEvaluator - enter main definition (for identities) identifier * Permission to update phone attribute: Forms - values (IdmIdentityFormValue) | Read, Update | IdentityFormValueEvaluator - select form definition same as above, enter phone as attributes * and check logged user only checkbox, if currently logged user can edit just itself. Logged user will not get permissions to edit other users. ==== Settings of permissions of contract form (extended) attribute values ==== If we want to enable for currently logged identity read / update for some contract form attributes (e.g. other manager) from some form definition (e.g. from main definition) on contract detail (tab more information), the authorization policies have to be be set as follows: * Permission to autocomplete main form definition: Forms - definitions (IdmFormDefiniton) | Displaying in autocomplete, selections | UuidEvaluator - enter main definition (for contracts) identifier * Permission to update other manager attribute: Forms - values (IdmIdentityContractFormValue) | Read, Update | IdentityContractFormValueEvaluator - select form definition same as above and enter other manager as attributes. ==== Settings which enable skipping of the role approvement ==== Assignment of roles is normally approved by the standard approval process. The approval process may be skipped by executing the bulk action for Role assignment with unchecked Approve, but only if the user has the following permission: * Permission to directly execute role requests: Role requests (IdmRoleRequest) | Execute | BasePermissionEvaluator ===== Employing policies for a new domain type - entity ===== To employ permissions for data for a new domain type it is necessary: * to implement the interface AuthorizableService for the service working with entities - is needed to use correct GroupPermission and entity type - don't reuse groups and entity types from different agendas. This requires the repository not to search for log via hql queries but via jpa criteria api (this is the main adjustment for the existing services where all the filters need to be rewritten). An example can be found in DefaultIdmAuthorizationPolicyService. * To implement a new rule if the universal ones (see above) do not suffice. In order to simplify the implementation of a new rule, the class AbstractAuthorizationEvaluator has been created, which can be simply inherited when adding another rule. Example: <code java> / * Adds permission for creating a new role only * */ @Component @Description("Adds permission for create new role") public class RoleWriteNewOnlyEvaluator extends AbstractAuthorizationEvaluator<IdmRole> { @Override public Set<String> getPermissions(AuthorizationPolicy policy, IdmRole entity) { Set<String> permissions = super.getPermissions(policy, entity); permissions.add(IdmBasePermission.CREATE.getName()); return permissions; } } </code> * the rest is taken care of by AuthenticationManager, which finds all implementations of the rules according to the application context, offers supported types and so on.