Mandatory Sunset Date

[zeel_sinojia]

Hello Everyone,

I recently had a requirement from a client to make the access request sunset date mandatory. As there is no OOTB solution for this, I created a custom workflow to achieve it.

I see an idea was submitted for this functionality, which is marked under Future Consideration, GOV-I-1764 so I believe this should be a lot more helpful for the folks looking to make the sunset date mandatory.

Workflow file

I have attached the workflow JSON file, you could use this file as a template and customize it further as needed.
MandatorySunsetDateWorkflow.json (6.5 KB)

Prerequisite

For a basic Access Request Submitted Trigger, please check out this post implementing-a-request-response-type-trigger-in-workflows by @colin_mckibben and Access Request Submitted trigger.

Access Request Submitted | SailPoint Developer Community

Mandatory Sunset Date Workflow

Building on Colin’s workflow, I added an additional API call to list-access-request-status | SailPoint Developer Community ( Get Access Request ) which fetches the status of all the access requests.

This list-access-request-status | SailPoint Developer Community API call is necessary because the trigger input doesn’t provide the sunset/expiration date.

The API does not allow filtering to retrieve only the access request with the specific accessRequestId provided by the trigger. Therefore, I used JSONPath filtering and filtered the JSON response with the expression:

$.hTTPRequest1.body.[?(@.accessRequestId == $.trigger.accessRequestId)].removeDate

This returns the sunset date (attribute name is removeDate) from the API call. We use this approach instead of sorting the response to pick the latest request, as it better support handling multiple access items.

Note: I have used this API with the parameters ?count=true&limit=5&sorters=-created. This will give me the 5 latest access request object from this API. You may adjust this number as per your requirement.

After retrieving the removeDate value, use the Verify Data operator to check whether the value is null. If the value is null, it means the requested access item doesn’t have any sunset date and the request can be Denied.

{
    "output": {
        "approved": false,
        "approver": "Workflow",
        "comment": "Sunset or Expiration Date is mandatory. Please submit a new request with a sunset date."
    },
    "secret": "{{$.trigger._metadata.secret}}"
}

Otherwise, approve the request, and it will proceed through the configured access request approval hierarchy.

{
    "output": {
        "approved": true,
        "approver": "Workflow",
        "comment": "This access has passed workflow approval."
    },
    "secret": "{{$.trigger._metadata.secret}}"
}

If the request is denied, this will send an email to the requestor informing them about the denial of request and the reason.

Get Identity Action

Send Email Action

That’s it, now you have a workflow that will deny any access request submitted without a sunset date and inform the requestor of the same. You can modify comments and adjust the workflow logic according to your requirements.

I’ve attached the Workflow JSON file, which you could use to implement this solution. Let me know if you have any more questions.

Hope this helps!
Thanks!

[RandomUser4096 (Terry Yau)]

As much as it ‘works’ and forces a Sunset Date to become mandatory…after the fact, this is terrible UX for the requester. There ought to be native OOTB configuration (as opposed to per tenant development) for this. Product gap?

[248048 (Girish Lavangade)]

Thanks you soo much Zeel. Great learning.

[zeel_sinojia]

I agree the UX is terrible and this ought to be an OOTB solution. However, till they decide to provide us with an OOTB solution (which I don’t see happening in the near future), this feels like a good workaround.

I feel that the workflow can be modified to set a default sunset date instead of rejecting the access request to improve the UX a bit.

[dpennington (David Pennington)]

Thanks for this - very helpful and worked like a charm. Agree, this is a workaround until they provide an OOTB solution, but this helps in the meantime.

[TheOneAMSheriff (Amar Sheriff)]

Decent workaround until the the feature finally gets implemented OOTB. A static time period might not be preferred from a security perspective/granting access to users to the least amount of time required, as I understand that’s why the decision was to deny the request without an expiry date in the workflow.

[zeel_sinojia]

Yes that’s correct. The workflow will deny the access request. This is NOT a good UX. But, I see it as the only way to make sure every access request has sunset date associated with it.

[Firmman-Alexander]

@zeel_sinojia this is great! Will be testing this in my tenant soon

I would like to modify this workflow to only perform this “sunset date check” on certain access items. How best could you suggest modifying this to perform that use-case? Perhaps filtering at the Access Request Submitted external trigger step? Thanks again for this workflow as it is

edit: meant to add that I looked at the v4/access-request-status endpoint you used, but I can’t seem to figure out if you can only filter out identities and accountactivityid’s