Email authentication action Process Automation

We are struggling with the same issue and have not found an acceptable solution.

Add the property emailActionAuthenticationRequired to the system configuration (and set the Value to true) in the IPA server so that the approver needs to log in prior to taking an action on a workunit from an email notification.

I did that but it didnt seem to work.
It was still logged under the original approver.
Did this work for you?
If so, perhaps I need to revisit it.

David,
When you use this does it tell the impersonator that they are not authorized to approve or give them some kind of error?

I had similar questions. Is it indicated anywhere that Approver B did the action and not Approver A? We're looking for an audit trail when it occurs. Also, does Approver B need to have the same WF security or is it let ANYONE that receives the email to approve it?

Not as far as I know. That's exactly why we have not enabled those buttons on our action emails. We just direct them to EmployeeSpace, and tell them to go to their Inbasket and take action. Not our preferred solution, but without forcing a login, we won't go there.

Kelly

I opened an Incident with Infor but it went nowhere except around in circles.
They said the emailActionAuthenticationRequired setting fixed this which it didnt for me at least.
Then they said it worked on their version and then they eventually said it must be because we were using single sign on for Lawson.
I dont believe it was working on their end either because the Support person seemed unsure of himself thorughout the thread.
Even it were to force a login we wouldnt want a user approving another users request.
I ended up agreeing to let them close the ticket but users are really pushing for this.
Does Infor have any plans to fix this?

The Requsition header audit says the User who took the action was lawson
The process flow thinks its the approver it was intended for (not the one it was forwarded to)
I also have the same question as Terry .. is it logged anywhere who did the approval?
If there was a way to audit this through another process flow, we might settle for sending alerts if unauthorized activity took place.
Its pretty bad that they dont seem to be interested in fixing this security loophole.

There's always a way...depends how creative you want to get, HOWEVER i would lean towards "monitoring" approvals from within each flow proactively.

The flow alreadys know who SHOULD be approving, or if it's a group task, who is the possible list of approvers.
I would add a LM node following the approval to see who actually approved, then add a branch...
If approver = expected approver(s)
continue the flow
Else
send email to notify and loop back to the approval node

You could add this logic pretty quickly, then cut-n-paste in other flows.

After you add the emailActionAuthenticationRequired property to the 'system' configuration you need to restart the IPA web application server. Just did this today and it worked.

Did it also validate that the proper user was the one who logged in? I was playing with this a bit a few days ago, and it let me approve a requisition that wasn't filtered to me, and then reported the user who changed it was the one who the notice was sent to.

I hadn't tested that yet; I just did. No, it didn't validate that the authenticated user what the proper person for the user action.

We're just upgrading to IPA and this is new functionality for us.
Has it ever validated that the authenticated user is the proper user?
If not, why even offer authentication (especially in an organization that has EMSS where everyone can authenticate to Lawson)?

In my test case the flow shows that I took the action (the flow sent the task to me) even though I had forwarded the email to my manager who took the action and authenticated. This is just as bad as not having any authentication.

Agreed, that's what I found as well.

I just sat on the ICYHH webinar for the mobile inbasket and mobile notifications. if you don't mind that it only supports Apple, the mobile notifications might be a good route to go. I'm going to check out the mobile inbasket as it is "supposed" to work with IPA. It is basically a mobile browser version of the inbasket, so you log in and see your inbasket rather than direct action from the email.

If you use the email authentication it should require you to log into Portal/Ming.le and not allow you to take the action if you don't have the correct Task/Filter.

David - our tests show it is only authenticating if you have Lawson access - not that you have that task and/or filter the original person had. Can you confirm that.

The authentication flag was setup by Infor to address the security hole of taking the action within emails and was designed to also check for the Task setup. I believe I tested this when it first became available, but don't have access right now to validate.

So what does that get you? If you need to have the second person setup with the task and filter - wouldn't they have received the email in the first place? Just trying to in-vision what you gain or how it would actually work.

In our case we have only one person setup for a specific task/filter (Department Director). If he went on vacation or wanted his assistant to handle the approval in his absence, he could forward it to them. With the flag off, there is no checking whatsoever. With it on, someone would have to go in and add the task and filter for the assistant, then take it off later.

What I had "hoped" would occur is it validated they had Lawson access, but it would show the user who actually approved it in the work unit action and logs.

We have been using Mobile In Basket for several years. We have not yet moved to IPA, but I have been assured that MIB still works with IPA. Since it is not a true "app", it is platform independent. It runs on Apple, Android, Blackberry, PC, etc.... Users must authenticate so they can only approve reqs that they are authorized to approve.

@all

I asked the same question to Jena Block here http://blogs.infor.com/te...ts-new/#comment-3012 , and she responded to me by email.

She said "from 10.1.1.43 and on, the accidental impersonation is fixed. You will, however, need to add a new configuration property in order for this to be allowed. The default behavior is that user authentication will be required when taking action from an email. If the authenticating user is not the same as the user that has been assigned the work, they will not be allowed to take action. If you want to allow users to take action on a forwarded email, you will need to add a system configuration property called “emailActionAllowEmailForwarding” and set it to true."

Note the version number. And note the word "Allow" in the property name (which I did not see in your posts above). I haven't tested.