Skip to Content
Author's profile photo Former Member

One custom authorization object for all

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.   

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Alex Ayers
      Alex Ayers


      Maybe I have misunderstood your post but I'm not sure I understand what purpose this object fulfils over and above standard mechanisms.


      We have a new program that needs to be executed so we assign it to a transaction code.  For the sake of hygiene we also assign an auth group against the program.  Assuming that normal basic practice is adhered to we don't have anyone able to directly execute programs etc.

      That covers program execution, now we have the treatment of the data accessed / functionality performed by the program.

      In your deliveries example you already say that you incorporate an additional check against a standard auth object V_LIKP_VST.  I agree that if we are doing something covered by standard SAP functionality then we should as default look to using the relevant controlling auth object.   Only when there is new functionality then should we create something new.



      Author's profile photo Former Member
      Former Member
      Blog Post Author


      Thank you for having interest on my post.  Using the t-code & auth group also works as well for executing a program for single purpose.  However, sometimes a program can have create, change, and display function since underlying logic is similar.  Or one can execute report and send e-mail but the other can display only.  In such case, if you are assigning a t-code, you will have to create multiple t-codes and programs.  And then link them.  Assigning t-codes might be easy only if strict naming convention is used and followed diligently.  This object could give more flexibility.  Program name can start with z or y and then followed by area such as FI or MM so users can access only their area.   Also for t-code, only sa38 could be given at development stage.  As needed, t-code can be assigned later.

      This object is not a magic bullet but this is a very good auth object to cover majority of abap programs without creating too many.  I also see that there are good aspect to what you are practicing.  Matter of fact, I use that sometimes as well.  It is just a different approach and one should be able to decide what works for them.

      Please feel free to contact me if you have any question.

      Thank you.

      Author's profile photo Alex Ayers
      Alex Ayers

      Hi Paul,

      T-code & auth group to control initiation of transaction is the standard process for any program that should be executed by a "human" user.  As with standard SAP the next step is to use relevant (and preferably standard where possible) auth objects to control at the more granular level.  You don't need multiple tcodes or programs, just use of the standard objects in the proper manner.  If we take your example of V_LIKP_VST, we already have the ability to differentiate between create, change, display through the activity field.  I suppose I just don't see what this additional auth check can give us if proper security coding standards are followed in the first place.

      Anyhow, as you said it is a different approach and having good options is never a bad thing!