Analysis Authorizations – Design

The idea for this article came to me after reading through a question from a visitor to this site. I believe the question is relevant to anyone designing Analysis Authorizations. So even though there are other posts in this blog that talk about how to actually create analysis authorization, this current article is meant to help security consultant in actually applying the concepts while designing security. I will start with reproducing the question below.

Q:  Hi Aninda,

Firstly, thanks for the helpful posts on this site.

I would like to check with you on how the system checks BI auth.
Does it check every possible combination?

For eg: user is assigned with 2 analysis auth as below:
A: plant 1000, purchasing group (PG) 100
B: plant 2000, PG 200

When the user runs a report and fills in the fields with plant : 1000, 2000 and PG: 100, 200,
he/she will actually get no authorization. When I checked the trace, it looks like the system is checking for
1) plant 1000, PG 100
2) plant 1000, PG 200
3) plant 2000, PG 100
4) plant 2000, PG 200

In this case, the authorization failed because there is no such combination for 2 and 3 in my analysis authorization. Appreciate your advice if my understanding is correct and how do we work around this apart from asking the user to run the report separately for plant 1000 and 2000? Thanks.

I will elaborate from my original answer below. Firstly I should re-iterate that SAP does indeed check for the 4 different combinations mentioned , i.e.
1) plant 1000, PG 100
2) plant 1000, PG 200
3) plant 2000, PG 100
4) plant 2000, PG 200

This may be counter intuitive to us from our experience in ECC while looking up data from SAP tables in SE16 or SUIM. However, BI reports only return data when the total result set is authorized. In other words, you need access to all possible combinations for the query to return any data at all. You get everything or nothing 🙂

So the next question that we need to answer is how to give access to plants 1000, 2000 and PG 200, 100?

Here we would need to create two new analysis authorization rather than the ones already in use
Auth 1) Plant 1000, 2000
Auth 2) PG 100, 200

However, these two authorizations end up giving access to the combinations for Plant 1000 PG 200 and Plant 2000, PG 100 in addition to the earlier values. We need to ask ourselves, Is this extra access a problem?

Like most consulting questions, there is no single correct answer to the problem. For some clients this extra access might be okay while for others it might be a strict no. I would start looking at how security is set up in ECC and try to replicate same access in BI. For example, I would think a Buyer in ECC would be assigned to one or more purchasing groups and would be responsible for one or more plants. Its far less likely that a Buyer is assigned to a different purchasing groups for different plants. So the more likely scenario tells me that the extra access with the two new authorizations are perfectly fine and in line with ECC security. However, your client might be using a different configuration for plant and purchasing group security.

In case, the extra security access is not enough, the solution would be to ask the reporter to run the BW query twice. Once for Plant 1000, PG 100 and next for Plant 2000, PG 200.

Transaction & Value Roles

The idea for this post was suggested to me by one of the visitors of this blog, who had put in a comment around the use of value roles in security design. I though that the question was general enough to merit its own post instead of a reply to the comment. Let me first begin with a confession, though I have worked in a few set ups using this concept, I have never understood their effectiveness in security design. For me, value role create  more problems than they solve. I agree that my views are colored by the projects that I have worked on and elsewhere, their use might make a whole lot of design sense. If any of the visitors have any experience in innovative use of value roles which really simplified security design, please feel free to comment. A healthy discussion on the subject will help everyone of the readers including myself!

The transaction and value/controller role concept revolves around creation of separate roles for transactions ( with S_TCODE) and authorization objects with org level values. The latter are the value roles as the individual values for the org levels are maintained therein. Elsewhere they are also known as controller roles or enablers, as they control the final access to a transaction. The transactional role in addition to S_TCODE also contain the authorization objects which do not have org level values. Since the value roles do not have transaction in their menu, the authorization objects are manually added to them. During assignment, both transaction and value roles need to be assigned to a user (sometimes via a composite role). There is no hard rule around the number of transaction or value roles. In a typical scenario, a transaction roles might be created to map the different jobs defined in the enterprise. A possible starting point of such a design will be provided by the user-transaction matrix. After the transaction roles are set up, a few broad value roles are created with authorization objects needed for a functional area (SD, MM, HR, FICO etc). The number of value roles generally will be much lesser than the number of transaction roles and will have all or most of the authorization objects belonging to the functional area.  We can also have separate value roles for display and update and also different ones for the different ones for the various divisions in the enterprise.

