Skip to Content
Author's profile photo Former Member

Authorization tool; I would like to have in Solution Mananger

In my previous project I had an opportunity to implemented Security as well as Solution Manager. It was fun filled experience with many challenging cases from security point of view.

Till the completions of project I figured out most of the time spent was in requirement gathering and refining roles according to business process and studying its technical feasibility. As a novice in security there was a constant feeling that implementing SAP security could have been made easy at many different levels.
Contemplating on it I came up with a Dream Security Application in solution Manager that can be used in all phases.

And expressing the same I started a thread in forums. There were many interesting views and comments from experts and moderators that give a picture of, why the things are the way they are.why dont SAP device a fullproff mehthod for authorization  

In this Blog I am putting the entire discussion as 4 sections for ease of understanding. I have included replies from experts and members as well; I hope they don’t mind it. Also the situation I faced was because I was a first timer and in no way it expresses the method of working of an expert in security. Nor dose it take in account the way in which security project is to be carried out.

So here is how things generally go for a novice Security Consultant –

Working Scenario for Implementing Authorization:

When every a security guy is given a Tcode (of which he is not aware of) on which access is to be control. He will use su24 to check the auth objects or even better makes a new role with the tcode and check for each object how dose it behaves in real word.
If the TX is complex enough, he may even have to use trace and debuggers to figure out where exactly the code is checking which auth object.
Accordingly plays with different values and test it and then come up with conclusion that whether existing auth objects and field are sufficient to meet the requirements or new auth object is to be created.

Difficulties involved in figuring out the right Authorization Object: 

Functional people give requirement in relation with tcodes, org unit and other fields. The challenge is the mapping from the functional (data level) to technical i.e. to authorization objects. It eventually required digging down all objects and field level actives and then testing it.
It is very tedious searching all objects related to tcode in Tx su24. Most of the auth objects are deactivated by default.  You may need to activate it and try out different combination according to your requirement.
Trace and debuggers are not ment for this purpose. These are just work around.Using this work around dose not guarantee 100 % results. Hence most of time trial and error method works out with a new requirement that comes up. For that purpose testing or each field is need to make sure what we need is what we get.

New Conceptual Authorization Application in Solution Manager –

The primary focus here is Solution manager as a tool to achieve this. It is the ideal components for it. It will explore the potential of Solman as it is connected to systems across landscape. Here solution manager will not only help in to gathering and accessing Authorization documents (requirements, technical and implementation) all at one place, but also materializing the authorization requirements. So all authorization task will be performed in solution Manager.

The Main idea is to have a Tx (Program) in Solman similar to Tx:SOLAR01 dedicated solely for authorization tasks.


Just like SOLAR01 the new TCODE can be dived in two frames:

Left Frame -> Will have hierarchy replicating  SOLAR01 used for process blue print defination)   

1. Org Units  2. Master Data  3. Business Scenarios (Module Wise).

Right Frame -> Will have a Authorization matrix for corresponding module or process.  This will having list of tcode as first Colum and All Relevant Roles as first row.

• Clicking on the modules node in BBP will give Authorization Matrix for that module.

• All “Tcode Specific” Authorizations in for a particular process which change according to changes made in BBP (Tx: SOLAR01)• Authorization for Org Unit and Master data level will be given at their respective nodes. Additional features can be provided so that all existing Security Tcodes can be accessed from this application. This can be very much possible as Solman is connected to entire Landscape.


  • Right click on the Listed Tx in Authorization matrix will give an option to take you to su24 for that Tx in the corresponding system.
  • Clicking on the role will take you to PFCG in the corresponding system.
    How will it work –

This application will help at following 3 stages of the Security Project –

1. Preparation of template framework.
2. Determine Scale and Scope of Authorization Requirements.
3. Implementation application security.

1.  Preparation of template.

