9.5:documentation:roles:adm:authorization

Permission setting mechanism

Permission setting mechanism

This is a quick overview of how to restrict or broaden users’ permissions. Basically, there are three main areas to tinker with:

agendas (parts of IdM)
scope of activities
data range (through evaluators)

Agendas (tabs or types of entities)

Currently, there are 62 areas or sections to be accessed. The logical sequence of individual agendas (or parts of CzechIdM) is indicated in a tree-like graph below. When granting permissions to users, pay attention to the hierarchy of agendas (hidden within each one of the menu items). Of the total, 19 agendas are linked directly to the main menu. Obviously, you won’t be able to access other related parts of the app without first granting permission to view the menu item. Nearly every menu item can be allowed separately.

These agendas are linked with the menu (in the order of appearance):

1. Dashboard + Users:

       Uživatelé (IdmIdentity)

2. Tasks:

       Workflow-úkoly

3. Organizations:

       Prvky struktur (IdmTreeNode) + Typy struktur (IdMTreeType)

4. Roles:

       Role (IdMRole)

5. Systems + Virtual Systems:

       Napojené systémy

6. Reports:

       Reporty (RptReport)

7. Audit:

       Audit

8. Notifications:

       Notifikace + Notifikace-šablony + Notifikace-konfigurace

9. Settings (each sub-item can be set separately, too):

         Configuration: Konfigurace aplikace (IdmConfiguration)
         Script definitions: Pravidla (IdmScript)
         Code lists: Číselníky (IdmCodeList) 
                     Číselníky-položky (IdmCodeListItem)
         Forms: Formuláře-hodnoty 
                Formuláře-definice (IdmFormDefinition) 
                Formuláře-atributy (IdmFormAttribute)
         Modules: Moduly 
         Generate values: Generování hodnot (IdmGenerateValue) 
         Task scheduler: Plánovač – nastavení (IdmScheduledTask) 
                         Plánovač–nastavení (IdmLongRunningTask) 
                         Plánovač–nastavení (IdmProcessedTaskItem)
         Password policies: Politiky hesel
         Tree structures: Prvky struktur (IdmTreeNode) 
                          Typy struktur (IdMTreeType)
         Role catalogue: Katalog rolí (IdmRoleCatalogue)

To further select from the list of remaining agendas, use the following tree-like graphs of the logical sequence of agendas, branching out from the respective menu item (and letting you drill down the data).

Set up roles going from left to right.
Nested choices show dependencies on the above steps.
Options in the same column are independent of each other (any given order or groupings is possible).
[Options in brackets] indicate that these ones can be skipped altogether, nothing depends on them.

USERS (MENU ITEM) Token (IdMToken) …by default upon first logging-in > > [Uživatelé – profil identity (fotka) (IdmProfile)] > > > > [Oprávnění (IdmAuthorizationPolicy)] > > > > Formuláře – definice (IdmFormDefinition) /záložka Další údaje v detailu uživatele/ > > > > Role přiřazené uživatelům (IdmIdentityRole) > > > > Pracovněprávní vztahy (IdmIdentityContract) > > > > > > Účty pro vztahy identity (pozice) (AccContractAcount) > > > > > > Další pozice (IdmContractPosition) > > > > > > Časové řezy (IdmContractSlice) > > > > > > > > Účty pro časové řezy vztahů identity (AccContractSliceAccount) > > > > > > > > Garanti časových řezů (IdmContractSliceGuarantee) > > > > > > Garanti pracovněprávního vztahu (IdmContractGuarantee) > > > > > > Žádosti pro přiřazení rolí (IdmRoleRequest) > > > > Účty na koncových systémech (AccAccount) > > > > > > Účty pro identity (AccIdentityAccount) > > > > > > Účty pro vztahy identity (pozice) (AccContractAcount) > > > > IdmTreeNode + Zobrazení v našeptávačích a výběrech

. .

ROLE (MENU ITEM) > > Agenda žádostí (univerzální) (IdmRequest) – role changes (items, role supervisor) > > > > > > Žádosti - položky žádosti (univerzální) (IdmRequestItem) > > Žádosti o automatické role (IdmAutomaticRoleRequest) – create, change automatic roles > > > > > > Žádosti o automatické role (pravidla atributů) (IdmAutomaticRoleAttributeRuleRequest) > > Role automatické (organizační struktura) (IdmRoleTreeNode) > > > > > > Role - definice business rolí (IdmRoleComposition) > > > > > > Role automatické - pravidla (atributy) (IdmAutomaticRoleAttributeRule) > > > > > > Role automatické (atributy) (IdmAutomaticRoleAttribute) > > > > > > Role- garanti dle role (IdmRoleGuaranteeRole) > > > > > > Role - garanti dle identity (IdmRoleGuarantee) > > Role – dle katalogu (IdmRoleCatalogue) > > Role – dle katalogu (IdmRoleCatalogueRole)