I believe the initial logic behind adoption of the value/controller roles was reduction in maintenance effort. For example, instead of maintaining tcodes and authorization objects in all roles, we just add the tcodes to the single transaction role and the authorization objects to the value roles. In fact, since SU24 entries are not involved (authorization objects are manually added to the value roles), value roles will be only be need to be updated for a new authorization object (i.e. an object not used in the transactions being already used). Some people might also consider it to be a cleaner design, to keep the transactions and authorization objects separate.

After knowing the background of value roles, lets explore the problems created by their use. For me the biggest casualty of the value roles, is the loss of all information contained in the SU24 entry for the transaction as transactions and the objects needed for its execution are present in different roles. Without strong documentation practices, we can often end up with a situation where no one has any idea why a particular authorization object was added to a value role. A direct result of the above problem, is the fact that most value roles have more authorizations than are needed for execution of the transaction present with a user through a transaction role. A further problem arises because in many cases SAP allows us to jump to different transaction screens by following navigation options in the menu for a tcode i.e. moving from a display to the corresponding update transaction.  Even though SAP would normally check for update activity in such a case, a S_TCODE  check might not be enforced. Hence, user would get access to an update transaction through the value role even though transaction role only allows the display version. There might be many other such cases, where access present in the value roles might open up extra access with the tcodes present in the transaction roles. Finally the security testing effort is also increased a great deal as without the use of SU24 to guide us, the only way to determine the complete access needed for a tcode is run a trace for each new transaction and check each of the value roles to ensure that they contain required access.

I have already mentioned my skepticism for the value role concept for security design. In fact, I am even unwilling to accept the argument about less maintenance effort for value roles as  the same can be realized with a parent-child role based design. However, there is overwhelming majority of security installations which continue to use value roles. If any senior security experts are currently reading this post, I would sincerely request their comments on the same as its extremely probable that I am missing something about the potential benefits for value roles.

Profile Assignment via OM

In the last article we have already looked at the process of indirect role assignment through OM objects. SAP provides another option to achieve indirect assignment of security through the org structure of the enterprise. This method involves indirect assignment of authorization profiles. Though much less common now-a-days as most companies have moved to a system where access is based on roles instead of authorization profiles, there is really nothing preventing its use in even a role based system.

The basic concept of indirect assignment remains the same. Instead of creating B007 relationships, between the user’s position and object type AG, we maintain infotype 1016 for the position with the profile names. An example screen-shot is given below. Through configuration, its also possible to maintain IT 1016 for other org objects like jobs, org units, tasks, etc.

PP01 - Create IT 1016 (Standard Profiles)
PP01 - Create IT 1016 (Standard Profiles)

To copy the profiles from HR objects to users, the report RHPROFL0 is used with the options shown below. This report can also be scheduled to run in the background everyday at midnight to sync up user access (both PD profiles and general authorization profiles) with a changing org structure.

RHPROFL0 - Copy IT 1016-1017 values to users
RHPROFL0 - Copy IT 1016-1017 values to users

Indirect Role Assignment via OM

We have come across the Organizational Management (OM) component while talking about SAP HCM. The OM component in SAP is used to map the Organizational Hierarchy of an enterprise by means of HR objects and Relationships between these objects. In this post we will discuss about the possibility of using OM to simplify some of the user-role assignments tasks that need to be handled by a security administrator.

Lets start with an sample org hierarchy created in PPOME transaction as shown below. We start with a root org unit ( HR obj O) “IDES Root” with “IDES India” and “IDES Bangalore” under it. ” IDES India” includes the position (HR obj S) of “Director – India” which is also set as the Line Manager for it. The position is filled by person (HR obj P) “Mister Director”. We make the basic assumption that the SAP access for a user corresponds to his position in the org structure of the enterprise.

PPOME - A Sample Org Hierarchy
PPOME - A Sample Org Hierarchy

Consider the access for “Mister Director”. In the case of direct role assignment, any role would be assigned to the user id for “Mister Director” through SU01 or PFCG. Now lets consider, that “Mister Director” get promoted to be the CEO of “IDES Root” and a new person comes to take his place. However, since the roles for the India Director were directly assigned to his user id, he will continue to keep his old access even in his new position. Also the new person filling the position of “Director – India” will have to be manually assigned with enough access to enable him to do his job. This same situation will repeat for every transfer, promotion, demotion (and most other org changes in general) that takes place in an enterprise. For an enterprise with more than a few thousand employees, the effort involved in keeping user access in sync with the org hierarchy is substantial. In addition to the monetary cost of the effort, their is a time penalty as users would need to wait for the User Admin team to adjust their security before they can start using SAP. Indirect role assignment comes to the rescue in such situation and if configured correctly can reduce the routine maintenance effort appreciably. In indirect assignment, instead o directly assigning the roles to user id for “Mister Director” we assign the roles to the position “Director India” (The standard SAP configuration allows role assignments to the OM objects – Position, Org Unit, Work Center, Task and can be used depending on business cases) such that any user occupying the position would automatically get the access needed for “Director India”.

