Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Next revision Both sides next revision
devel:documentation:security:dev:authorization [2019/02/13 08:22]
kotisovam first part moved to the admin section 		devel:documentation:security:dev:authorization [2019/05/16 09:23]
tomiskar [Settings of permissions for the Helpdesk role]
Line 1: Line 1:
-===== Base interfaces and classes =====+===== Authorization policies =====
  
-{{tag> security authorization role }}+{{tag> security authorization role policy }} 
 + 
 +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. 
 + 
 +<note info>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.</note> 
 + 
 +<note important> 
 +**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 roles. **To be able to select from the roles dial** (e.g. when requesting roles) **we need to be assigned a permission for an agenda of autocomplete for roles** ''Role - AUTOCOMPLETE'' or //Displaying in autocomplete, selections// for instance with the evaluation type ''BasePermissionEvaluator''. 
 +</note> 
 + 
 + 
 +===== Base interfaces and classes =====
  
  
Line 307: Line 330:
   * Permission to read audit: Audit | Read | BasePermissionEvaluator   * Permission to read audit: Audit | Read | BasePermissionEvaluator
   * Permission to see sent notifications: Notifications | Read | BasePermissionEvaluator   * Permission to see sent notifications: Notifications | Read | BasePermissionEvaluator
-  * FIXME add permissions to see the provisioning queue and archive+  * Permission to see provisioning operations (queue): Provisioning - operations in queue (SysProvisioningOperation) | Read | BasePermissionEvaluator 
 +  * Permission to see provisioning archive: Provisioning - archive (SysProvisioningArchive) | Read | BasePermissionEvaluator
  
 ==== Default settings of permissions for a role detail ==== ==== Default settings of permissions for a role detail ====
  • by kucerar