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
devel:documentation:roles [2019/03/19 06:19]
kopro [Admin guide] 		devel:documentation:roles [2022/12/15 13:45] (current)
doischert
Line 1: Line 1:
-<- .:identities | Identities ^ .:start | Documentation ^ .:role_change | Roles change request ->+<- .:contracts | Contracts ^ .:start | Documentation ^ .:role_change | Roles change request ->
  
 {{tag> role incompatible business automatic SoD Segregation Duties }} {{tag> role incompatible business automatic SoD Segregation Duties }}
Line 5: Line 5:
 ====== Roles ====== ====== Roles ======
  
-A role in CzechIdM is an entity representing a set (1 or many) of permissions/privileges on the end system or in CzechIdM itself. Users acquire roles: +A role in CzechIdM is an entity representing a set (1 or more) of permissions on the end system or in CzechIdM itself [[.roles:adm:authorization|(permission)]]. From the perspective of the identity manager, it does not matter whether the user acquires an account in a specific application, is placed in a group in LDAP, his indication is set to “can use VPN”, or permission is set for him in the application. In all these cases, a role is assigned. A simplification carried out like this allows general rules to be applied for assigning all types of permissions (~roles) in the same way.
-  * **automatically** – according to the organizational placement of the identity, identity or contract attributes +
-  * **manually** – through assigning based on the user’s request in the CzechIdM self-service or by a CzechIdM administrator. +
-  * **by business role** - roles (sub) can be assigned automatically, when other role (superior) by defined role composition is assigned manually or by some automatic role.+
  
-From the perspective of the identity manager, it does not matter whether the user acquires an account in a specific application, is placed in a group in LDAP, his indication is set to “can use VPN”, or a permission is set for him in the application. In all the cases, a role is assigned. A simplification carried out like this allows general rules to be applied for assigning all types of permissions (~roles) in the same way.+Users acquire roles: 
 +  * [[.roles:adm:automatic_roles|automatically]] – according to the organizational placement of the identity, or identities attributes like address or company.  
 +  * manually 
 +    * [[.roles:adm:role_assignment| by request]] in the CzechIdM self-service or by a CzechIdM administrator. 
 +    * [[tutorial:adm:copying| copying]] from an existing user.
  
-====== Role-differentiating icons ======+Request for a role [[.role_change|can be approved]] by a specific user, usually helpdesk, user's manager or IT security. 
  
-...to be completed +=== Business roles === 
-===== Roles and contracts =====+Roles can be aggregated into [[.roles:adm:business_roles|business roles]]. Provided role A is a subrole of role B, if role B is assigned (no matter how - automatically or manually) to the user, he or she acquires role A as well.
  
-{{ :devel:adm:idm_entities.png?1000 | Entities relations}}+=== Incompatible roles (segregation of duties) === 
 +If an identity should not be placed into Security Group A and Security Group B in MS Active Directory at the same time, we can ensure it via CzechIdM mechanism of [[.roles:adm:incompatible_roles|incompatible roles]].
  
 +===== Roles and contracts =====
 Roles are assigned to users via their contracts. If a contract is not valid (time validity) the roles on the contract are removed. In other words, the identity loses roles permissions in IdM and rights in connected systems. Roles are assigned to users via their contracts. If a contract is not valid (time validity) the roles on the contract are removed. In other words, the identity loses roles permissions in IdM and rights in connected systems.
  
-===== Roles and environment =====+{{ :devel:adm:idm_entities.png?1000 | Entities relations}}
  
-Role with the same base code could be created from / for different environment. Final role code is combined from the base code and environment identifier. When role is created (or synchronized), then role attributes can be used: +===== Automatic roles ===== 
-  * ''baseCode'' - base code without environment. If environment is not used, then ''baseCode'' value is the same as ''code'' value, e.g. **roleOne** +==== By org. structure ====
-  * ''environment'' - environment identifier, e.g. **dev**. +
-  * ''code'' - complex code. If environment is not used, then ''baseCode'' value is the same as ''code'' value, otherwise complex code is combined from base code, environment and joined with separator (''|'' by default). For example **roleOne|dev**.+
  