There are four technical prerequisites for the use of indirect role assignment through Org Mgmt

  • An active planning version must be defined in the system. Roles/profiles are assigned to the OM objects defined in the active plan.
  • The User and Personnel masters are linked via the IT 0105 (communication) subtype 0001 (system id). This translates to maintaining the SAP user id for a user in IT 0105, 0001 for the user’s personnel number with an active validity date.
  • The HR_ORG_ACTIVE customizing switch is set to YES in the PRGN_CUST table either as the default value or as an entry in the table.
  • The evaluation path US_ACTGR is defined and suitably adjusted in the system. The evaluation path is actually used by SAP to assign roles to the users during user comparison and is the last and the most vital cog in the wheel. The screen-shot below shows the default definition of the evaluation path in OOAW.
  • OOAW - Definition of US_ACTGR evaluation path
    OOAW - Definition of US_ACTGR evaluation path

Once the above prerequisites are met, we can just go ahead and create indirect role assignments between roles and HR objects. Indirect role assignment through PFCG can be accessed through the “Organization Management” button shown below. The blue lines correspond to indirect role assignments.

PFCG - Indirect Role Assignment through OM
PFCG - Indirect Role Assignment through OM

Clicking the Org Mgmt button opens the below screen where we can check the existing assignments for the role (both direct and indirect). New role assignments can e created using the highlighted button

PFCG - Indirect Role Assignment through OM 2
PFCG - Indirect Role Assignment through OM 2

Roles can also be assigned through PP01. An indirect role assignment is a relationship between object type AG (Activity Group or Role) and HR objects like positions, org units, etc. Below screen shows a new assignment (relationship B007) between the users’ position and the role object (object type AG)

PP01 - Create B007 reln between S and AG
PP01 - Create B007 reln between S and AG

The final step in the process of indirect role assignment is to copy the roles from the HR objects to the users. One of the most common way to achieve this is to execute the PFUD transaction with the option for HR reconciliation checked. In productive systems, this program is normally scheduled to run everyday at midnight to sync user access with a changing org structure.

PFUD - User Master Reconciliation

PFUD - User Master Reconciliation

The critical success factor for indirect role assignment is to understand how correctly your org hierarchy mirrors the roles/ responsibilities of your users. Some of the questions that need to be discussed with your business owners, functional consultants and security team are

  • What is the correlation between the roles/responsibilities users and their position in the org structure?
  • Who will be responsible for maintaining the org structure and how frequently?
  • Will users need their old access even if they move to a new position?
  • How will contractors be given access? Contractors are normally not part of the org structure and don’t occupy a position. So do you continue to directly assign roles to contractors or do you link them to the org structure in some way (for example through positions/jobs/tasks)?
  • Are you only concerned about a central ECC system or are there other systems in the landscape (BW, CRM, SRM, APO, etc)? Will the roles assigned in these other systems also be determined by the users’ positions in ECC?

Parent & Derived Roles

The concept of parent and derived roles was introduced by SAP to simplify role administration tasks. Its specially helpful while mapping security for large enterprises spread across multiple geographies or divisions. A child role derived from a parent role will have all attributes (transactions/ authorization object values) same as it parent except the values of the Organizational Level fields (plant, company code, sales organization). Thus maintenance is simplified as only the org levels need be maintained at the derived role level. This also ensures that there is no opportunity to make mistakes during authorization maintenance for the multitude of derived roles and also reduces testing effort for roles.

Creating the parent role follows the same process as creating any other single role. In the example below we create a global role “Z_CREATE_SO_GLOBAL” which allows the creation of Sales Orders (transaction VA01) for all company code, sales orgs.

PFCG - Define Parent Roles
PFCG - Define Parent Roles

With the parent already defined we create a child role “Z_CREATE_SO_US” which allows SO creation for the US companies. We maintain the parent role name as shown below.

