Skip to main content

Workflow Approval Via Encrypted Email Links

A common workflow process is often the access request scenario - a user requires access to something, and that something requires an approval before the provisioning can be completed. Typically this is done via notifications, a dashboard and perhaps an email notifying the approver that they have a task that requires their attention.

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:
  1. Helpdesk operator requests access to impersonate an end user for a set period of time - say 5 minutes
  2. The end user will receive an email notification with two links - Approve or Reject
  3. Each link will go to two specific OpenIDM custom endpoints - ../endpoint/approveImpersonation or ../endpoint/rejectImpersonation
  4. Each endpoint will take a ?payload= argument that will contain an encrypted value
  5. That encrypted value will be contain the end user's Id and a unique reference to their workflow task instance
  6. As every request into OpenIDM needs to be authenticated, we'll route the request via OpenIG to add in an authentication header
  7. The custom endpoints will verify the payload, decrypt, find the appropriate workflow task instance and complete the workflow request task
  8. If approved...the workflow will provision the end users Id into the helpdesk operators account under an attribute called impersonationId
  9. 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.

The architecture at a high level looks something like this:




The main element of this is the workflow.  This is a simple access request style workflow with two interesting components. First is the sending of an email with the two links - both of which are encrypted using the openidm.encrypt function. The second is a time boundary that removes any changes the workflow makes after a selected time window.  The encrypted email payload contains a unique reference that is attached to the task instance.  The unique reference is created using the openidm.hash function, that takes the requester Id, requestee Id and the current time in ms.


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 end user simply selects the appropriate link.  The link automatically redirects via IG to snowball the appropriate authentication headers and completes against the OpenIDM endpoint.

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.

        <intermediateCatchEvent id="timer">
  <timerEventDefinition>
    <timeDuration>PT${lengthOfImpersonation}M</timeDuration>
  </timerEventDefinition>
</intermediateCatchEvent>

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" >
            <script>
                
                queryParams = ["_queryFilter": '/userName eq "'+startUserId+'"']
                userToPatch = openidm.query("managed/user", queryParams)

                patchParams = [[operation:'replace', field: 'idToImpersonate', value : ""]]
                openidm.patch('managed/user/'+userToPatch.result[0]._id, null, patchParams)
            </script>
        </scriptTask>

The code for the above sample is available here.

Comments

Popular posts from this blog

WebAuthn Authentication in AM 6.5

ForgeRock AccessManagement 6.5, will have out of the box integration for the W3C WebAuthn. This modern “FIDO2” standard allows cryptographic passwordless authentication – integrating with a range of native authenticators, from USB keys to fingerprint and facial recognition systems found natively in many mobile and desktop operating systems.
Why is this so cool? Well firstly we know passwords are insecure and deliver a poor user experience. But aren’t there loads of strong MFA solutions out there already? Well, there are, but many are proprietary, require complex integrations and SDK’s and ultimately, don’t provide the level of agility that many CISO’s and application designers now require. 
Rolling out a secure authentication system today, will probably only result in further integration costs and headaches tomorrow, when the next “cool” login method emerges.
Having a standards based approach, allows for easier inter-operability and a more agile platform for change.
AM 6.5 has int…

Implementing Zero Trust & CARTA within AM 6.x

There is an increasing focus on perimeterless approaches to security design and the buzzy "defensive security architectures".  This blog will take a brief look at implementing a contextual and continuous approach to access management, that can help to fulfil those design aspirations.

The main concept, is to basically collect some sort of contextual data at login time, and again at resource access time - and basically look for differences between the two.  But why is this remotely interesting?  Firstly, big walls, don't necessarily mean safer houses.  The classic firewall approach to security.  Keeping the bad out and the good in.  That concept no longer works for the large modern enterprise.  The good and bad are everywhere and access control decisions should really be based on data above and beyond that directly related to the user identity, with enforcement as close as possible to the protected resource as possible.

With Intelligent AuthX, we can start to collect and s…

Forget Passwordless, What About Usernameless?

A year or so ago, I blogged about the wonderful world of passwordless and how WebAuthn was going to save the world!  Gone will be insecure passwords, with their terrible user experience, and contributions to data breaches and in with a standards driven, crypto based, technology agnostic way of authenticating a user. The panacea!  Well, the panacea might just be getting be getting a little better.

Take a look at the above blog for a quick "reccy" on how WebAuthn works and the main flows.  TLDR; we're using public/private key pairs for each website or service we want to authenticate against.  The private key gets stored somewhere safe - namely within the dedicated USB authenticator fob, or within the secure element on an operating system.

In ForgeRock Access Management 7.0 EA, the WebAuthn registration authentication node has been modified to now include a "Username to device" switch.  This essentially allows a user handle to be sent back down to the authenticato…