However, what if the approver doesn't want to, or cannot, access their dashboard to approve the request? An alternative is to embed workflow approval questions into an email, with fully self-contained links that contain encrypted payloads to approve or reject the request. (NB a further extension to this is to be able to respond to workflow requests directly via email / SMTP).
A way to do this is to simply send an email during the workflow instantiation that contains links to approve or reject the request. But how can those links be securely created to avoid tampering, replay and misuse? There a few neat steps in the ForgeRock platform that can simply come to the rescue. (NB this assumes that the email traffic / account is secure, which might not be the case...!).
My use case will look like something like this:
- Helpdesk operator requests access to impersonate an end user for a set period of time - say 5 minutes
- The end user will receive an email notification with two links - Approve or Reject
- Each link will go to two specific OpenIDM custom endpoints - ../endpoint/approveImpersonation or ../endpoint/rejectImpersonation
- Each endpoint will take a ?payload= argument that will contain an encrypted value
- That encrypted value will be contain the end user's Id and a unique reference to their workflow task instance
- As every request into OpenIDM needs to be authenticated, we'll route the request via OpenIG to add in an authentication header
- The custom endpoints will verify the payload, decrypt, find the appropriate workflow task instance and complete the workflow request task
- If approved...the workflow will provision the end users Id into the helpdesk operators account under an attribute called impersonationId
- The workflow will then suspend and return n-minutes later, based on the time selected in step 1 and deprovision the attribute in step 8.
To trigger the workflow, the enduser and a time element are entered.
This triggers the sending of the notification email with the two links.
The endpoint verifies the payload argument exists, that the encrypted value is in tact, decrypts, finds the appropriate workflow task, compares the two hashed verification codes and completes the appropriate approve or reject action.
The workflow then contains an intermediate timer event that is used to act as a stop watch - to basically reverse any changes that are made, acting like a temporal condition.
The length variable is taken from the submitted workflow form. After the timeDuration has completed a simple patch removes any values provisioned to the user.
<scriptTask name="Cleanup User" id="cleanupRequestingUser" >
queryParams = ["_queryFilter": '/userName eq "'+startUserId+'"']
userToPatch = openidm.query("managed/user", queryParams)
patchParams = [[operation:'replace', field: 'idToImpersonate', value : ""]]
openidm.patch('managed/user/'+userToPatch.result._id, null, patchParams)
The code for the above sample is available here.