PFCG - Derived Roles - Definition
PFCG - Derived Roles - Definition

The menu for a derived role can not be individually maintained as all entries are inherited from the parent.

PFCG - Derived Roles - Menu can not be changed
PFCG - Derived Roles - Menu can not be changed

Now we maintain the org levels values relevant for the child role. In the example below, we have used a dummy value of @ but in a production system the correct value for org levels should be used. The other other need not be maintained at this stage. Now we save the authorization entry for the derived role.

PFCG - Derived Roles - Maintain Org Levels
PFCG - Derived Roles - Maintain Org Levels

To populate the rest of the authorization values for the child role, we go into the authorization maintenance screen for the parent and click the button “push from gl”. This option pushes the non org level values from the parent to the child role and generates the profiles for both.

The most critical success factor for a parent-derived role concept is how well, the different business processes mapped by SAP roles are mirrored across the different divisions in an enterprise. In other words, a parent-derived role concept will not be very beneficial in case an enterprise follows different business process in its different subsidiaries.

Composite Roles

Till now, all our discussion on role administration has been concentrated on creation and maintenance of single roles. A single role as we have seen till now is a collection of tcodes and/or authorization objects. However in addition to these, SAP also allows to create composite roles which contain one or more single roles. In this post, we will discuss the tecnical and business reasons for working with composite roles.

During role creation, the PFCG initial screen allows us to choose whether we create a single or composite roles. Once created, there is no way to changing a single role to a composite or vice versa. In the screen below, we look at the role definition of the SAP_AUDITOR composite role provided by SAP to allow the use Audit Information System (AIS). You will notice that the individual tabs inside PFCG are different from those for a single role. for ex, we do not have the common transaction or authorization tabs. Instead we have the Roles tab and also a menu tab. The roles tab allows us to specify any number of single roles that constitute the composite role as well as the system for the roles. This is important in a SAP system with CUA installed as a composite role defined in the central CUA system can point to roles defined in the child systems.

PFCG - Composite Role Definition
PFCG - Composite Role Definition

Even though transactions can not be directly added to a composite role, a composite role can have its own menu structure. We display the same through the Auditor role provided by SAP

PFCG - Composite Role Menu
PFCG - Composite Role Menu

Depending on role design or user assignment strategies, composite roles can be used in a number of ways. Lets look at a few scenarios using composite roles.This is not an exhaustive list in any way but just meant to give an idea of the common uses for composites

  • Single roles are mapped to tasks performed by users . Since a typical user performs multiple tasks, the total access for a user is represented through a composite role which includes the individual task roles.
  • Access is divided into transaction role ( which contain transactions but no authorization object access ) and value/controller roles (authorization objects but no transactions). Complete access is represented through a composite role with the transaction and value roles.
  • The entire system landscape consists of a number of separate SAP systems (like ECC, BW, SRM, CRM etc.) and users are administered through a CUA connecting the individual systems. A user getting role A in ECC will need the corresponding role B in BW and role C in CRM. This can be achieved through a composite role created in the central system which links the individual roles in the different systems.

Authorization Groups (BRGRU)

Authorization Groups allow us to secure access to various entities in the SAP landscape. The most common application of authorization groups is to secure tables but they can also be used to secure other objects like customers, vendors, accounts or materials. In fact authorization groups are represented by the authorization field BRGRU and they form part of quite a few authorization objects. However lets start our discussion with the example of table authorization groups. Table authorization groups are created through the SE54 transaction shown below.

SE54 - Inital Screen
SE54 - Inital Screen

To secure access to tables/views through authorization groups, we need to assign it an authorization group. We have the choice of using any of the existing authorization groups or create a new one for our table. Both these activities can be completed through the SE54 transaction as shown below.

SE54 - Create Table Authorization Groups
SE54 - Create Table Authorization Groups

Note that the figure above shows the existing auth-groups created in the system. The entry “S_TABU_DIS” appears at top of the screen as this is the auth groups assigned to the table needs to be maintained for the S_TABU_DIS object with the correct activity (02 – change, 03 – display, etc) in the users’ role to complete the process of securing table access. Another point to remember is the fact that a table without any auth group maintained for it, is considered to be linked to the &NC& auth-group. So for these tables, &NC& need to be maintained in S_TABU_DIS.

SE54 - Assign Authorization Groups
SE54 - Assign Authorization Groups