-===== Role permissions===== +The role can be linked to a Tree structure (e.g. a position in organizational structure). That role is assigned to and removed from a user based on adding/removing the user (via their contract or other contract position) to/from the organizational tree structure. If a contract is not valid yet, roles are assigned but are disabled until the contract starts.
- +
-Role permissions define rights for administrator actions in CzechIdM. A permission for CzechIdM is not necessarily defined for every role. A permission is, for example, READ on USERS. A user having a role with this specific permission can see the read-only detail of all identities in CzechIdM. +
- +
-{{ :devel:documentation:permission_example.png?400 |}} +
- +
-===== Role criticality===== +
-The level of criticality can be set for every role. Criticality denotes, [[devel:documentation:role_change#roles_criticality_disintegration_to_subprocesses| who approves ]] its assignment. Role can have criticality from 0 to 5. +
- +
-===== Business roles ===== +
-Business roles (composition) can be defined on role detail. Business role could contain sub roles - all sub roles are assigned automatically, when business role is assigned to identity. Sub roles has the same validity as business role. When assigned business role is removed from identity, then all sub roles are removed automatically too. Sub roles are processed on the background asynchronously (by [[devel:documentation:architecture:dev:events#identityroleassignsubrolesprocessor|processors]]), only business roles (=> direct roles) are assigned synchronously. +
-Sub roles defined by business roles are recalculated on the background (by [[devel:documentation:application_configuration:dev:scheduled_tasks:task-scheduler#addnewrolecompositiontaskexecutor|long running tasks]]), when business role definition is created or removed - sub roles are assigned to identities, which already owns business (or any superior) role.  +
- +
-{{ :devel:documentation:business_01.png |}} +
- +
-{{ :devel:documentation:business_02.png |}} +
- +
-===== Incompatible roles ===== +
-**Segregation of Duties** (SoD) can be ensured by incompatible roles. Their setup resembles that of business roles, described above.  +
- +
-{{ :devel:documentation:incompatible-role-definition.png |}} +
- +
-The old generation CzechIdM used to have a feature of [[https://blog.bcvsolutions.eu/neslucitelnost-roli/|Role's incompatibility]]. By incompatibility we mean that you can set restrictions on roles A and B that will stop any user or process from assigning these two roles to the same user at once. In the new generation CzechIdM, we now have a similar feature. The difference is, however, that our experience of CzechIdM deployments on projects have taught us that users prefer this incompatibility function to work merely as a **soft** mechanism. In other words, CzechIdM will allow a user (identity) to have incompatible roles as long as an administrator/security manager is notified about this incident. The security staff also get a new tool to generate a special report, listing all users with incompatible roles - the report is prepared in the reports module named ''Identities-assigned incompatible roles.'' +
- +
-When an incompatible role has been assigned to an identity, a **warning stating the incompatible role definition** is shown.  +
- +
- +
-==== Concurrence of incompatible roles and business roles ==== +
- +
-The same warning symbol is shown when an identity requests new role(s) which happen to be incompatible with one of the subroles nested within a business role composition. In this case, the informative symbol is ALSO shown next to a business role that IS NOT itself incompatible with the requested role.  +
- +
-In other words, the meaning of the symbol is somewhat different then: it does not mean the respective role - marked by this symbol - is incompatible, but rather it serves as an indication that one of the subroles down the business role cascade is incompatible. +
- +
- +
-{{ :devel:documentation:incompatible-role-request.png |}} +
- +
-{{ :devel:documentation:incompatible-role-request-confirm.png |}} +
- +
- +
-===== Copying roles from a user ===== +
- +
-Copying roles from a user is a new feature that allows one user to easily copy roles/permissions from another user. You can get the same roles like one of your colleagues has by simply filing a request that admin then approves or declines.   +
- +
-This feature is available in the role request detail, see the new button in the picture: +
- +
-{{ :devel:documentation:add_role.png |}} +
- +
- +
-For more information about the feature with more detailed description, please see the [[devel:documentation:roles:dev:copying_role_by_user|developer wiki page]]. +
- +
-===== Automatically assigned roles by organization structure ===== +
-The role can be linked to a Tree structure (e.g. position in organizational structure). That role is assigned to and removed from a user based on adding/removing the user (via their contract or other contract position) to/from the organizational tree structure. If a contract is not valid yet, roles are assigned but are disabled until the contract starts.+
  
 {{ :devel:documentation:automatic_roles.png?600 |}} {{ :devel:documentation:automatic_roles.png?600 |}}
  
-===== Automatically assigned roles by attribute ===== +==== By identity attributes ==== 
-The role can be also linked with value in attribute (value can be stored in Identity, Identity extended attribute, Contract and Contract extended attribute). That role is assigned to and removed from a user based on the value in the specific attribute. Recalculating of this automatic roles is done after saving identity, identity extended attribute attributes, contract and contract extended attribute attributes. All necessary attributes that defined automatic role by attribute are defined by agenda "Automatic role by attribute".+The role can be linked by value in attribute (value can be stored in Identity, Identity extended attribute, Contract and Contract extended attribute). That role is assigned to and removed from a user based on the value in the specific attribute. Recalculating of this automatic roles is done after saving the identity, identity extended attribute attributes, contract, and contract extended attribute attributes. All necessary attributes that define automatic role by attribute are defined by the agenda "Automatic role by attribute".
  
 {{ :devel:documentation:automatic_role_by_attribute.png?600 |}} {{ :devel:documentation:automatic_role_by_attribute.png?600 |}}
  
-After save identity (save from identity detail) it will be done recalculation for all automatic roles that has at least one rule with type IDENTITY, **recalculation from identity is done for all contracts for saved identity**. After save contract extended attributes (save from extended attribute detail) it will be done recalculation for all automatic roles that has at least one rule with type CONTRACT_EAV.+===== Roles and accounts ===== 
 +Roles can also be assigned directly to accounts. This is particularly when a user has multiple accounts and we want the role to apply to only one account or when we are managing technical accounts.
  
-===== Requests for change automatically assigned roles ===== +====== Read more ======
-Automatically assigned roles have a significant safety impact. When creating, editing, or deleting, it is necessary that the process is approved. For this purpose, an agenda for requests for change of automatic roles has been created.+
  
-This request gets the approval process from the criticality defined for that role. Critical role determines what process the application must accomplish to implement it. +===== Admin guide ===== 
- +  * [[.roles:adm:icons| Icons and description of roles]] 
-Processes of defined by the role criticality is defined [[https://wiki.czechidm.com/devel/dev/security/change-user-permissions?s[]=approve&s[]=role&s[]=by&s[]=guarantee#setting_of_the_approval_process_to_a_role|here]]. +  * [[.roles:adm:duplicate-roles| Copy roles]] 
-Processes for approval change of an automatic role are different then processes using for approving assign role to one user. For clarity, both processes (role assignment, change of the automatic role) are defined in one final process. +  * [[.roles:adm:authorization_policy|Authorization policies overview]] 
- +  * [[.roles:adm:authorization|Permissions Setting Mechanism]] 
-<note>Some processes used to approve role assignments to a user may not support approving changes to automatic roles (for example, approval by the supervisor). In this case, the default process is used (**approval with role guarantee**).</note> +  * [[.roles:adm:automatic_roles|Automatic roles overview]] 
- +  * [[.roles:adm:incompatible_roles|Incompatible roles]] 
-===== Duplicating roles ===== +  * [[.roles:adm:duplicit_roles|Assigned roles deduplication]]
- +
-Role can be duplicated by prepared bulk action. Bulk action is available on the roles table. +
- +
-{{ :devel:documentation:screenshot_from_2019-03-15_13-11-55.png?600 |}} +
- +
-Action provides features: +
-  * **Select environment** - role will be duplicated to selected environment. If the same as role's environment is selected or environment input is leaved empty, the role is duplicated on the same environment with suffix added into role's base code, e.g. **roleOne** => **roleOne_1**. If the different environment is selected, then duplicate with the same base code is created (or updated). +
-  * **Duplicate role attributes** - creates (or updates) configured role attributes. +
-  * **Duplicate sub roles** - creates (or updates) sub roles by business role definition (recursively). If the same environment is selected, the only role composition is created - exists sub role is used. If the different environment (~target environment) is used, then sub roles with the same environment as original are duplicated recursively into target environment. +
-  * **Duplicate automatic roles** - creates (or updates) configured automatic roles. Both automatic roles by the tree structure and by the attribute are duplicated. +
- +
-<note tip>When the role with the same base code already exist on the selected environment (environment has to be different), then new duplicate is not created, but the exists duplicate is updated.</note> +
- +
-Read [[.roles:dev:duplicate-role|more]] about action implementation and how it's possible to extend it. +
- +
-===== Deduplicating roles ===== +
- +
-...to be completed. +
- +
-====== Read more ======+
  
 ===== Admin tutorials ===== ===== Admin tutorials =====
Line 127: Line 57:
   * [[tutorial:adm:automatic_roles|Creating an automatically assigned role by organization structure]]   * [[tutorial:adm:automatic_roles|Creating an automatically assigned role by organization structure]]
   * [[tutorial:adm:automatic_roles_by_attribute|Creating an automatically assigned role by identity attribute]]   * [[tutorial:adm:automatic_roles_by_attribute|Creating an automatically assigned role by identity attribute]]
-  * [[tutorial:adm:copying|Copying roles]] +  * [[tutorial:adm:copying|Copying assigned roles from one user to another]] 
-  * [[tutorial:adm:deduplicating|Deduplicating roles]] +  * [[tutorial:adm:codeable_permission|Create a codeable evaluator]]
- +
-===== Admin guide ===== +
-  * [[.roles:adm:authorization_policy|Authorization policies overview]] +
-  * [[.roles:adm:authorization|Permissions Setting Mechanism]] +
-  * [[.roles:adm:automatic_roles|Automatic roles overview]] +
-  * [[.roles:dev:automatic_role_request]] +
-  * [[.roles:adm:copying-deduplicating-roles|Copying and deduplicating roles]] +
-  * [[.roles:adm:copying-assigned-roles|Copying assigned roles from user to user]] +
  
 ===== Devel guide ===== ===== Devel guide =====
Line 143: Line 64:
   * [[.identities:dev:contractual-relationship#automatically_assigned_roles|Automatic roles by organization structure: heredity of roles]]   * [[.identities:dev:contractual-relationship#automatically_assigned_roles|Automatic roles by organization structure: heredity of roles]]
   * [[.roles:dev:automatic-roles-by-attribute|Automatic roles by attribute, rules, and recalculation]]   * [[.roles:dev:automatic-roles-by-attribute|Automatic roles by attribute, rules, and recalculation]]
-  * [[.roles:dev:duplicate-role]]+  * [[.roles:dev:duplicate-role| Cloning roles]]
  
  • by kopro