Activities

A user may only be allowed to do certain types of actions in respect with specific agendas:

administer all
create
read
write
(handle) up to x records only
delete
change password,
etc.

Data range set by evaluators

The range of data available to users may be further restricted and/or refined by means of evaluators. E.g. a user is only permitted to view his/her own data (SelfIdentityEvaluator), or manage the data of his/her own subordinates (SubordinatesEvaluator).
.
.
A complete list of current evaluators and data range permissions:
.
.

BASIC EVALUATORS

Areas	User types	Evaluator name	Description
user	user	SelfIdentityEvaluator	Gives currently logged user a permission to work with his own identity
user	user, manager, supervisor	SelfProfileEvaluator	@since 9.2.0 / Working with one's own profile
user	user, manager, admin	ProfileByIdentityEvaluator	@since 9.2.0 / Permissions to profiles by identity. With a permission to an identity, one has a 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 a logged user can read identity, then (s)he can update his or her profile).
users interrelated	user, manager, admin	ReadAccountByIdentityEvaluator	Only READ permission, viewing only accounts of identities which have some relation (via identity-account entity) to the accounts. A user can view accounts (s)he owns.
role, user	user, manager	RoleAccountByRoleEvaluator	Permissions for accounts in a system based on one's permissions for a role ⇒ e.g. If I have a permission to read a role, I have a permission to read its accounts in a system. AbstractTransitiveEvaluator is used here.
role, business role	user,manager,admin	RoleCompositionBySubRoleEvaluator	@since 9.0.0/ Permissions to business roles from a subrole. If I have a permission from a certain role, I have permissions to business roles (compositions) coupled with this role, defined by a subrole relationship.
role, business role	manager, supervisor	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 a superior role relationship.
user	manager, supervisor	SubordinatesEvaluator	A permission for identities which are my subordinates. Overloadable filters are used for evaluating subordinates or managers.
automatic role, role	user, manager, supervisor	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.
role request, user	user, manager, admin	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.
requests	manager, supervisor	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).
role, tree elements	manager, supervisor, admin	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.
role, user	manager, supervisor	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.
data, complete	user, manager,admin	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). 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

COMMON EVALUATORS

Areas	User types	Evaluator name	Description
contract	manager, supervisor	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.
contract	manager, supervisor	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.
contract, garant	manager, supervisor	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.
role	manager, supervisor, admin	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.
role	manager, supervisor	RoleGuaranteeByRoleEvaluator	@since 9.0.0 / Permissions to assigned guarantees (by identity) by role.
role	manager, supervisor	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 / This evaluator solves both ways (or). Guarantees.
requests	manager, supervisor, admin	Universal request agenda (IdmRequest - evaluators)
requests	user, manager, supervisor, admin	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.
requests	manager, supervisor	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.
requests	manager, supervisor	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.
reports	user, manager, supervisor	SelfReportEvaluator	Gives currently logged identity a permission to work with his own reports ⇒ logged identity is report creator.

ADVANCED EVALUATORS

Areas	User types	Evaluator name	Description
role	manager, supervisor	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.
role	manager, supervisor	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.
role, user	manager, admin	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).
role, uživatelé	user, manager,admin	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.
atributes	user, manager, admin	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.
atributes, users	specific (individual items, data sets)	IdentityFormValueEvaluator	@since 8.2.0/ 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 1for one user to view (or edit) all his attributes, and only one attribute for the other. The permissions control for a particular attribute is now only available for extended attributes (EAV). 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 - FORMDEFINITIONAUTOCOMPLETE is needed for read / update form values in this definition. Evaluating authorization policies for identity extended form attributes has to be enabled by configuration. Configure permissions for form definitions together with this evaluator - FORMDEFINITIONAUTOCOMPLETE 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).
configuration	admin	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.
customization	specific (individual items, data sets)	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.
customization	specific (individual items, data sets)	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).
evaluators	admin	AbstractAuthorizationEvaluator	Adds the default implementation of the AuthorizationEvaluator methods. It is used as a parent for the other evaluators.

Table of Contents