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.

Administrator Workbench – RSA1

In the present article, we will explore some of the common transactions/tools used in SAP BW. By no means is this a comprehensive list but the transactions referred to here are certainly among the more common ones and needed almost on a daily basis. We have already mentioned that BW security is different from ECC as the security requirements in an OLAP environment are significantly different from an OLTP system. However other than the reporting transactions which use the OLAP security model, SAP BW also contains a huge number of transactions, typically dealing with administration of the BW system or SAP Basis, which continue to use the conventional authorization model using authorization model.

We start our discussion by looking at the BW Administrator Workbench (transaction RSA1) – The administrator workbench is the central cockpit used for the administration of almost the entire BW system. As shown below, the RSA1 main screen can be divided into three general areas. The extreme left area, allows us to chose BW modelling components like Infoproviders, InfoObjects, InfoSources and DataSources. All of these components form part of the ETL (extraction, transformation and loading) concepts in SAP BW. Choosing any of the components, opens a view with a list of objects of the said type in the middle portion of the RSA1 screen. For example, if the component InfoProviders has been chosen, the main screen area shows a list of InfoProviders built in the specific BW installation. Individual BW components represented by different icons, the double diamonds being InfoAreas, the cubes being InfoCubes and the cylinders being Operational Data Store (ODS) objects. InfoAreas are not InfoProviders themselves but help to group similar InfoCubes under them. Other than InfoCubes, ODS objects, Multicubes and Infosets are other types of InfoProviders which can be encountered.

RSA1 - Initial Screen
RSA1 - Initial Screen

Right-clicking on an InfoProvider/InfoArea opens up a context menu which allows us to carry out different operations on the said object. For example we can create a new InfoProvider or change/display an existing one. The details of the chosen InfoProvider is now displayed in the right-most portion of the screen.

An InfoCube in general is made up of a number of information units called InfoObjects. These store data about the objects that are reported on. We can display a list of infoobjects defined in the system by choosing the InfoObjects option from the left hand screen as shown below. A right click on an individual InfoObject and following the options in the context menu allows us to display/change details for an InfoObject. InfoObjects can be of two types, Characteristics and Keyfigures. For example an InfoCube which stores sales data will store data about Customers. In this case, Customer is an characterististic which is part of the sales cube. Monthly unit of sales or similar data will be a keyfigure. As we can appreciate, Characteristic and Keyfigures store different kinds of data. They appear differently in reports and are secured through means. From the security standpoint, the fact whether we can selectively control access to an InfoObject is controlled by the contents of the Authorization Relevant flag in the explorer tab for an InfoObject. In the screen below, InfoObject 0COSTCENTER is marked as authorization relevant.

RSA1 - display infoobject
RSA1 - display infoobject

InfoObjects in turn can also have their own attributes. Following the earlier example, the InfoObject Customer would have attributes like Customer Address, Bank Details, Tax number etc. The following screen shows the the attributes of InfoObject 0COSTCENTER. We can observe that the attributes can be two types, Display attributes (DIS) and Navigational Attributes (NAV).Security for a navigational attribute can be enabled by switching on the authorization relevant flag shown in the screen below. The latest version of BW (BI 7) allows Navigational Attributes to be secured differently from the base InfoObject. Thus BI 7 can allow different security for InfoObject 0COMP_CODE and the navigational attribute 0COSTCENTER_0COMP_CODE depending on requirements.

RSA1 - Display nav attributes
RSA1 - Display nav attributes

Introduction to BW

SAP Business Information Warehouse or SAP BW or SAP BI is the Business Intelligence and Data Warehousing Product in SAP Netweaver Suite. Being an OLAP system, it has it own security requirements which are often different from a standard OLTP system like SAP ECC and hence this separate discussion. However, before getting into the nitty-gritties of BW security, let us first take some time off to discuss data warehousing in general and how SAP implements it the SAP BW solution.

A data warehouse (DW) is a database used for reporting. Its usually separate from a database used to store transactional data as the goals of reporting is significantly different from OLTP systems. While OLTP systems are optimized for preservation of data integrity and speed of recording of business transactions through use of database normalization and an entity-relationship model, OLAP systems are optimized for speed of data analysis. Frequently data in data warehouses are denormalised via a dimension-based model. Also, to speed data retrieval, data warehouse data are often stored multiple times—in their most granular form and in summarized forms called aggregates. Data warehouse data are gathered from the operational systems and held in the data warehouse even after the data has been purged from the operational systems.

Having a separate data warehouse system is beneficial in many respects

  • A data warehouse provides a common data model for reporting irrespective of the source of data. Its common that data from multiple operational systems are loaded into a central data warehouse.
  • A data warehousing solutions helps in the implementation of an efficient decision support systems where key users get access to key data about the enterprise to understand past histories and make future forecasts.
  • Its typical that reporting on historical data is time intensive. A separate data warehouse allows execution of complex queries without unduly affecting performance of operational systems.

