I’m trying to understand how IdentityIQ creates negative role assignments when a Business Role is revoked through LCM.
From my testing and the documentation, when a role assigned by an Assignment Rule is removed through an LCM Access Request, the RoleAssignment is typically marked with negative=“true”, which prevents the role from being automatically reassigned during a subsequent Identity Refresh.
My question is:
Where in the LCM process is this negative=“true” actually created?
Is it handled by a specific step in the LCM workflow?
Is it done by the Provisioner/Plan Compiler during the RemoveRole operation?
Or is there another component (such as an API or internal service) responsible for creating the negative RoleAssignment?
I’m trying to implement the same behavior in a custom workflow that revokes Business Roles assigned by Assignment Rules, and I’d like to understand the supported mechanism rather than recreating it manually.
If anyone has traced this behavior before or knows which class, workflow step, or service is responsible, I’d really appreciate your guidance.
Hi In SailPoint IdentityIQ, the negative="true"RoleAssignment is not typically created directly by the LCM workflow itself. Instead, it is created by the Identity Library/Role Assignment services that the LCM workflow invokes when processing a role removal.
Here’s how it works:
LCM Role Removal Flow
When a user submits an LCM request to remove a Business Role:
The LCM Provisioning workflow receives the request.
The workflow builds a provisioning plan containing a Remove Role request.
The plan is processed by the Provisioner/Plan Compiler.
During processing, IdentityIQ updates the identity’s role assignments through its internal role assignment APIs.
If the removed role is an Assignment Rule role, IdentityIQ creates a negative RoleAssignment (negative="true").
This negative assignment acts as an exception that tells IdentityIQ:
“Even if the Assignment Rule evaluates to true during Identity Refresh, do not assign this role.”
@IslamElkhouly If you print the plan in the start step, you can see it has all the details populated. So, basically when we submit the request, IIQ APIs creates the plan and pass it to LCM Workflow. IIQ sets it on the RoleAssignments during removals via Access Request orCertification to override auto assignment criteria set in roles and it should not assign the roles automatically during identity refresh.
I found this to be only working if the assignment rule of the Business Role is match list if it is a Rule then the negative=“true” flag is not added. I have replicated this in our lower environment. Do you know why that is?
@desibariuan This is SailPoint logic. When you remove a role through LCM or Certification, SailPoint adds a flag to indicate that the role was explicitly removed. This is necessary because, if the flag does not exist, the role will be assigned again during the next refresh due to the assignment logic.
Therefore, it makes sense for LCM to create this flag when a role is removed. If I remove the role manually without creating the corresponding flag, it could be considered a security concern because the role might be automatically reassigned during the next refresh.
What I meant to say is that this attribute only gets added for Roles that have an assignment rule of type “Match list” and not if the type is a “Rule”. And this is based on our recent testing. I hope that is clear. I am asking if you guys have any idea why it is that way.
If a business role has an assignment rule, then it normally should be marked so that it does not show up in a search of roles for revocation in the Access Request process, and also should be excluded from certifications. Any deviation from this is unnatural: the whole point of an assignment rule is to provision by policy: match the conditions, the role is assigned. No longer match, the role is removed. Allowing business roles to be included in Access Requests or Certifications is certainly allowed, but requires planning and process to deal with this negative flag. Client assumes responsibility for management of this: I think that requesting/approving the role again might possibly clear the negative flag, so I don’t think it’s complicated.
One other thought: I discourage use of match rule for assignment rules. Two better options are Filters and Populations. Populations are just a named filter. Match rule has limits. I often will create a hierarchy of business roles, each with an assignment rule, so that I limit the amount of processing by the matcher in each business role.
@Keith_smith Agreed with your comment that we should not allow dynamic roles to be part of certification or access request. This is a deviation.
However, on your other point. Even match list and filters have its own limitations. It doesn’t work effectively with multiple accounts in the application whose attributes you want to add in your filter. There is no option to decide from which account you want the attributes to be picked. So, we need to rely on Rules only. It’s a topic for some other discussion.
Hi thanks for your thoughts. In my experience it is not best practice to make a business role’s assignment rule dependent on an attribute from an account link. I think it is possible; that doesn’t make it a good practice. I have encountered many instances where there are complex account dependencies and I normally will use a global identity attribute rule to compute and save an identity attribute onto the identity, which then can be used to drive assignment logic, no matter what form it takes.
Not saying that rule objects are bad, but if you write them be sure to provide sufficient trace logging statements so that when they act up you can trace the logic.
@Keith_smith Yeah.. but there would be instances where we need to read values from specific application accounts, and converting them to identity attributes doesn’t add much value. We may end up creating bunch of identity attributes whose only purpose is to satisfy just handful of roles.
Still, I’ll make a note of it that recommendation is to use matchlist and filters over rules. Thanks for sharing the details Keith. Really appreciate it.
