Pages

Contact

How to avoid impersonation with the Mailbox Inbasket for PFI

Here is a solution to avoid impersonation when from an email we take action in the Inbasket of ProcessFlow Integrator (PFI).

The scenario is the following. We have a workflow where approvers need to review certain information and take action, for example Approve or Reject. In this particular scenario the buttons to approve and reject are embedded in the email such that approvers can take action directly from their mailbox, i.e. we are not discussing the scenario of the Inbasket in Lawson Smart Office (LSO).

I call this the Mailbox Inbasket.

Note: The reason to use emails instead of the Inbasket is that not all approvers use LSO, for example in certain companies the managers don’t use LSO, they just have a mailbox. The other advantage of using the mailbox instead of the Inbasket is that taking action from the mailbox works from virtually any mail client that has network access to the PFI server, from corporate mobile phones for example.

When the approver takes action (for example Approve or Reject), PFI will challenge the user for authentication. The approver enters the login and password, PFI validates the credentials, and carries on with the action (Approve or Reject).

The problem arises if the user forwards the email to another person, the parameter RDUSER embedded in the URL could lead to impersonation, i.e. a user could take action in place of another user. That’s not desirable.

To avoid impersonation, we must remove the parameter RDUSER from the URL. But in doing so, PFI will throw an error.

The solution I propose is to create an intermediate JSP that will append the parameter RDUSER to the URL only after authentication.