Replace Removal Action with Add Action

Identity Security Cloud (ISC) ISC Discussion and Questions
1

@zachm117 ,
wanted to check out with you , if you able to solve this one ?

Continuing the discussion from Replace Removal Action with Add Action:

2

Hey @vishal_kejriwal1!

Short answer, no we have not really be able to solve for this. We use the Standard Services beforeProvisioning rule I mentioned to replace the access with a default lower level of access, but the failures still show on our event log and reports.

The reason why this works for us, for now at least, is because we started giving our internal audit folks sub-admin access to IDN so they could see the Access History section on IDN, since we have that module available. Interestingly enough, even though the campaign reports have these failed events and the Search event logs have the failed events, Access History events show these replacements happening as expected without the failures. So when, for example, System Admin access is removed either due to a certification campaign or an expiration date, Access History shows this access being removed and the new default access being added at the same time. Since this is what our IA team is looking for and they can see themselves that this access is being removed/added as expected through Access History, this has been sufficient for our audit requirements. Since audit is satisfied and obviously since the access changes happen as expected, we haven’t tried to pursue a different solution.

Hope this helps you in your situation!

  • Zach
3

can you share the cloudServicesIDNSetup for your application ?

4

Sure thing!

                {
                    "eventActions": [
                        {
                            "Action": "UpdateAttribute",
                            "Attribute": "ProfileId",
                            "Value": "ALPHA-NUMBERIC ENTITLEMENTID"
                        }
                    ],
                    "Entitlement Update Triggers": [
                        {
                            "Attribute": "ProfileId",
                            "Value": "*",
                            "Operation": "Remove"
                        }
                    ],
                    "Operation": "Modify"
                }

This works since profileID is an attribute on the account schema. Basically when any entitlement remove operation is occurring, it updates the account attribute profileId to the value specified, effectively adding the new default entitlement/profile. This just doesn’t prevent IDN from trying to actually remove the original entitlement, hence the errors that still occur.

The “Alpha-Numeric Entitlement ID” is the ‘default’ lower level of access to get provisioned to a user when a Profile is being revoked, such as ‘Standard’. Yes, this can be a bit cyclical of someone is trying to revoke that Profile, IDN is just adding it back, but since it is the lowest level of access, we haven’t run into this being an issue.

  • Zach
5

Thank you @zachm117 .
I am doing the same thing for my application but i am getting error
Remove Operation on Profile is not supported.

“SourceName”
Failed: Failed and will not be retried

Errors
Remove Operation on Profile is not supported.

ACCOUNT REQUEST
Modify account: “AccountID”

ATTRIBUTE REQUESTS

Remove ProfileId: current profileID backend value
Set ProfileId: “least profileID backend value”

6

Yep that is the error we still see also in the logs and campaign reports because the remove operation is still being processed and fails. However, the profile actually does get updated in the Salesforce system and is reflected on the IDN account and the Access History shows this being done. Check out the user in Access History (if you have it available), or check out their Salesforce account to see if these changes are actually taking effect.

7

I don’t see that the profileID is updated in salesforce app. :frowning:

8

Does end-user raise request for ProfileID as entitlement ? or they always raise the request for Access profile (having profileID attached) ?

9

Hi Vishal,

Appreciate your insights !

let me take this forward,

We are facing the same issue for salesforce user when user Job title or department changes the IDN tries to remove the profielID and RoleID but fails to remove ProfielID though and user’s Salesforce account does not turn to Disable state(due to profielID being stick to it). but when new job title matches the salesforce role criteria it does add the new SF role(replacing the old profieID with New) and also adds new roleID to User but the Salesforce accout does not turn to Enabled state which should be automatic process.(manual Enablement is possible)

we add SF roles based on Criteria of job title and departement value match.

Client wants the user mover scenario to be handled without manual intervention.

Please let me know if you have any helpful guide on this to address the issue.

we also have tested the Before Provisioning Rule in SB given below.
but this Rule does not add new SF role to user based on new jobtitle & department as the salesforce account turns Disabled it doesnot get triggered on new SF Role addition.

import java.util.ArrayList;
import java.util.List;
import sailpoint.object.Attributes;
import sailpoint.object.ProvisioningPlan;
import sailpoint.object.ProvisioningPlan.AccountRequest;
import sailpoint.object.ProvisioningPlan.AttributeRequest;

if (plan != null) {
AccountRequest disableAccountRequest = null;
List accountRequestsToRemove = new ArrayList();

List accReq = plan.getAccountRequests();
for (ProvisioningPlan.AccountRequest acctreq: accReq) {
List attrRequestToRemove = new ArrayList();
List attributes = acctreq.getAttributeRequests();
if (null != attributes) {
for (ProvisioningPlan.AttributeRequest attrRequest: attributes) {
if ((attrRequest.getName().equalsIgnoreCase("Role")) || (attrRequest.getName().equalsIgnoreCase("ProfileId"))) {
if (attrRequest.getOperation().equals(ProvisioningPlan.Operation.Remove)) {
acctreq.setOp(ProvisioningPlan.ObjectOperation.Disable);
}
if (acctreq.getOp().equals(ProvisioningPlan.ObjectOperation.Modify) && attrRequest.getOperation().equals(ProvisioningPlan.Operation.Add)) {
acctreq.setOp(ProvisioningPlan.ObjectOperation.Enable);
}
}
}
}
}
}
return plan;

10

the main issue is with the stickiness of the entitlement and that we are planning to use before provisioning rule also the assignment of initial profileID will be handled in same rule.

11

Hi Vishal,

Could you please help us with that rule and strategy you applied to get this working please. we did try with before provisioning rule but that isn’t being helpful so far. could you please share your rule and methods that you find are helping to handle this case please

Thanks
Pooja Kesarkar