Assignments
Assignment reasons and states
All calculated resource assignments have at least one reason that indicates why the assignment was created, for example, an assignment has a reason type that indicates whether the assignment was created due to a direct assignment or an assignment policy.
In addition, a reason type belongs to a state which can be either Actual or Desired:
-
Actual state assignments represent the access that an identity currently has in the connected systems.
-
Desired state assignments represent the access that companies or organizations would like an identity to have based on assignment policies and other criteria.
The following table presents an overview of reason types and states:
Actual state
| Reason type | Description |
|---|---|
| Actual direct | The assignment was added due to the existence of a direct resource assignment in ODW. |
| Actual indirect | The assignment was added due to the existence of an indirect resource assignment, for example, an assignment due to group-in-group in ODW. |
| Unconfirmed actual | The assignment was assigned because of a provisioning claim based on a Manual or Omada Provisioning Service provisioning task. |
Desired state
| Reason type | Description |
|---|---|
| Direct | The assignment was added due to the existence of a Resource assignment data object. The resource assignment must have one of the following statuses: Inactive, Active, Obsolete, Disabled, Locked. Also, if the Resource assignment has an Active, Inactive, Active, or Obsolete status, it's only considered if the time of calculation was within its validity period (plus post-validity days). |
| Policy | The assignment was added due to the existence of an Assignment policy data object. |
| Child resource | The assignment was added due to the assignment of an Business role (or Application role) that the resource is a child of. |
| Auto account | The account assignment was added due to the identity not having an account for a system, for which the identity has a CPRA (calculated permission resource assignment), and the automatic creation of accounts has been defined for the system or a resource type. |
| Review OK | The Review OK reason (survey result) is considered as a second-class desired state, as it is taken into consideration in a secondary cycle in RoPE, and will never stand alone as the only reason for an assignment. Therefore, it can be considered more as an attribute or a flag than a proper desired state. It is recommended to always use a direct assignment or an assignment policy as the desired state, and only use the Review OK reason as a temporary desired state. |
| Additional | The assignment was added by a standard or custom extension in RoPE. |
No state
| Reason type | Description |
|---|---|
| Implicit assignment | The assignment of an Business role or Application role was added because the identity has assignments for all resources that are contained in the role. |
| Implicit child | The assignment was added due to the implicit assignment of an Business or Application role which the resource is a child of. |
Implicit assignments of roles
If an identity is assigned to all resources that are contained in a compound resource, for example, a business role or an application role, RoPE automatically assigns the compound resource itself to the identity with reason type Implicit assignment. It does not do so for disabled/deleted resources or for resources that are classified as a Permission resource.
The purposes of this are the following:
- To be able to define SoD policies on the role level and have them enforced even though an identity is not directly assigned to the roles.
- To enable access reviews where the answering persons are presented with role assignments rather than technical permissions, as the former is easier to understand from a business perspective.
Implicitly assigned compound resources are traversed by RoPE as if they were assigned in any other way. The assignments of the children get the special reason type Implicit child, instead of the Child resource.
To become implicitly assigned, a role must meet the following conditions:
- The identity is assigned to all the child resources of the role.
- None of the child resources is in disabled state. If any of them is in disabled state, then the role will not be implicitly assigned. However, if a child resource is marked as deleted, typically because it is deleted in the target system, RoPE will still assign the parent role implicitly if the remaining child resources are assigned.
The calculation of implicit assignments for new environments is disabled by default. The RoPE: Skip implicit assignments and the Skip implicit assignments for technical identities setting is set to True by default.
You can enable this functionality by setting the RoPE: Skip implicit assignments (RoPESkipImplAssns) or Skip implicit assignments for technical identities (RoPESkipImplAssnsForTechIdent) customer settings to False.
RoPE does not resolve implicit assignments for the unresolved identity, because in this case, the ownership of the underlying permissions is undefined, and therefore, an implicit role assignment would not reflect a well-defined state.