| Both sides previous revision
Previous revision
Next revision
|
Previous revision
Next revision
Both sides next revision
|
devel:documentation:roles [2019/01/16 12:25]
tomiskar |
devel:documentation:roles [2019/03/15 12:24]
tomiskar |
| <- .:identities | Identities ^ .:start | Documentation ^ .:role_change | Roles change request -> | <- .:identities | Identities ^ .:start | Documentation ^ .:role_change | Roles change request -> |
| |
| {{tag> role incompatible business automatic }} | {{tag> role incompatible business automatic SoD Segregation Duties }} |
| |
| ====== Roles ====== | ====== Roles ====== |
| |
| ===== Incompatible roles ===== | ===== Incompatible roles ===== |
| Segregation of Duties can be defined by incompatible roles. Definition is almost the same as business roles definition above. | **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 |}} | {{ :devel:documentation:incompatible-role-definition.png |}} |
| |
| Old generation of CzechIdM had a feature of [[https://blog.bcvsolutions.eu/neslucitelnost-roli/|Role's incompatibility]]. The incompatibility means that you can define restrictions on roles A nad B that will forbid any user or process to assign those to roles together to the same user. In new generation of CezchIdM we have a similar feature now. However, due to our experiences from CzechIdM deployments on projects the incompatibility is "soft". It means that CzechIdM will allow the user to have incompatible roles assigned to the identity, but an administrator/security manager will be notified about this incident. Security also have tools to generate reports with users and their incompatible roles - report is developer in the report module with name ''Identities - assigned incompatible roles''. | 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 identity has incompatible roles assigned, then warning with incompatible role definition is shown. The same warning is shown on business role definition (business role contains incompatible sub roles) and when identity requests new roles (for example currently assigned role is incompatible with the new one requested). | 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. |
| |
| |
| |
| <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> | <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> |
| | |
| | ===== Duplicate role ===== |
| | |
| | Role can be duplicated by prepared bulk action. Bulk action is available after roles to be duplicated are selected in the roles table. |
| | |
| | {{ :devel:documentation:screenshot_from_2019-03-15_13-11-55.png?600 |}} |
| | |
| | Action provide features: |
| | * **Select environment** - role will be duplicated to selected environment with the role's base code preserved. 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**. |
| | * **Duplicate role attributes** - creates (or updates) configured role attributes. |
| | * **Duplicate sub roles** - creates (or updates) sub roles by business role definition (recursively). |
| | * **Duplicate automatic roles** - creates (or updates) configured automatic roles. |
| | |
| | <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. |
| | |
| | |
| ====== Read more ====== | ====== Read more ====== |
| |
| * [[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]] |
| ===== Devel guide ===== | |
| * [[.security:dev:authorization|Authorization policies]] | ===== Admin guide ===== |
| * [[.identities:dev:contractual-relationship#automatically_assigned_roles|Automatic roles by organization structure]] | * [[.roles:adm:authorization_policy|Authorization policies overview]] |
| * [[.roles:dev:automatic-roles-by-attribute|Automatic roles by attribute]] | * [[.roles:adm:authorization|Permissions Setting Mechanism]] |
| | * [[.roles:adm:automatic_roles|Automatic roles overview]] |
| * [[.roles:dev:automatic_role_request]] | * [[.roles:dev:automatic_role_request]] |
| | |
| | ===== Devel guide ===== |
| | * [[.security:dev:authorization|Authorization policies: base interfaces and classes]] |
| | * [[.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:duplicate-role]] |
| | |