Imagine the following scenario: you’re about to go to the supermarket, your wallet is in your pocket with a $50 bill in it. Just before you leave the house, your spouse asks you to buy something from the pharmacy and gives you a $50 bill as well. You put the money in your pocket and leave to the mall. The question is, how much money do you have?
Some say $50 for the supermarket and $50 for the pharmacy. Others will argue that you simply have $100. The same argument applies to authorizations and roles. Many often assume that if a user has two roles – Secretary and Accounting – the user can perform actions either as part of the secretary role or as part of the accounting role. For example, you can perform the activity Approve Purchase Orders, which is part of the Secretary role, or you can perform the activity Open Vendor, which is part of the Accounting role. So far, pretty simple.
However, things start getting complicated when organizational objects such as company codes or warehouses are added. The role Secretary allows performing Approve Purchase Orders for company code 1000 and the role Accounting allows calling Open Vendor for company code 2000. John, who was granted with both roles, is authorized to approve purchase orders for company codes 1000 and 2000, and may also be permitted to open vendors in both company codes 1000 and 2000.
Oops… granting more authorizations than you intended...
In SAP when a user logs in, all authorizations are gathered into the user buffer. The user buffer includes all authorizations for a user, regardless of the source of the authorization (i.e. role). Thus, if an authorization object allows company code 1000 and another authorization object grants access to company code 2000, the user buffer will answer 'yes' to authorization questions regarding either company code 1000 or 2000.
How does SAP try to solve this situation (without 100% success)? You’re more than welcome to read further in SAP Authorization for Beginners.
Why this matters for Segregation of Duties and GRC
A common rule in many companies is: User can’t open vendors and issue a purchase order for this vendor in the same company code. Now, the role Super Accounting includes the action Open Vendor for company code 1000 and Issue Purchase Order for company code 2000. The role Super Secretary includes the opposite – Open Vendor for company code 2000 and Issue Purchase Order for company code 1000. Although each role is not violating the SoD rule, both of them together by the same user will violate the rule.
How to avoid granting unnecessary authorizations
First, you simply can’t trust a manual process to handle this problem. You must take a proactive approach – before and after granting the role. Before granting the role, use simulation; there are software tools which can simulate what will happen and which SoD rules will be violated when granting a specific role to a user. After granting a role, use an automated tool to continuously inspect your users/roles and send alerts about SoD rules that are being violated. This way you will be able to solve any issues that arise instantly.
So how much money do you have now?
Tricky question with a tricky answer – just like the unknown situation of cross-authorizations and wrongly granted authorizations. Still, this can be solved with a good set of SoD rules, simulation and smart alerts. Remember the money – clearly the safest thing to do (and best for your relationship with your spouse) is not to spend the money for the pharmacy on the supermarket.