Scribd
Upload
1K views10 pages

Control Access To Tables in SM30 and SE16

Control access to specific records in tables accessed through SM30 and SE16 transactions by using the authorization object S_TABU_LIN. This allows restricting access at the record level based on key fields in the table. The document demonstrates how to define organization criteria and attributes for a sample table, then apply this in a user role to only allow access to records with a certain country code value.

Uploaded by

gaganchodhry
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
1K views10 pages

Control Access To Tables in SM30 and SE16

Control access to specific records in tables accessed through SM30 and SE16 transactions by using the authorization object S_TABU_LIN. This allows restricting access at the record level based on key fields in the table. The document demonstrates how to define organization criteria and attributes for a sample table, then apply this in a user role to only allow access to records with a certain country code value.

Uploaded by

gaganchodhry
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

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 tablename-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.

You might also like