Professional Documents
Culture Documents
Authorization Concept Overview and Setup Guide: For Hovitaga Opensql Editor and Hovitaga Report Generator
Authorization Concept Overview and Setup Guide: For Hovitaga Opensql Editor and Hovitaga Report Generator
Version 1.0
2012.06.06.
1
Table of contents
Overview............................................................................................................................................................................ 3
Transaction level authorizations.................................................................................................................................... 3
Table group level authorizations ................................................................................................................................... 4
Record level authorizations ........................................................................................................................................... 4
SAP standard line-oriented authorizations ................................................................................................................ 4
Custom row level authorizations............................................................................................................................... 4
Field level authorizations............................................................................................................................................... 5
Objects shipped............................................................................................................................................................... 26
Authorization Objects .................................................................................................................................................. 26
Authorization Object ZSQL_COMM ..................................................................................................................... 26
Authorization Object ZSQL_RES........................................................................................................................... 26
Authorization Object ZSQL_CLSP......................................................................................................................... 27
Authorization Object ZSQL_COL .......................................................................................................................... 27
Authorization Object ZSQL_MAIN ....................................................................................................................... 27
Predefined Roles .......................................................................................................................................................... 28
Role ZSQL_USER .................................................................................................................................................. 28
Role ZSQL_DEVELOPER ..................................................................................................................................... 28
2
Overview
The authorization system of Hovitaga OpenSQL Editor and Hovitaga Report Generator is
exactly the same. Here you can see an overview of the whole authorization concept:
The SAP standard authorization object S_TCODE is used to control who can start the
transaction.
3
fig 2. Transaction check with S_TCODE
The authorization system uses the SAP standard authority objects S_TABU_DIS to control
access to table groups and S_TABU_CLI to control maintenance of client-independent
tables. This is done both for reading and writing operations.
For example to filter entries in the VBAK table (Order headers) by sales organization
simply assign authority object V_VBAK_VK0 to the table. To filter entries by plant in table
MARC (Plant data), assign authority object M_MATE_WRK to table MARC. If these
authority objects were already used in the SAP system, then the roles, profiles etc. do not
need to be changed, no other user maintenance effort is required.
4
Field level authorizations
In addition to the record level authorization query results can be filtered on field level also.
For example, certain users could see the contents of the salary field in a table, others
could not, depending on the authorizations.
There is a custom authority object that controls what columns may a user access in a
database table. This can be maintained with the standard SAP tools without any special
customizing effort.
5
General comments
Keep in mind that if you change the authorizations of a user, in order for the changes to
take effect the user must log out and log in again.
Please note that authorizations are not checked if the SQL query is using the addition
„client specified”. The reason is that authorizations are always checked for the logon client
anyway. In order to still have protection, S_TABU_CLI and ZSQL_CLSP are checked for
authorization to maintain client-independent tables and to use the “client specified” SQL
addition.
If you create a new role for the OpenSQL Editor, the ZSQL_COL authorization object must
be added. If you do not want to limit the columns displayed, add a star chatacter to the
table name and field name.
6
Step by step tutorials
As a first step, we will create a new authorization group in transaction SE54. Select the
highlighted radiobutton and press „Create/change”.
7
fig 4. Creating a new authorization group
As a second step we will assign our table ZFLIGHTS to this new authorization group. To
do so, select the last radiobutton in SE54 („Assign Authoriz. Group) and press
„Create/Change”. A popup window will appear where we can select how we should find
the records we want to work with. Since we are creating a new entry, this is not important
now.
After selecting a range of authorization groups and pressing enter, we can add our new
entry to this customizing view. Keep in mind that one table can be part of only one
autorization group, but one authorization group can contain many tables.
8
fig 7. Assigning table ZFLIGHTS to authorization group ZFLI
In this example we deliberately do not assign authorization to our test user, so we can see
that the OpenSQL Editor will refuse access to tabe ZFLIGHTS:
If you want to protect cross-client tables, a second step in the table access control is
required, which is based on the object S_TABU_CLI. The object consists of only one field
CLIDMAINT. The value for this object is 'X' (indicator for cross-client maintenance). The
9
object S_TABU_CLI is the object that especially protects the client-independent (also
called cross-client) tables.
The indicator 'X' does not automatically allow maintenance, the access scope is still limited
through the field values in ACTVT of the object S_TABU_DIS.
The example uses a custom table which is a copy of table SFLIGHT, which is included in
SAP systems for demonstration purposes. This holds flight information. Our goal is to filter
the table contents by Carrier ID (Airline Code). So for example a user who is responsible
for Lufthansa flights must only see records related to Lufthansa and nothing else.
10
We have also created a maintenance view for this table.
11
S_TABU_LIN Customizing
The customizing entries in the IMG can be found under SAP NetWeaver - Application
Server - System Administration - Users and Administration - Line-oriented Authorizations.
When „Define organizational criteria” is executed, we create a new entry for our
organizational criteria, which is called Flights.
The „Table-independent” checkbox can be very useful. If it is not checked, then this
organizaional criterie will only filter the contents of the table that we later will specify. If it is
checked, then it will filter the contents of all tables, whose key fields are related to all
domains specified in the attributes. We used the first option in our example to filter only
table ZFLIGHTS.
After defining the organizational criteria, we have to maintain the attributes of it. We will
maintain two attributes, which will check the first two key fields of the table (Carrier ID and
Connection ID).
12
fig 13. Maintaining the first attribute
After creating the first attribute, we have to maintain the table field details. Here we can
define which table we want to filter and which key field does the attribute filter. Keep in
mind that only key fields can be used.
13
We will do the same process for the second attribute and table key field:
So after setting this up, we can see that for our new organizational criteria called ZFLIGHT
we have two attributes: the first one for the Carrier ID and the second one for the
Connection ID.
After defining the oranizational criteria, we have to activate it using the second customizing
transaction in SAP NetWeaver - Application Server - System Administration - Users and
Administration - Line-oriented Authorizations. Simply check the Active checkbox and save.
14
fig 17. Activation of organizational criteria ZFLIGHT
15
On the third tab called „Authorizations” press button „Change Authorization Data”. This will
call a screen where we can actually define what data can the Lufthansa administrator see.
fig 19. The marked button will call the screen we will use
The next screen will be empty be for the first time. It is time to authorization object
S_TABU_LIN to this role using the „Manually” button (Manual entry of authorization
objects). After adding S_TABU_LIN to the role, we will see the following screen:
16
fig 20. Press this button to add an authorization object to the role
The icons will be yellow when the exact values are not maintained for the authorization
objects. To maintain them, press any of the pencil icons. A popup window will appear
where we select our new organizational criteria:
Another popup window will appear where we will set up which exact values the user can
see. Here we make sure that the Lufthansa administrators will only see records where
CARRID equals „LH”. The star character is the wildcard character, so all flight connections
will be visible for Lufthansa. The Activity field can be used to separate Display and Change
operations. Using the star character this setting will be valid for both operations.
17
fig 3. Lufthansa admins should see only LH flights, but all flight
connections
After successfully maintaining the values for the authorization object, the icons will turn
green as seen here:
The last step in PFCG is to generate the profile. Press Shift-F5 or button „Generate” to do
so. A popup window will appear where you can give a name to the profile. You can use the
default if you like.
18
fig 24. Giving a name to the generated profile
The very last step is to assign our new role to our test user. To do so, use transaction
SU01.
Simply add our new role on the „Roles” tabsheet and save.
Then testing our new authorization setup, we can see that the standard maintenance view
filters the table contents for user ZLH_USER, only LH records are visible.
19
fig 26. Table contents are filtered in the maintenance view
Finally, let's test the OpenSQL Editor by writing a query that selects all records from table
ZFLIGHTS. As you can see, the OpenSQL Editor automatically uses the authorization
settings, so only LH records are displayed.
20
Column level authorizations
If you want to hide a specific field from a user, you can do so by adding authorization
object ZSQL_COL to the role. In this example we will only let the user see the country-
related information for the flights. Press the pencil icon to maintain the values for the
authorization object.
fig 28. List the fields that the user will see
As a resul we will see the table and allowed fields in PFCG with green icons:
Finally, let's test the OpenSQL Editor by writing a query that selects all records from table
ZFLIGHTS. As you can see, the OpenSQL Editor displays only the fields that are allowed
by the authorization setup.
21
fig 30. Assigning an authoirzation object to a table
Keep in mind that if you create a new role for the OpenSQL Editor, the ZSQL_COL
authorization object must be added. If you do not want to limit the columns displayed, add
a star chatacter to the table name and field name.
22
fig 31. Assigning an authoirzation object to a table
As he second step a field mapping between the authority object and the table must be
made that is used when filtering query results. This can be done by maintaining table
ZHTDB_AUTH_FIELD using SM30. Basically here we define that which field of the table
will be passed to which field of the authorization object. In this example the field names are
exactly the same.
Once this data is saved, the OpenSQL Editor will use V_VBAK_VKO to filter the contents
of VBAK. Now we assign this authorization object to our role using PFCG and restrict the
authorizations to Distribution Channel „C1'.
23
Once the settings are saved and the authorization profile is generated, the OpenSQL
Editor restricts the access of table VBAK to records with Distribution Channel 'C1'.
fig 34. OpenSQL Editor filters VBAK for Distribution Channel 'C1'
24
Further checks in the OpenSQL Editor
SAP standard Authorization Object S_DEVELOP (ABAP Workbench) is checked when the
SQL Editor is loaded, and the Loop-at Workbench is available or not depending on the
result of the check. It is also checked when the user want to access the table definition or
technical settings, or a data element.
SAP standard Authorization Object S_DATASET is checked when the user executes a
background job (the job writes the results into a file) and also checked when the user
reads the results from the file.
SAP standard Authorization Objects S_BTCH_ADM and S_BTCH_JOB are checked when
the user administers his own jobs.
The following is the list of all custom authorization checks in the program.
ZSQL_COL controls:
− if a certain field of a table can be displayed or edited
ZSQL_COMM controls:
− what kind of commands can a user create, change, execute, delete
− if the command properties can be edited or not
ZSQL_RES controls:
− if the result set of a query can be used to create and fill a new table
− if the result set of a query can be edited or not
ZSQL_MAIN controls:
− if a report can be generated based on a query (feature of Hovitaga Report
Generator)
ZSQL_CLSP controls:
− if the user can use the „CLIENT SPECIFIED” keyword in a command
25
Objects shipped
Authorization Objects
The Authorization Object Class ZSQL contains the following authorization objects.
For example, Update commands could be executed on Test clients, but not on Production
clients.
Basically this defines what a user can do with each kind of command, and in what kind of
client.
Authorization Fields:
Permitted activities:
01 Create or generate
02 Change
03 Display
06 Delete
16 Execute
Authorization Fields:
ACTVT Activity
CCCATEGORY Client control: Role of client (production, test…)
Permitted activities:
02 Change
40 Create in DB
26
Activity 02 is relevant for modifying and saving the Result Set of a select command.
Activity 40 is relevant for moving the records of the Result Set to a different table.
Authorization Fields:
ACTVT Activity
ZSQL_CTYPE Command Type
Permitted activities:
16 Execute
Authorization Fields:
ACTVT Activity
TABLE Table Name
ZSQL_COL Field Name
Permitted activities:
02 Change
03 Display
Authorization Fields:
ACTVT Activity
TABLE Table Name
ZSQL_COL Field Name
Permitted activities:
16 Execute
64 Generate
The aim of providing predefined roles is to ease the process of authorizing users for the
SQL Editor.
Note that both roles grant access to all SAP table groups. This might have to be adjusted,
as it allows to much freedom to the user.
Role ZSQL_USER
This role is a basic role for users with only read access to the SAP tables. Users with this
role can:
Role ZSQL_DEVELOPER
The developer role allows even more activities than the user role. Users with this role can:
- Do everything that is included in the ZSQL_USER role (note that this role still does not
grant the S_DEVELOP authority object for security reasons)
- Create, edit and execute Update statements in non-production systems
- Create, edit and execute Delete statements in non-production systems
− Import and export data to/from SAP tables
− Edit and insert new entries into the result set
28
Appendix – Links to SAP Help
29