One custom authorization object for all

[Former Member]

I hope you didn't believe it.  certainly, that is not possible, but the number of custom authorization objects can be reduced significantly if you could utilize this authorization object.  I wrote this document few years ago so there may be new technology that might even be better.

---

One custom authorization object for all

There are over 400,000 standard authorization objects in SAP ECC ERP system.  Do we need them all?  The answer is, “Yes.  We need them all.” because these are the authorization object that is embedded within standard functionality of the SAP system.  But what about custom code that requires level of security?  Could we utilize some of those 400,000 authorization objects?  Sometimes “yes”, sometimes “no”.  Most of the companies that I’ve seen created authorization objects that was used by one program or code and could not re-use it for any other program or code that leads to maintaining many authorization objects.  Sometimes, too many.  Will your instance require this custom authorization object only?  I doubt it since there are many requirement from users but I strongly believe that this authorization object can be used to check 80~90% of security requirement within the custom codes. 

Most of custom codes create, modify, view, or execute.  Also, most likely, it is written with different program or code name.  SAP ABAP stack updates system variable such as SY-CRPOG every time the code is executed.  It is updated with the program name that is being executed.  The concept of this authorization object is checking for the program that’s being executed and what actions users are allowed.  It is a very simple concept.

Following is the building of the authorization object.

The screen shot shows the authorization object, Z_PROGRAM1 in custom class Zxxx.  These values can be anything that fits your instance’s naming convention.  However, naming of authorization field should not be changed.  There are only 2 authorization fields, ACTVT & PROGRAM.  The value of ACTVT can be standard, 01-create, 02-change, 03-display, 16-execute, & etc.  The authorization field, PROGRAM, is the program that user will be executing.   The control of this field is very easy if the instance you are working on has good naming convention of programs and codes.  For companies that utilizes name space is even easier since SY-CPROG value starts with name space.  For example, if I had a name space called /paullee/, and I created a program, name would be like /paullee/helloworld01.  The authorization value for PROGRAM would be “/paullee/helloworld01”.  In case I have more than one program and/or codes and the user requires having access to all programs within the name space, the authorization value of PROGRAM would be “/paullee/*”. 

Following would be object documentation.

Literally, the usage in program can be cut and paste in to the code without any modification if you are only executing the program.  The authorization field ACTVT is a 10 character field.  However, it works with 4 character number as it is shown.  I also found that it might be different from version to version.

Once this code is introduced into the program, run the program without authorization to fail the authorization check and see SU53 or do traces on a user with all authorization for this authorization object to find out what authorization value is required.  If you are a developer, perform debug on the program and see what the value of SY-CPROG at the time the code hits authorization check.

Although this authorization object can be used for many programs and codes, there will be occasions that you may require authorization based on organization or document type or etc.  In most cases, people who should execute the program based on those attribute, also has authorization for other SAP transactions that requires it which developer and SAP security admin can utilize.  For example, let’s say there is a custom program to display all the deliveries occurred based on shipping point.  Mostly the report will be used by a lead person in that shipping point who can execute VL02N transaction for that shipping point.  Whether that person can change or display, that user should have authorization object V_LIKP_VST with that shipping point already.  The custom program should check with both Z_PROGRAM1 and V_LIKP_VST authorization objects to ensure the user can only execute the report against that shipping point.  If that does not satisfy the requirement, last resort should be creating a new authorization but I’m sure that will be a rare occasion.

This authorization object may not be the master key to all custom authorization objects, but this authorization object can be used on many applications that security admin does not have to maintain multiple authorization objects such as transporting, making changes, and/or decommissioning.  I hope you will find good use for this authorization object.