The structure of the SAP BW solution can be divided into the four general layers given below. Each of these layers come with their own tools and will be discussed in the next article.

  • Extraction, Transformation and Load (ETL) layer is used for extracting data from one or more sources, applying transformation rules on extracted data and loading it into the Data Warehouse Area.
  • Data Warehousing layer consists of various SAP BW specific data structures (e.g. Data Store Objects, InfoObjects,  InfoCubes, etc) to store information.
  • Presentation layer which comes with tools to analyze data stored in the data warehouse and allows creation and presentation of reports for end users.
  • Planning and analysis capabilities – In addition to reporting, the latest version of SAP BW provides capabilities for the user to create planning scenarios and perform tasks such as budget calculations.

A related development in the history of SAP BW was SAP’s acquisition of Business Objects (BO). BO has introduced a number of new presentation tools into the SAP Business Intelligence landscape like Crystal Reports,  Xcelcius, InfoView. Other than Crystal Reports which introduces some new security concepts, most of the other tools allows the use of the current security model used for BW in general.

LSMW – Mass User Creation

LSMW stands for Legacy System Migration WorkBench. Originally it was a tool supplied by SAP to migrate data from a legacy system to SAP. However, as we will see in this article, it can be used to upload almost any data into SAP. In the present case, we will be creating a lsmw script to create a bunch of user ids, a job which is common for any security administrator. Since lsmw is based on sap BDC (batch-data-communication sessions) we would have to first create a recording to store the entire sequence of actions involved in creating a user, read the user data for a set of users from a data file and use the read data to create a session for user creation. At the final step we would run the session to actually create the users. Though I have taken the example of user creation, by no means should it be assumed that this is the only application of lsmw in security. As long as you can create a recording for a sequence of repetitive actions, lsmw can step in and lighten your load.

To start LSMW we use the transaction “lsmw”. We start create a project, subproject and object as shown below.

lsmw - create project
lsmw - create project

Once the project is created we are greeted with the lsmw main screen showing a set of actions needed to create the complete script. Depending on the nature of the script and the data all or some of these option need to be updated.

lsmw - main screen
lsmw - main screen

Step 1 – We start by maintain the object attributes. The most important attribute which needs to be specified is the name of the recording which will be used to create the BDC session. A recording is basically a set of actions that the script will replicate during executing. We can create a recording from following the menu options in the same screen. In the present case, we create a recoding for the SU01 transaction and fill up the various input fields needed to create a user.

lsmw - maintain object attributes
lsmw - maintain object attributes

Step 2 – We create a source structure to store the data needed for the script. This will store the user attributes needed by the script.

lsmw - display source structure
lsmw - display source structure

Step 3 – Next we maintain the data fields in the source structure. In the present case, I have only used the data fields – system id, last name, first name, department, email, user group and password. Nothing is really stopping you from using more or less fields. Note that unless all users use the same roles, it would be difficult to incorporate role addition into the same script.

lsmw - source fields
lsmw - source fields

Step 4 – Next we maintain the structure relations. Since we defined only one structure in our script, we accept the default values suggested and click save. This single data structure is used as the data source for the recording that is used to create each user.

lsmw - maintain structure
lsmw - maintain structure

Step 4: Maintain field mapping between the data structure and the fields used in the recording.

lsmw - map structure fields
lsmw - map structure fields

Step 5: In the next screen we can define our own fixed values, translations or routines to be used in the script. In the present script, these options are left unused.

lsmw - conversion routines
lsmw - conversion routines

Step 6: In the next screen we define the path and format of the input files which would actually store the legacy data meant to be loaded by the script. We have used a csv file in the local machine as our data source.

lsmw - specify input files
lsmw - specify input files

Step 7: Next we assign the data from the file to any of the structures used in the script. The present script uses a single file and a single data structure. So we just accept the default values suggested.

lsmw - assign files
lsmw - assign files

Step 8: Next we import the data from the source file

lsmw - import data from file
lsmw - import data from file

Step 9: On clicking execute we get the next screen displaying details about the data read. The input file in our case had 33 records for creation of 33 users.

lsmw - show details for import data
lsmw - show details for import data

Step 10: We can display the read data to verify that input data has been correctly imported into the script.

lsmw - display imported data
lsmw - display imported data

Step 11: The next 2 steps are converting imported data and displaying the converted data for verification. Since, we use imported data without change, these options remain unused for our script. Finally we generate the BDC session for our recording and using the imported data from the source file. Once the BDC session has been successfully generated we use the last screen option in lsmw or transaction SM35 to execute the session. If the recording is without errors and the data is correct, executing of the session will create the 33 users whose attributes were originally provided in the source file.

lsmw - generate BDC session
lsmw - generate BDC session

LSMW is very similar to creating a recording through transaction SHDB, generating an ABAP report for the recoding and modifying the generated code to read a source file and use the data to generate a BDC session. A seasoned ABAP developer might prefer this method as custom code provides a greater degree of flexibilty to answer complicated user requirements. However, custom code invariably results in greater maintenance and testing effort. So finally which method you end up following will probably depend on your own special requirements.