Accessing Content Objects

BOBJ is a reporting tool and an end user would typically use the BI launchpad to execute reports assigned to her. After logging  in the BI launch pad screen would look something like the one below.

BI Launchpad - Content Folders with Reports
BI Launchpad – Content Folders with Reports

As you can see the content that the user sees is grouped into a hierarchy of folders. During developement of reports need to be  added to folders and the correct folders need to be assigned to the correct set of users. This is the most common example of authorizing access to content in BOBJ and we in the next few paragraphs we would be looking at the security configuration to set it up. Continue reading “Accessing Content Objects”

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.

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

Authorization Trace in BW

The standard SAP authorization trace given by ST01 is not enough for troubleshooting security issues in BW reporting. A ST01 trace will show a basic reference for the two objects S_RS_COMP and S_RS_COMP1 to check access to the query and cube but nothing further than that. SAP provides a completely new authorization trace though the RSECADMIN transaction to troubleshoot analysis authorizations. The error log button gets us to the authorization trace screen.

RSECADMIN - Analysis
RSECADMIN - Analysis

Once we have “configured log recording” for the affected user, the system logs all OLAP data accesses made by the user.

RSECADMIN - Authorization Logs
RSECADMIN - Authorization Logs

Displaying the log data gets us into the following screen which shows the details of the security checks for the user.

RSECADMIN - Authorization Logs 2
RSECADMIN - Authorization Logs 2

The trace first displays the name of the InfoProvider and the query name that the user executed. Next, we have a list of characteristics in the cube for which user has non full (*) access as these need to be checked at a more detail level. Lastly we have the authorization checks for these characteristics with non full authorizations. Its this section of the trace thats typically the most helpful in troubleshooting authorization issues.

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.

Analysis Authorizations

Analysis Authorizations are used to secure individual InfoObjects during execution of queries. If we get a requirement of the form – “user should be only able to see for sales for the US companies but not for the European ones”, Analysis Authorizations are the way forward. In this post we will try to take a closer look at how these authorizations work and how to maintain them.

SAP provides the transaction RSECADMIN for working on different aspects of analysis authorizations. The different tabs of the transaction allow authorization maintenance, user assignment, transport and tracing potential errors. Analysis Authorizations are also be directly maintained through the transaction RSECAUTH. In addition to the tcodes, A person needs access to the authorization object S_RSEC to work with analysis authorizations.

RSECADMIN - Authorizations
RSECADMIN - Authorizations

The figures below shows an analysis authorization to secure 0COSTCENTER

Analysis Authorizations 1
Analysis Authorizations 1

Individual values can be maintained for 0COSTCENTER as shown below

Analysis Authorizations 2
Analysis Authorizations 2

