BeforeProvisioning Rule for a web-service application

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hello Experts,
I build my very first Before Provisioning Rule for a webservice application. I will be just syncing the data from ISC to Webservice application, but i need to send 4 different payload with a PATCH Method.

  1. add email
  2. update email
  3. add phone
  4. update phone

I created 4 different http operation and thought of write a BeforeProvisioning rule that will select the operation when syncing is happening.

Here is the first rule I generated, your feedbacks will be very helpful.

import sailpoint.object.ProvisioningPlan.AccountRequest;
import sailpoint.object.ProvisioningPlan.AccountRequest.Operation;
import sailpoint.object.ProvisioningPlan.AttributeRequest;
import sailpoint.object.ProvisioningPlan;
import sailpoint.object.ProvisioningPlan.Operation;
import sailpoint.object.Identity;

if (plan != null && plan.getAccountRequests() != null) {
    for (AccountRequest accReq : plan.getAccountRequests()) {
        if ("WebApp".equalsIgnoreCase(accReq.getApplicationName())
            && accReq.getOperation() == AccountRequest.Operation.Modify) {

            Map<String, Object> currentAttributes = accReq.getNativeIdentity() != null ? accReq.getAttributes() : new HashMap<>();

            String currentEmail = currentAttributes.containsKey("secondaryEmail") ? (String) currentAttributes.get("secondaryEmail") : null;
            AttributeRequest emailAttrReq = accReq.getAttributeRequest("secondaryEmail");
            String newEmail = emailAttrReq != null ? (String) emailAttrReq.getValue() : null;

            if (newEmail != null) {
                accReq.setOperation((currentEmail == null || currentEmail.isEmpty())
                    ? AccountRequest.Operation.Add : AccountRequest.Operation.Modify);
            }

            String currentPhone = currentAttributes.containsKey("phoneCallCell1") ? (String) currentAttributes.get("phoneCallCell1") : null;
            AttributeRequest phoneAttrReq = accReq.getAttributeRequest("phoneCallCell1");
            String newPhone = phoneAttrReq != null ? (String) phoneAttrReq.getValue() : null;

            if (newPhone != null) {
                accReq.setOperation((currentPhone == null || currentPhone.isEmpty())
                    ? AccountRequest.Operation.Add : AccountRequest.Operation.Modify);
            }
        }
    }
}

Thank you
Learning ISC daily

2

Are you having an issue that we can help solve, or are you asking for feedback on the rule that you wrote? I only see a description of the current state of your system, and could not find a question other than asking for feedback.

Let us know what you are looking for so we can better provide assistance.

3

Hello @gmilunich

I haven’t tried this rule yet. AS far I know “Before Provisioning Rule” are considerate as cloud rule in ISC and SailPoint needs to deploy to the tenant. And I wanted some expert eyes before I submit the deploy ticket.

I wanted some answers

  1. Does this rule logically make sense in the context of our use case?
  2. Is this rule aligned with SailPoint Identity Security Cloud (ISC) standards or best practices?
4

I would consider checking out the Rule Development Kit provided by the Developer Advocates, which can be found here: Rule Development Kit | SailPoint Developer Community

The kit provides tools to help you develop the rules before submitting them for review.

I assume that since you are asking about before Provisioning that you are using the Web Service SaaS connector.

Looking over your code, I am not sure it is doing what you intend. It looks like you are getting the attributes off of the AccountRequest:

Map<String, Object> currentAttributes = accReq.getNativeIdentity() != null ? accReq.getAttributes() : new HashMap<>();

I would review that the getAttributes() is available for the AccountRequest in ISC, as I don’t see it in the Rule Javadocs: Java Docs | SailPoint Developer Community
Additionally, are you setting data in the attributes for the accountRequest? This does not pull the attributes off the Account itself if that is what you were intending to do here.

Then you are checking to see if they have the key, and if so, returning the value or NULL:

String currentEmail = currentAttributes.containsKey("secondaryEmail") ? (String) currentAttributes.get("secondaryEmail") : null;

You then get the value of the AttributeRequest for that Key and then get the value or NULL from the key:

AttributeRequest emailAttrReq = accReq.getAttributeRequest("secondaryEmail");
String newEmail = emailAttrReq != null ? (String) emailAttrReq.getValue() : null;

Your last step here appears to be checking to see if the there is a newValue (newEmail in the example) and then if so, checks to see if there is a CurrentValue (currentEmail in this example). If the currentValue is not found, you change to an ADD operation, and if it is found you set it to a MODIFY operation.

if (newEmail != null) {
    accReq.setOperation((currentEmail == null || currentEmail.isEmpty())
        ? AccountRequest.Operation.Add : AccountRequest.Operation.Modify);
}

Where you could run into issues is that you are changing the AccountRequest operation here. If these changes come in on the same plan and AccountRequest, then you’ll keep changing the Operation if the Email Exists, the Phone does not for example.

Hope that helps.

1 Like
5

@gmilunich
While i was exploring your solution something came in my mind.
Could it be possible to put a condition “runif” from backend.
something like this

{
  "httpMethodType": "PATCH",
  "uniqueNameForEndPoint": "ABC",
  "sequenceNumberForEndpoint": "5",
  "runIf": "$getObject.attributes.phone$ == null",
  "body": {
    "jsonBody": "[\n {\n  \"op\": \"add\",\n  ... } ]",
    "bodyFormat": "raw"
  }
}
7

I don’t know that you can add elements to the JSON like that and have them evaluated or passed into the rule. You could create an Idea in the Ideas.sailpoint.com forum for that, but as it sits now, I don’t believe that is possible.

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.