Here solution Manager will have an “Authorization Matrix “suggesting different role in accordance with the proposed BPPs specified in SOLAR02. Just like all tcodes are listed according to BBP we will have corresponding Roles accumulating the tcode used in it. This will give an idea of what SAP recommends for maintaining different level of security depending on job profiles according to BPP. This can be maintained in one different Transaction all together. Hence we “Enterprise-Wide Role Matrix” maintained in solution manager. As a result Role Implementation Framework Prototype will be standardized. And it will give something to start working on with preliminary data that can be evolved as required. I know we have accelerator in Road maps in Solman. But if we have tcode for it will serve the purpose better.


2.  Determine Scale and Scope of Authorization Requirements

Here you can just specify restrictions at functional and data level for that tcode in the given role.
Gathering functional and data level authorization requirements can also be done. • Clicking on the listed Transactions (in Authorization Matrix) against the roles, would take you to the screen of the Tx.
• We should be able to select access (including data level) to be given for this Tx.
• Org Unit and Master Data level Auth can be specified for a given role using “Org Units” And “Master Data” nodes. As a Result Auth requirements are gathered and documented. This data can be used to implement and review security. This can be done by functional Consultants without even knowing the how it is going to be technically implemented. Solman is a very efficient documenting tool so other feature can also be helpful for the same purpose.


3.  Implementation application security i.e. Creation of Roles.

Now comes the best part. Regarding how the user roles and authorizations are technically implemented. The idea here is specifying Authorization for each tcode for each role graphically without seeing object behind. (not all but most of auth) This will be done using the same program again.

a. How you define the roles should be completely up to you, those who want to group them into tasks can do that, those who like to build at a higher level can do that.

b.  Clicking on the listed Transactions (in Authorization Matrix) against the roles, would take you that tcode specific screen which has a kind of replica of actual Tcode screen where you can specify authorization for corresponding Role as follows : 
       • Add and remove Tabs of the Tcode graphically. 
       • Double clicking on filed will allow you to specify the allowed activity that field. 
       • Also it should have provision for specifying organization level and master data level authorization specific to that tcode.

c.   As we are specifying Authorization graphically without seeing object behind there are chances that there may be confects and if any conflicts. There should be warning and suggestions for such case.

d.   Finally there can be a generate button that will generate the specific role or also takes you to pfcg for the role.And all such similar auth that can be given at tcode level.


As a Result we maintain the authorization without even knowing which Auth Object are used to implement. Auth Objects needs to be modified automatically for achieving this. Or can be resolved in classical way. It can help to remove all ambiguity regarding how the user roles and authorizations are technically implemented. Hence at least 80% of the Authorization can be implemented using this program. Remaining Intricacies in security can still be implemented using current tools. And it can still require same amount of functional and technical knowledge to finalize and complete all task.


Experts opinion on “why things are the way they are”. (Taken from the SDN thread mentioned above)

The complexity comes primarily from the request of customers over years that want to be able to restrict on a specific item/field.
To look at it from a technical point of view only (create a tool) is bypassing the complexity one finds in companies that have (and want to keep) a certain way of working still being able to meet SoD and other security requirements.The delivered SU22 settings (and then SU24) are not always complete or maintained and may differ from the implementation requirements. Of course that is what SU24 is all about… creating an implementation specific tool using standard tools (and coding) to fit the choice of business process design.The tools used security should ideally be as irrelevant as possible, if the intention and abilities of the transaction (or RFC or service) are known. In that sense, a worth while investment from the SAP side is to educate developers to maintain SU22 correctly; and from the customer / partner side to not only change SU24 but also report missing default data to SAP or opinions on the scenarios for the use of the functionality, and of course also train functional folks and developers.SAP delivers some check indicators which may or may not be relevant depending on data used, path through a transaction, configuration. To have a system which dynamically responds to requirements would be so complex that it would have more bugs than it fixes.Of course, that is only the ABAP side of the coin, with main focus on the transactional systems.

What do you think can we get an easy authorization tools to work with or is it best the way it is?

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.