Control access to tables in SM30 and SE16(N) on line level

Home

Security

SAP Consulting

How-to Guides

Control access to tables in SM30 and SE16(N) on line level

Access to the transactions SM30, SE16 and SE16N is often regarded as a security risk on any

productive system.

But with the right use of the authorization object S_TABU_DIS and the rarely used objects

S_TABU_NAM and S_TABU_LIN, this isnt the case.

With S_TABU_DIS you have the option to control access to groups of tables, and you have the

option to distinguish between Update and Display access. If you do not want to give access to an

entire table group, its quite easy in transaction SE54 to create a new authorization group and to

reassign one or more tables/view to this group, thus achieving control of access to these specific

tables. S_TABU_NAM can be used to control access to a database table (or a view) on a table-

name-level.

If youre anxious about giving access to an entire table group due to the fact that some tables have

an open interface which allows table maintenance even in transaction SE16, then check out

this report developed and posted to the SAP Fans security forum by John A. Jarboe.

With the authorization object S_TABU_LIN, you can even go a step further, and control access to a

table on record level, based on the key fields of the table. You can find an overall presentation of the

object here.

This How-To guide below will demonstrate how to set up and use this authorization object.

The example is based on a small table ZMYTABLE. I have created a maintenance view and

parameter transaction based on SM30 around this table.

Please notice that the parameter transaction is calling SM30 in update mode.

If the object is to be used with SE16 youll need to implement OSS note 76326

S_TABU_LIN Customizing

We can find the customizing entries in the IMG under SAP NetWeaver -> Application Server ->

System Administration -> Users and Administration -> Line-oriented Authorizations.

First, we need to define the Organization Criteria.

Next, we will create new criteria by pressing the New entries button.

In the above example, we will like to control access based on the key field Country. In order to do

so, create an organization criteria called Z_Country_Grp, with Country Grp as the organization

name. If we flag the table-ind, the criteria will affect maintenance of all tables whose key fields are

related to the domains specified in the attribute later on.

In this example, what we want is to control the access to the specific table ZMYTABLE so we will

leave it blank for now.

Next, Save the entry and assign it to a transport request.

Then mark the created line and switch to attributes.

Proceed to create a new entry with the data illustrated below.

Save it and assign it to the transport request. Notice that you can have up to 8 organization criteria

attributes.

What we need now is to assign a table and a field to our attribute. In order to do that, simply mark

the attribute and switch to Table Fields

The next screenshot shows where you can create a new entry and assign a table or a view to the

created attribute. For instance, in this example, the table ZMYTABLE, and the field name Country

has been assigned to the attribute COUNTRY GROUP.

Please note that only Key Fields can be used!

Save and assign to transport request.

At this juncture, we are ready to activate our organization criteria this is the second box in the IMG.

Just click (check) the active flag and the check will be activated.

Incorporate the Authorization Object in a Role

We have now implemented the authorization check; next step is to implement it in the required roles.

In this example, I have created a parameter transaction ZMYTRANSACTION using SM30

around the table ZMYTABLE. I have also created a small test role ICC_TEST including only the

transaction ZMYTRANSACTION, and a few support transactions.

In the authorization part I have inserted the object S_TABU_LIN manually (best practice is of

course to assign it in SU24), but a manual insert will also do the trick.

Now, when we change one of the authorization fields by clicking the pencil-like symbol, the profile

generator will ask us for the criteria.

We can go ahead and choose the Z_COUNTRY_GRP criteria that we created.

The following popup then appears. In this case, we will grant change access, so we choose 02

Change for activity.

In the list below well see the Organizational Attributes that we have created we have the option to

use up to 8 attributes. In the previous example we only defined one attribute Country Grp which

we will assign the value DK thus only granting access to records with DK in the key field Country.

To transfer the selection back to the profile generator press the transfer button or simply hit F5.

What we need now is to generate the profile and assign it to a test user.

When this test user signs in and executes the transaction, only entries for Cty DK are displayed.

If the transaction is executed by a user with SAP_ALL, all records will be displayed. See figure

below.