When a user receives a notification, there is usually an option to reassign / transfer / delegate the notification to other users. If they are using the standard Workflow worklists, then there is some in-built security here, in that only the recipient (or an administrator) should have access to the notification unless the whole worklist has been delegated to another user.
Responding to notifications via email is a different matter altogether. Assuming the email client renders the notification in HTML, the user should be presented with some system generated links to respond to the notification or reassign it. If they need to reassign the notification to a different user, then this is the mechanism that they should use. If they require more information, then this should be included as an option for the recipient to ask someone for their input. Assuming that the users use the links, the system is foolproof – reassign the notification via the link, or send it back to someone for comment using the link. Dead easy.
Let’s be honest – can you really rely on your users doing everything the “correct” way? What happens if they just want to get more information quickly, so instead of clicking on a “more info” option, they just forward the email to the preparer with a quick note at the top for more information? They’ve just opened up a potential security loophole – the person that they sent the email to has now got a link in their mail which would allow them to respond to the notification if they wanted to! Imagine if this was an expense claim, or an expensive purchase order approval – the person who should have been approving it (i.e. a “trusted” employee) has effectively handed an opportunity to the preparer to approve the request themselves. The owner on the notifications table remains the same (the transfer / delegate functionality has not been used), so it will look like the right person approved it, when in reality, anyone could have done it.
So, what can we do to stop this happening?
There are a few things that you can do to help minimise the impact of this. Starting with the easiest to implement – don’t use email for your notifications. Email is fine for sending FYI notifications, but I don’t like the idea of relying on users to respond to a system via email My reluctance to embrace email with Workflow stems from working with less sophisticated email servers and clients. When I started Workflow development, HTML mail clients were nowhere near as common as they are these days – my email client through Netscape only displayed email in text format. Also, the Workflow mailer was mainly implemented using UNIX sendmail. If you have ever had the experience of trying to implement Workflow with a non-HTML email client, you should be able to relate to this quite well – if the email can’t generate the response template automatically for you, you are reliant on the user to enter the correct response, in the correct case, on the correct line, with the correct opening and closing quotation marks. However, I concede that this isn’t always possible – email is much more of a push of information from the system to the user, whereas the notification worklist relies on the user pulling information out of the system. Users like email, plus not all notification recipients are Workflow or eBS users, so can’t use the worklist.
Secondly, there is a certain amount of responsibility that lies with the user and the level of training that they have received. It should be a “simple” matter of user training to highlight the importance of using the generated links to respond to notifications. However, this is a fairly naïve thought – not everyone is going to get the same training, particularly as a system matures, and this can quite easily be overlooked.
Thirdly, you can check from the notification response who the response came from. When a notification comes in via email, the email address is stored in the system, and can be checked. A Post Notification Function could be used to check the email address against the owner role, and if there is a discrepancy, then it could reject the response. However, this isn’t quite as simple as it sounds – you also need to check whether the notification has been delegated, since the owner of the notification will not have changed on delegation.
The final check that you can implement to stop this being a security problem is that you can change the mailer configuration. AFAIK this will only work in the Java implementation of the Workflow mailer, but you can configure the mailer to disallow this. From the mailer configuration, there is a flag which you can set or unset as necessary called “Allow Forwarded Response”. If the flag is set, then the system will not accept responses which have not come from the original recipient of the notification email.
Personally, if possible, I would advocate the first option – if you require users to log on to the eBS, then this ensures that the respondent has the appropriate authority to do so, rather than relying on other configuration. If necessary, you can always send summary emails to remind people that they have open notifications in the system.