NOTE: this content is the copyrighted property of the author, Gretchen Y. Lindquist, and is published by the author’s permission on SDN.SAP.COM. If you are reading it elsewhere, you are reading stolen property.***
My colleague’s request was simple: could I take a few minutes to call an end user who had submitted a problem ticket concerning SAP security access requests? Sure thing, give me her contact information and I’ll handle it. When I reached her by phone, she explained that she was having a problem using our old access request form to request access to approve expense reports. I reassured her that I could talk her through using the new access request toolset, and she would see how all the new features made it a much easier process.
Getting her logged into our SAP portal and launching the request application was a snap. We were progressing swimmingly until a pop-up error message said that she was being blocked from requesting the expense approver role; either a request for that role was already in process, or it was already assigned. OK, let’s back up a minute, click the Show User’s Current Role Assignments button and let’s take a look. Sure enough, the role was already there. But I am gettting a security error every time I try to approve this expense report, she protested.
I had her log into the core production client and try again, up to the point where she was stopped, then I verified her last authority check. As I had started to suspect, it told me that all authority checks were successful. I told her that she was not having a security problem, that something else was wrong here. Perhaps the expense report was not in the correct status. I suggested she contact a process expert in expense approvals, and wished her luck.
Afterwards, I thought about this user and considered the possible root causes of her problem. Was something done incorrectly in the submission of the expense report, or was she making some kind of error in her attempts to approve it? It seemed likely that it was a training issue of some sort, which led to further questions.
Access to submit expense reports is granted in our general user role, which is assigned to most users via assignment to the organization unit, after the user IDs are created automatically by a custom program. We don’t do a lot of security by org structures, but it is a huge time / cost savings to have user IDs created automatically and basic general access and access to employee self service (ESS) granted automatically. However, the down side to this automation is that the users are granted access to these transactions without any training. The ESS transactions are fairly straightforward, but on a few occasions I’ll admit that they had me stumped, and Engish is my native language. What about all of those transactions in the general user role? Are all of them so straightforward that users could do them correctly without any training, even users for whom English is not their first language? I’m not so sure about that optimistic assumption.
Then I considered the new identity management tools that assign a whole bundle of roles in several systems, based on an employee’s hiring into a particular position. I have doubts that automation to that extent would be acceptable to the business here. Today, a good number of roles are not approved for assignment until the user provides evidence of passing a training course.
Therein lies the conflict. The idea that users would get roles based upon their assignment to a particular HR position, and removal of those roles when moved to a new one, has some inherent control benefits, preventing the continued accumulation of security roles as employees move about the organization. The down side is that the roles are assigned without any training, which might be OK for some roles but not others. How much automation of role assignments would be considered low risk? I can see that in our organization at least, quite a few roles would never be approved for automatic assignment.
In this case, I suspect that either the expense report creator or the would-be approver needed some training on expense reports, but as is so often the case, the user having problems automatically assumed that the error message meant that she was having a security problem. Over ten years after our initial implemention, people still occasionally jump to the conclusion that an error message is always indication of a security problem. Why didn’t the help desk agent help her review the message and determine that it was not a security problem? Another training issue seems evident. Sometimes what appear to be problems are just training issues, and we certainly do not want to contribute to more business disruption caused by training issues by letting loose untrained users to attempt complex transactions. How do organizations balance out the need to ease onboarding of new employees and to keep security aligned with their current jobs, and still require training prior to role assignments? There is the million dollar question.