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 isn’t 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, it’s 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.
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 you’ll 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 we’ll 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.