Now that we are done with the use of auth groups for securing table access, lets check out their use in securing other SAP applications. To better understand the subsequent use of auth groups lets start with a display of the BRGRU field (which represents them in authorization objects) in SU20. You will note that the BRGRU field has a length of 4 and has a check table TBRG. The TBRG table is the central repository of auth groups defined in the system. When creating new groups through the SE54 transaction, we are actually accessing this table filtered for S_TABU_DIS.

SU20 - Definition of field BRGRU (Authorization Group)
SU20 - Definition of field BRGRU (Authorization Group)

To create auth groups for use in other objects, we need to directly access the TBRG table. We can use SM30, SM31 or SE16 for creating new entries. The figure below shows this table being maintained through SM30. We create entries for the F_LFA1_BEK object which is used to secure access to vendor master records.

SM30 - Creation of entries in TBRG table
SM30 - Creation of entries in TBRG table

Now to secure vendors through the created auth groups, we need to update the vendor master (transaction FK02) as shown below with the same and maintain the same values in the F_LFA1_BEK object in the users’ roles.

FK02 - Change auth group for vendor
FK02 - Change auth group for vendor

Similarly auth groups can be maintained for customers as well through the XD02 transaction as shown below. In this case the TBRG entries are for the F_KNA1_BED object.

XD02 - Change auth group for customer
XD02 - Change auth group for customer

RSSM – Reporting Authorizations

In all the previous articles on BW security, we have already looked the current method of BW security through analysis authorizations. However, even now its possible for customers to continue to use the old security concept using reporting authorization objects (customer created authorization objects of the RSR class). Since there are still quite a few installations that continue to run in the old model let us have a brief look at this concept of BW security.

The basic transaction for maintaining BW 3.5 security is RSSM. The initial screen of the RSSM transaction can be divide into two main areas as shown below. The upper area is used to create new authorization objects whereas as the lower area is used to configure the checks for authorization objects for the individual cubes.

RSSM - Initial Screen
RSSM - Initial Screen

It is here that we create the the RSR authorization objects. During creation we have the choice of adding any of the authorization relevant InfoObjects defined in the system. However note that since these are authorization objects ( as opposed to analysis authorizations), maximum number of fields are limited to 10.

RSSM - Create Reporting Authorizations
RSSM - Create Reporting Authorizations

Once created, the second step is to check the relevant authorizations for the individual infocubes. This activity is also performed through RSSM as shown below. Whenever a new Infocube is created in BW, by default all possible authorization objects ( these are the authorization objects which contain any of the InfoObjects defined in the cube) are shown to be checked for it. Its the security administrator’s job to un-check all the unnecessary objects.

RSSM - Check Auth Objects for InfoProviders
RSSM - Check Auth Objects for InfoProviders

Like Analysis Authorizations, checks for reporting authorization which occur during query execution can not be caught through the standard security trace (ST01). We use the transsaction RSSMTRACE to trace security checks for reporting authorization objects. For individual users to be traced, they need to be added to list below. A security trace is generated during query execution for all the listed users. Subsequently the trace can be displayed through the same transaction for analyzing possible security errors.

RSSMTRACE - Troubleshooting Reporting Authorizations
RSSMTRACE - Troubleshooting Reporting Authorizations

Context Solution

In the modern enterprises, its very common that dual responsibilities are performed by the same individual. For example a Line Manager in the Training department of an Organization needs access to certain infotypes (like org assignment, personal data, education, etc) for all employees as part of the process structure. In addition to the above, by virtue of his position in the org hierarchy as a Line Manager, he would also need significantly more access (like basic pay for instance) to the employees who report up to him. This is problem of contextual security and is can not be handled properly through the structures that we have covered so far.

Let us investigate further about the possible security solution in this case and try to understand why it might not meet the full requirements. We would need at least two roles for the training manager – on role with training infotypes and a second one with infotypes needed by the line manager. Further we also likely to have two PD profiles as well – on with access to all employees and the other with access to only the direct reports. When the 2 structural and general authorization profiles are assigned to the same person, like to the Training Manager in our discussion, we find that he has access to both sensitive and non sensitive infotypes for all employees. The sensitive access is not limited to only the direct reports as the security system has no way of understanding that access in the manager role needs to be restricted to only the direct reports (the people who are part of the manager PD profile).

