Skip to main content
Version: Cloud

Exclusively managed assignments

A fundamental idea in Omada Identity, is that it manages access rights, also deprovisioning those access rights that it believes should no longer exist. Omada Identity deprovisions a managed access right when it no longer has a desired state.

However, to prevent access rights from being deprovisioned before a desired state has been established to begin with, during the implementation phase, you can toggle on a resource type whether assignments are exclusively managed by Omada Identity or not. Even if an assignment is not exclusively managed, according to the resource type, Omada Identity will still deprovision it if no longer has a desired state, that is, if it is used to have a desired state but no longer has one.

All CRAs have an Is managed tag which shows if a CRA is exclusively managed. A CRA is exclusively managed if either:

  • It is stated on the resource's resource type that all assignments are exclusively managed.
  • It has (or had at some point in the past) a desired state reason.

If you enable the Exclusively managed setting for a resource type, RoPE sets the Is managed tag to true on all CRAs for resources of the resource type.

RoPE also enables the Is managed setting if a CRA has a desired state reason, or if it had one specified in any previous calculation. The result is that if a CRA gets a desired state reason at any time, Is managed is set to true in all future calculations.

When an exclusively managed CRA does not have a desired state reason then RoPE sets it to Disabled=True which leads to deprovisioning in the target system, regardless of the type of provisioning you use, for example, Omada Provisioning Service, Manual, or MIM Sync.

Omada recommends that you set Exclusively managed to True on all resource types when going live with Omada Identity.

recommendation

Before going live with Omada Identity, we recommend that you configure your resource types to not be exclusively managed. If your resource types are not exclusively managed, you can safely enable provisioning before a desired state has been established for all access rights.

It is important to note that CRAs still have the Is managed setting enabled if there is or has been a desired state for it, even if the resource type does not have the Exclusively managed setting enabled. In this case, some deprovisioning actions may be unexpected. Calculated resource assignments are always set to Disabled if they had a desired state reason at one stage, and the desired state reason is removed.

If one or more resource types do not have the Exclusively Managed setting enabled, it is important that you run periodic access attestation surveys to be able to accept or reject new access rights created directly in the target systems.

Example​

The following is an example of why deprovisioning takes place after a desired state has been established for a calculated resource assignment (CRA). In the example, the resource type for the resource has not been set to Exclusively managed yet.

The identity John has a CRA for the resource Group1 with the following settings:

  • Reason: Actual Direct (Actual State reason).
  • Is managed is not enabled on the resource type
  • Has or had desired state is False on the CRA
  • Disabled is False on the CRA

The admin user, Jane, creates a role Engineer, which contains Group1, and creates an assignment policy that assigns the role to John. This makes RoPE process John again.

John's CRA for Group1 now has the following settings:

  • Reason 1: Actual Direct (Actual State reason).
  • Reason 2: Child Resource (Desired State reason).
  • Is managed is (still) not enabled on the resource type
  • Has or had desired state is now True
  • Disabled is set to False

Jane now removes the role Engineer again, and RoPE processes John once again.

John's CRA for Group1 now has these settings:

  • Reason 1: Actual Direct (Actual State reason).
  • Reason 2: Child Resource (Desired State reason).
  • Is managed is (still) not enabled on the resource type
  • Has or had desired state is True
  • Disabled is set to True

Because the CRA is now disabled, it gets deprovisioned.

Compound resources​

When an application role or an enterprise role has a child resource which is not exclusively managed (that is, Exclusively managed is not checked on the resource type of the child resource), then the unmanaged resource risks to be deprovisioned if the compound resource first gets the desired state and subsequently loses the desired state.

Example

  1. An enterprise role ER1 has unmanaged child resources CR1 and CR2.

  2. An identity has actual assignments for CR1 and CR2 in the target system.

  3. ER1 is then implicitly assigned to the identity and approved in a survey.

  4. If the assignment for CR1 is removed in the target system, then the assignment for ER1 is removed and in turn, CR2 is also removed.

The recommendation is to not only rely on survey approvals to establish a desired state for implicit assignments. Instead, configure the desired state with the corresponding assignment policies and direct assignments.