Removing Entitlement that also belongs to a role

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

IIQ 8.3P5.

Same issue as this thread that’s now closed: Unable to remove entitlements through Manage Access page if those are part of Roles

Essentially, if we have an entitlement assigned via LCM, it doesn’t show up as an option to remove later on if that entitlement also belongs to an IT role (just being detected…no business role is assigned, just the entitlement).

Is this the intended behavior?

2

Hi @cds21
Yes, the behavior you’re describing in IdentityIQ, where an entitlement assigned via LCM cannot be directly removed through the Manage Access page if that entitlement is also being detected as part of an IT role, is generally the intended behavior.

Here’s why and the logic behind it:

  • Source of Truth Principle: IdentityIQ operates on a “source of truth” principle. When an entitlement is assigned through an IT role (meaning, IdentityIQ detects that the user has this entitlement because they meet the criteria for an IT role that grants it), the IT role is considered the governing factor for that entitlement.
  • Role-Based Access Control (RBAC): IdentityIQ strongly promotes RBAC. If an entitlement is part of an IT role, it implies that the access is granted due to the user’s membership in that role. Trying to remove the entitlement directly via “Manage Access” would be bypassing the role’s control, which can lead to inconsistencies.
  • Re-provisioning Risk: If you were able to remove an entitlement directly that was granted by an IT role, the next time the Identity Refresh task runs, IdentityIQ would likely detect that the user still qualifies for the IT role and would re-provision the entitlement, creating an “infinite loop” of adding and removing.
3

Thanks. In this case, however, the entitlement wasn’t “granted” by an IT role. It was assigned directly as an entitlement in Manage Access (and perhaps the user also has several other entitlements and this particular bundle of entitlements is what makes up an IT role that’s required by some business role).

I guess I’m curious how IIQ expects this entitlements to be removed. Since IT roles generally aren’t requestable and there is a sticky attribute assignment for the entitlement, how does the application expect this entitlement to be removed?

4

Please check below topic about sticky entitlements

Resolving Sticky Entitlements: Common Causes and Solutions - IdentityIQ (IIQ) / IIQ Community Knowledge Base - SailPoint Developer Community

5

I understand how sticky entitlements work. I guess I’m lost on how this is the intended design. Let’s say, we have the following:

ITRole1 with 2 direct entitlements for 2 AD groups (Group1 and Group2).
BusinessRole1 with automatic assignment logic and requires ITRole1.

After an identity is terminated, they are unassigned BusinessRole1 automatically and Group1 and Group2 are removed as expected.

However, for some business reason after termination, the identity’s AD account needs Group1, and this is assigned by Manage Access by an entitlement owner. This creates an attribute assignment on the identity and the group is available to be removed via Remove Access in Manage Access.

Then for a second business reason, this identity’s AD account also requires Group2, and this also gets added via Manage Access by an entitlement owner.

Now that the user has Group1 and Group2, ITRole1 is now detected and both Group1 and Group2 are not available to be removed via Manage Access.

This is the intended behavior, you’re saying?

6

Dear @cds21

let me check with my colleagues and Experts whether my understanding is wrong.

  • IT Roles are Derived: IT roles in IdentityIQ are typically assigned based on some criteria (e.g., membership in an AD group, user’s department attribute, etc.). If a user meets the criteria for an IT role, they automatically get the entitlements associated with that role.
    LCM is for Direct Assignment/Request: The Lifecycle Manager (LCM) is primarily used for direct requests or assignments of entitlements and business roles. When you assign an entitlement via LCM, it creates a “direct assignment” record for that entitlement for the user.
    The Conflict: The problem arises when the same entitlement is both:
    Directly Assigned via LCM: IdentityIQ has a record that you explicitly asked for this entitlement for the user.
    Detected via an IT Role: IdentityIQ’s aggregation process also sees that the user has this entitlement because they belong to an IT role that grants it.
    Why You Can’t Remove It via Manage Access (LCM):

When IdentityIQ’s reconciliation process runs (e.g., during an Identity Refresh), it prioritizes the “source of truth” for entitlements. If an entitlement is detected as being part of an IT role, even if it was also assigned via LCM, the IT role’s claim to that entitlement takes precedence.

I will update you once I have answers on the expected behavior.

7

Yes, what is your requirement? normally we design the role to get assigned based on some match criteria. if user don’t match then no need to assign complete role. you can create another role that will assign access to user.

8

Hi Kumar

I explained the use case in my most recent message.