The context solution introduced as part of SAP R/3 4.7 seeks to address this very gap in HR security. The context solution introduces new authorization switches and the corresponding authorization objects. To switch on checks for any of the new objects, the corresponding switches should be set to 1. Its also customary to switch off checks(value 0) for the non context authorization objects. The relevant switches are given below

  • AUTSW-INCON HR: Master Data (Context) for object P_ORGINCON
  • AUTSW-XXCON HR: Master Data – Enhanced Check (Context) for object P_ORGXXCON
  • AUTSW-NNCON HR:Customer-Specific Authorization Check (Context) for customer specific authorization object. The switch corresponds to AUTSW-NNNNN (HR: Customer-Specific Authorization Check) in the non context solution.

In addition to the three switches above there is a fourth switch used by the context solution. This last switch – AUTSW – DFCON – HR: Default Position (Context) – is analogous to ORGPD switch used in normal structural authorization as it controls access to non integrated personnel numbers (persons who are on a default position and as a result are not mapped to the organizational structure).

The fields for the individual authorization objects P_ORGINCON and P_ORGXXCON are given below.

P_ORGINCON

Authorization Field Long Text
INFTY Infotype
SUBTY Subtype
AUTHC Authorization Level
PERSA Personnel Area
PERSG Employee Group
PERSK Employee Subgroup
VDSK 1 Organizational Key
PROFL Authorization Profile

P_ORGXXCON

Authorization Field Long Text
INFTY Infotype
SUBTY Subtype
AUTHC Authorization Level
SACHA Payroll Administrator
SACHP Master Data Administrator
SACHZ Time Recording Administrator
SBMOD Administrator Group
PROFL Authorization Profile

You will notice that new authorization objects differ from the corresponding old objects in a single respect. Both of these have the new field PROFL (Authorization Profile). The PROFL field is meant to store the value of the PD profile for which each general authorization is valid. In other words, the PROFL field serves to link the general authorization with the corresponding structural authorization. Context problems, like the one we discussed about the Training manager, can now be easily solved by maintaining the correct PD profile on the role.

The context solution is truly a welcome addition to the other security features of SAP HCM as it allows us to solve scenarios which couldn’t be solved with the means at our disposal till now. However it comes at the cost of increaded maintenance effort as now in addition the PD profiles assigned to the user, we need to maintain the correct PD profiles for the role as well. Also, we should remember that the context solution only addresses the context problems for accessing people (PA master data). There is still no context solution for PD data secured through PLOG.

Saving Workbooks in Roles

Though creating a report in SAP BW is typically much easier than creating one in ABAP, most reporting users are involved in actually running reports and interpreting the results rather than designing them. As a result the task of designing reports is often left to a select group of power users who are well versed in the knowledge of creating queries and formatting their outputs into suitable form for the use of other users. The output of one or more queries formatted in excel, which might include charts or higlight different data rows or columns, to facilitate their use for enterprise level reporting are called “workbooks”.

Once constructed, these workbooks, or even direct queries, need to be rolled out to the end users. Since the queries and workbooks are defined on InfoProviders, exploring the InfoProviders in BEX Analyzer would show all the reports defined on them. BW also provides a way of saving queries or workbooks into select folders by the power users as shown below.

BEX - Save Workbook In Role
BEX - Save Workbook In Role

Technically the folders are implemented as SAP roles without any authorization data. The folder roles are just placeholders to store queries/workbooks. Once the folder roles are assigned to the end users, they can just look into the folders roles assigned to them rather than having to search for the individual reports under the InfoProviders. This is beneficial as typically a InfoProvider will have a huge number of reports defined on them, many of which might not be applicable for all end users. Also, saving the important reports in roles saves the user from having to remember the InfoProvider on which a report is defined. In fact, we can take this scenario a step further by actually hiding the InfoProvider button from the open query/workbook dialog so that an end user can only access the reports which are specially designed for them. Hiding of the InfoProvider button is accomplished through the use of the S_RS_FOLD authorization object. Adding the object with a value of “X” to a user master ensures that the InfoProvider button is hidden from view in the open query dialog.

To save a query or workbook two authorization objects are needed to be present with the user – S_USER_AGR and S_USER_TCD. S_USER_AGR should have change access to the roles where the reports are going to be saved. S_USER_TCD needs the value RRMX.

Since the folder roles are modified by power users rather than the security administrators, a different transport strategy should be followed for them. In case, power users design reports directly in the productive environment, folder roles should only be transported to production once during the time of their creation. Any subsequent transport will wipe out all the new reports added to them. In the second case, a report is deigned in the development environment, tested and then moved to Production. In such a case, folder roles need to transported similar to any other authorization role.