- I have 10 friends.
- 5 of them are good friends and 5 of them are bad friends.
- I wrote an SAP Dialog program
- I want my good friends to be able to execute the program.
- I want my bad friends NOT to be able to execute the program.
I was troubled with this thought. How can I achieve this ?
So I thought of a plan.
I created a Custom Table called ZGOOD_FRIENDS with one column.
Now on the PBO Event of the Program I run a SELECT Query on this table and if a record with UNAME = SY-UNAME exists in ZGOOD_FRIENDS table then I allow the program to continue execution or else I simply terminate the program with the following error message.
“You are not my Good Friend, so you are not allowed to run this report”.
This program runs fine. But when my bad friends learnt about my plan, they came to me and said
“We want to be in your good books, Linkin.. We promise we wont trouble you any more.”
I know, To pardon is Noble, hence I decided to pardon my friends.. But as per Ronald Regan’s signature phrase, Trust but Verify I would not let them thru without first verifying their true motives.
I decided, therefore, to let my bad friends be able to run the program, but not be able to make any edits to the data. — VIEW ONLY .. NO EDITS.
However for my GOOD Friends.. — ALL ACCESS TO THESE Good Hearted Folk — VIEW ALL, EDIT ALL.
How do I achieve this now ?
I decided to extend my table and add another column to the table called ACTIVITY and I classified 2 activities as 01 and 02. So 01 would stand for READ and 02 would stand for EDIT.
For my good friends I marked them with a 02 and for my bad Friends ( who I considered not so bad for now ) I marked them with a 01.
Now in the PBO Event I made a slight tweak.
If the SY-UNAME would have an activity 02 then the user would be able to see the screen in change mode, but if the activity would be 01 then the user would see the screen in display mode only.
Cool my idea worked. I tested it on both, my good friends as well as my bad friends. Bruce Lee now was able to edit the data, but Joker could not.
OK!! Now I was ready to move this solution to Quality, and moved my program for a security audit.
At this time my SAP security lead saw my solution and said ..”Dude why did you do all this programming. SAP already had a solution for this.”
ALAS .. Dumb Linkin realized his folly!!
How could I have forgotten that I could have used the AUTHORITY-CHECK Statement to perform the exact same thing that I did with the use of all this programming and Custom Table.
So with this story I introduce you to the SAP Magic Statement AUTHORITY-CHECK.
Off-Course the above story is a figment of my imagination but it was composed to drive home the point that usually in a Business enviornment, it is usually a requirement that certain group of people have access to certain transactions with View or Maintain capabilities.
For Example, you would not want a Factory Shop Floor Project Manager to have access to Sales Manager’s Salary Records and alternatively you also would not want an HCM Administrator making edits to Inventory or Factory Planning data which only the Shop Floor Planner understands better.
This concept of restricting data access is called Authorization.
To make authorization management simple, SAP provides a large number of Authorization Objects with certain permissible activity parameters.
For example SAP provides an Authorization Object S_DEVELOP. This object controls the access to SAP program source code. You would not want Functional Consultants to view or modify SAP source code. Source code modification is a Technical Consultants job who understands the ABAP language.
Hence In SAP Security you would have two roles. For simplicity of understanding we will call them Z_TECHNICAL_ROLE and Z_FUNCTIONAL_ROLE.
In Z_TECHNICAL_ROLE you will add the S_DEVELOP object with the appropriate Activity value.
Since I am primarily a Technical Consultant, the security consultant will add the Z_TECHNICAL_ROLE to my id. Which means I would therefore have the S_DEVELOP object in my id with the approprpriate Activity Value. (01 = Create)
Now if the Functional Consultant is ABAP Savy and would want Read Authorization to read program source code.. off-course since they DO NOT have Z_TECHNICAL_ROLE so they will not be able to read the code also. But why stop them from reading the code. Our only intention is to prevent them from writing or editing the code .. right ?
In that case Security consultant can create another Role called Z_TECHNICAL_READ_ROLE and include the S_DEVELOP object in this role with the Activity 03(Display) and assign this role to the functional consultants id.
This would mean that now the functional consultant can read the code but cannot edit it unless they get the Z_TECHNICAL_ROLE which has the S_DEVELOP object with Activity Value 01.
But this is a standard functionality.
What would you do in a custom program ?
That’s where the AUTHRORITY-CHECK statement comes into picture and will be the focus of part-2 of this blog piece.
Wait for it.. will write about it soon.
If you liked this article, Share it.
Thanks for sharing. This topic is interesting for usage of sod.
It is very difficult to explain Authorization Concept but you explained it very well. Thanks for the blog Linkin.
Hi Linkin ,
Your way of explanation is awesome . If anyone explains at the time of interview , interviewer might be surprised for subject knowledge.
Simply awesome!
where can i find part 2?
Nice but i have one query if my bad frnd srch my program in f4 there also dont show my program name for them . becoz if my bad frndz know debugging very well their can do bypassing if their know my program name. These can achieve or not ,actually one of my frnd askd this question and I m working on this.