In addition to EQ (Equals) which is used to give access to actual values as shown below, we might also use CP (Character Pattern) for wildcards or BT (Between) for ranges. Also, instead of values, individual hierarchy authorizations or user exit variables might also used for InfoObjects. In addition to actual values or hierarchies, two special characters are often used in authorizations. These are

  • Colon (:) – Colon is used to authorize access to aggregate data. For example, a person with : for 0COSTCENTER would be able to see aggregate data for all cost centers (cost center in the free characteristics section of the query) but would get an authorization error when trying to drill down on 0COSTCENTER. Colon (:) authorization is also needed for all authorization relevant characteristics which are not used in a query.
  • Hash (#) – While loading data into cubes, there might be some fields for which no values are maintained in the data source. Hash is used to authorize these undefined values as otherwise a full acces (*) would be needed for them.

If we look at the first screenshot showing the definition of the analysis authorization, we find that in addition to 0COSTCENTER, the analysis authorization uses three other characteristics. These are

  • 0TCAACTVT (Activity in Analysis Authorizations) – Default value 03(display) is sufficient for reporting. However, 02 (change) is needed for using planning functionality of BI as planning essentially allows updation of data into InfoProviders.
  • 0TCAIPROV (Authorizations for InfoProvider) – We maintain the InfoProviders for which the authorization is meant to give access. Default is *
  • 0TCAVALID (Validity of an Authorization) – Default value is * but can be used to restrict analysis authorization by validity dates.

It is imperative that all three of the above InfoObjects are part of at least one of the analysis authorizations assigned to a user but its good practice to add them to each authorization that you create.

Once created, there are two ways of assigning analysis authorizations to users.

  • Direct Assignment – Direct assignment of analysis authorizations to users is possible by following the path RSECADMIN >> User >> Assignment which calls transaction RSU01 transaction.
  • RSECADMIN - User Actions
    RSECADMIN - User Actions
  • Assignment through roles – SAP provides the authorization object S_RS_AUTH with the single field BIAUTH. Individual analysis authorization values can be maintained for this field and added to the users’ roles.

Reporting – Basic Access

Analysis Authorizations are used to secure individual InfoObjects during execution of queries. If we get a requirement of the form – “user should be only able to see for sales for the US companies but not for the European ones”, Analysis Authorizations are the way forward. In this post we will try to take a closer look at how these authorizations work and how to maintain them.

SAP provides the transaction RSECADMIN for working on different aspects of analysis authorizations. The different tabs of the transaction allow authorization maintenance, user assignment, transport and tracing potential errors. Analysis Authorizations are also be directly maintained through the transaction RSECAUTH. In addition to the tcodes, A person needs access to the authorization object S_RSEC to work with analysis authorizations.

RSECADMIN - Authorizations
RSECADMIN - Authorizations

The figures below shows an analysis authorization to secure 0COSTCENTER

Analysis Authorizations 1
Analysis Authorizations 1

Individual values can be maintained for 0COSTCENTER as shown below

Analysis Authorizations 2
Analysis Authorizations 2

In addition to EQ (Equals) which is used to give access to actual values as shown below, we might also use CP (Character Pattern) for wildcards or BT (Between) for ranges. Also, instead of values, individual hierarchy authorizations or user exit variables might also used for InfoObjects. In addition to actual values or hierarchies, two special characters are often used in authorizations. These are

  • Colon (:) – Colon is used to authorize access to aggregate data. For example, a person with : for 0COSTCENTER would be able to see aggregate data for all cost centers (cost center in the free characteristics section of the query) but would get an authorization error when trying to drill down on 0COSTCENTER. Colon (:) authorization is also needed for all authorization relevant characteristics which are not used in a query.
  • Hash (#) – While loading data into cubes, there might be some fields for which no values are maintained in the data source. Hash is used to authorize these undefined values as otherwise a full acces (*) would be needed for them.

If we look at the first screenshot showing the definition of the analysis authorization, we find that in addition to 0COSTCENTER, the analysis authorization uses three other characteristics. These are

  • 0TCAACTVT (Activity in Analysis Authorizations) – Default value 03(display) is sufficient for reporting. However, 02 (change) is needed for using planning functionality of BI as planning essentially allows updation of data into InfoProviders.
  • 0TCAIPROV (Authorizations for InfoProvider) – We maintain the InfoProviders for which the authorization is meant to give access. Default is *
  • 0TCAVALID (Validity of an Authorization) – Default value is * but can be used to restrict analysis authorization by validity dates.

It is imperative that all three of the above InfoObjects are part of at least one of the analysis authorizations assigned to a user but its good practice to add them to each authorization that you create.

Once created, there are two ways of assigning analysis authorizations to users.

  • Direct Assignment – Direct assignment of analysis authorizations to users is possible by following the path RSECADMIN >> User >> Assignment which calls transaction RSU01 transaction.
  • RSECADMIN - User Actions
    RSECADMIN - User Actions
  • Assignment through roles – SAP provides the authorization object S_RS_AUTH with the single field BIAUTH. Individual analysis authorization values can be maintained for this field and added to the users’ roles.

Select Authorization Concept

SAP provides two different ways of securing OLAP data in BW. The first is the traditional, and till BW 3.5 the only way, using Z authorization objects for reporting. The second way, which was introduced as part of BI 7, uses analysis authorizations. So the first step in BW security, should always be to choose the concept which we want to use in our BW landscape.

We can reach the switch settings option through the transaction SPRO as shown below

SPRO - Select Authorization Concept
SPRO - Select Authorization Concept

Once inside the transaction, we just choose the appropriate authorization concept setting and save our entry. Though its appears to be a single setting, we should give some thought about which authorization concept to use as migrating from one concept to another takes a significant amount of time for design, testing and implementation.

SPRO - Select Authorization Concept 2
SPRO - Select Authorization Concept 2

SAP recommends that for new projects at least we use the concept of analysis authorizations for security as it provides significant advantages over the old concept. There is also the possibility that in the future SAP might stop supporting the old authorization concept completely in their products. Thus in our future discussions on BW security, I would concentrate on analysis authorizations.

Before going into detailed configuration for analysis authorizations, it might be worth to look at a few of the advantages of analysis authorizations over reporting authorization objects.

  • Reporting authorization objects are Z or Y objects of the RSR class (SAP Business Information Warehouse – Reporting). As authorization objects they are limited to a maximum of 10 authorization fields per object. Analysis authorizations have no such restrictions.
  • The new concept allows us to separately secure the navigational attributes used in an InfoProvider. For example, the authorization object 0COSTCENTER can have different security when it appears as an InfoObject in an InfoProvider and when it appears as a navigational attribute for another InfoObject. In the old concept, both these cases will have the same security.
    SAP Business Information Warehouse – Reporting

Query Designer

Query Designer, as the name suggests, is an application within SAP BW which allows us to create new queries or display/ change existing ones. It can be launched by trying to change a query in BEX analyzer or by a separate link in the SAP GUI menu. The options in query designer has changed quite a bit between BW 3.5 and BI 7. However the essential functionality remains the same. Lets start our discussion by displaying a query in the BW 3.5 designer.

Query Designer 35
Query Designer 35

The leftmost bar displays a list of InfoObjects, both characteristics and keyfigures, which are defined for the InfoProvider. The rest of the Designer display the different design areas in the query. Thus we have separate areas for filters, free characteristics, rows and columns. The bottom right area gives a pre-view of the query output. This is how the result from the query will look like once its executed through Bex. We now selectively drag InfoObjects into the different areas of the query depending on our reporting needs. In general, characteristics appear as filter criteria, free characteristics or rows while keyfigures appear as columns. Characteristics also should be restricted to particular values as otherwise all data for them will be pulled into the query result and result in long execution times for the query. Characteristics can be restricted to actual values or to input variables which prompt user for values during query execution. In the displayed query, the filter criteria calendar year/month is restricted to Aug, 2010 while material is restricted to an input variable. We also have an option of using authorization variables, where an input variable is automatically filled by the authorized values for the executing user.

Query Designer also allows the use of calculated key figures, restricted key figures and provides many different options for controlling the display of the InfoObjects. We would not get into these details as our intention is only to concentrate on the security aspects of query design. We end our brief introduction to Query Designer by opening the same query opened in Query Designer for BI 7.Though the look and feel, and certainly the features, is different it has the same basic areas. The difference which is readily observed is a separate tab to contain all the filter criteria. One important factor to note, is while queries designed in the old designer can be opened in the new version, the reverse is not true.

Query Designer 7 - Dislay Query Definition
Query Designer 7 - Dislay Query Definition

BEX Analyzer

BEX Analyzer or Business Explorer Analyzer or Simply BEX is the core reporting tool in SAP BW. It can be launched from the Analyzer icon from the SAP GUI menu or through the transaction RRMX. Its is Add-On to microsoft excel and allows executing of reports (queries) on BW data. It has links for creation/change of queries as well, though the actual updation is done in a separate BW application, the Query Designer.

The screen below shows the BEX toolbar inside Add-Ins and the result of running a query. The different icons in the toolbar allo us to open, save, refresh and change a query. This is a simple test query which shows the amount, price and quantity of a material type sold to different customers. The results are filtered for the calendar year/month – AUG, 2010. In the report below, material and customer are characteristic infoobjects in the cube while amount, price and quantity are the keyfigures.

BEX - Query Result
BEX - Query Result

In addition to queries, Bex Analyzer can also be used to execute or display Workbooks. Workbooks are basically the results of execution of the query. For example, we can save the report obtained above as a workbook. In fact, the different tabs in an workbook can store the results of different queries obtaining data from completely different InfoProviders.

We can readily appreciate that since BEX is really a single application launched through a single transaction, the general transactional based security model might not be as affective to secure the multitude of different queries that can be run though it. A more logical security model for queries will be one which allows to secure on individual infoproviders, characteristics and keyfigures. SAP provides us two methodologies to do just that,reporting authorization objects as used traditionally till BW 3.5 and the newer Analysis Authorizations which were introduced as part of BI 7.