Hi everyone,
I’m trying to implement Sunrise/sunset role assignment feature of SailPoint using API calls from ServiceNow using POST [http://localhost:8080/iiq/scim/v2/LaunchedWorkflows ]
We know that by default SailPoint uses “Scheduled Assignment” workflow to implement this functionality.
However, in terms of actual flow how does it work based on which i can plan the API inputs - I tried a manage user access request for a user scheduled to start one day in future and ending 3 days from now. In tasks results i could see update identity “xxxxxx” accessRequest complete and access request complete immediately after approvals- this means LCM provisioning has ended. Could also confirm this via the logs.
At this stage the identity → entitlements page does show the entitlement with an ! mark with start date and end date. This means the access is not provisioned yet even though LCM provisioning has ended ? I could see 2 request objects created for Scheduled Assignment in future.
So in terms of implementing this functionality via API , do i need to call both LCM provisioning and scheduled assignment or just scheduled assignment WF(i assume it will be just scheduled assignment if i am just doing sunrise/sunset provisioning and approvals are handled at Snow end ?).
Also if i call scheduled assignment WF i couldn’t see any date parameter in WF inputs. Do i specify this date input (or nextLaunch input ?) and the WF automatically understands it ?
@paulo_urcid
From what I understand, you would just call the LCM Provisioning workflow and pass in a provisioning plan which already contains the sunrise/sunset dates on the AttributeAssignments of the entitlements. The LCM Provisioning workflow would be configured to not require any approvals (approvalScheme=none). The provisioning engine will internally launch the Schedule Assignment workflow based on the sunrise/sunset dates in the plan. The workflow itself does not have any parameter or variable that determines the sunrise/sunset dates, as those are specified in the provisioning plan
thanks Paulo, yep planning to do this with a removeDate (as business wants immediate sunrise and future sunset) . Currently the complete design is yet to be finalised so will keep you posted how i go with this.
Hi @paulo_urcid ,
I tried the below code to generate the immediate sunrise, future sunset plan(after 1 day) -
if(idLink !=null){
log.error("Build immediate sunrise and future sunset plan");
workflow.put("accountProvisioned",idLink.getDisplayName());
//Build account request
ProvisioningPlan.AccountRequest accReq = new ProvisioningPlan.AccountRequest();
accReq.setApplication(applicationName);
accReq.setOperation(ProvisioningPlan.AccountRequest.Operation.Modify);
accReq.setNativeIdentity(idLink.getNativeIdentity());
ProvisioningPlan.AttributeRequest attrReq1 = new ProvisioningPlan.AttributeRequest();
attrReq1.setOperation(ProvisioningPlan.Operation.Add);
attrReq1.setName("memberOf");
attrReq1.setValue(groupDN);
attrReq1.setAddDate(date);
attrReq1.setRemoveDate(addDays(date,1));
accReq.add(attrReq1);
List attList = accReq.getAttributeRequests();
//Only Push to LCM Provisioning if their are attributeRequests
if (attList != null) {
wfcontext.getWorkflowCase().put("proceedLCM",true);
}
plan.add(accReq);
log.error("sunrise sunset plan is:"+ plan);
}
the code ran successfully, and in entitlement for a person I could see deactivation date being populated, but when I checked the request object there was no request created for future execution -
And as expected the problem is that even after the sunset date passed the entitlement has not been removed.
Please advise if i’m missing something in plan ? (ignore the log.error statements, will change levels later)
Good afternoon @aditya_pathak - what version of IdentityIQ are you currently testing on?
Hi Aditya,
I’m glad to see you were able to fix your original issue. Would you mind sharing the steps you took to solve it in case anyone else is experiencing a similar issue? It will greatly help the community.
Thank you!
Additional Attributes object with “assignment” as true was required to be set on the AttributeRequest object
