How to test table access security?

[Former Member]

Folks,

I need to test a third party FM that accesses arbitrary SAP tables. The documentation from the vendor says that they honor SAP table level security, that is, the FM will throw an error if the user tries to access a table through the FM that he or she does not have permission to.

My SAP user account has all the privileges. Therefore, I am able to get to any SAP table without any error.

I need your help in creating another user account and give them limited permission.

What security role can I assign to this user that has limited access to SAP tables? Is there a specific SAP table I can use to test if the user is indeed denied access to this table?

Thank you in advance for your help.

Regards,

Peter

[Former Member]

Take a look in SU21 at the object documentation of S_TABU_DIS, and search for discussions here about it. See also S_TABU_CLI, S_TABU_LIN and S_TABU_RFC.

You can also just look in the function module to find your search terms in there, if found...

Cheers,

Julius

Edited by: Julius Bussche on May 4, 2009 10:26 AM

[Former Member]

Hi,

Just to add !!!

You can activate table logging and monitor the changes made to the table from the transaction se13 and view the same in scu3.

Restriction logic is maintained from the auth objects S_TABU_DIS , S_TABU_CLI , S_TABU_LIN .

Rakesh

[Former Member]

Peter,

For your third party tool can you specify which table to read? If so you can create a new role with just access to S_TABU_DIS for that particular table auth group and see if it works and then remove the access for this table and see if it fails.

Also switch ON the security authroization trace in ST01 and check for the authorizations being used by this new FM.

Thanks

Khan

[Former Member]

Hi Khan and others,

Thank you for your help.

The FM allows us to access any table.

As you suggested, I can create a new role and allow access only to S_TABU_DIS. However, when I create a new user, don't I have to add other "standard" user roles? This would mean that the user would automatically get access to many other tables.

For testing purpose, how can I ensure that table "MARA" cannot be accessed by a specific user?

Appreciate your help.

Regards,

Peter

[Former Member]

> However, when I create a new user, don't I have to add other "standard" user roles? This would mean that the user would automatically get access to many other tables.

That is a clear design error. Some implementations take this short-cut by creating a "display all except HR and Basis" role for all users and expect S_TCODE to prevent the user from starting the functionality which they would otherwise be unhindered in using - but it comes back to bite you... because S_TCODE is not the only entry point to the functionality which consistently uses the authorization concept.

Some of them (such as RFC - most likely your 3rd party tool is using RFC_READ_TABLE...) are explicitly prohibited from checking any S_TCODE authority for a good reason...

My recommendation would be to re-think the design of your authorization concept...

Alternately, create yet another work-around by checking a non-SAP permission in the 3rd party tool or custom object in the 3rd party interface within the ABAP system.

Imagine if everyone used "alternate" concepts in the same implementation...

Cheers,

Julius

[Former Member]

Hi,

I agree with Julius comments. Also, mara table is available in security group MA. Check the security groups of each table as below.

Open SM30 --> Enter v_ddat_54 --> Click on display --> Now click on position and enter table name

Now the table's top entry shows you the authorization/security group for corresponding table. You need to provide this value for object S_TABU_DIS with activity 03, and other field with MA.

Regards,

Gowrinadh C

[Former Member]

My guess is that the table name is exposed to the interface of the RFC, and logical databases are not popular amongst developers who think that they know what they are doing (and expect it to be release independent).

The best option is always a BAPI (or BAPI compliant FM) to achieve the same consistent behaviour^, and let SAP take care of the coding on the inside.

If the business application interface program is legitimate, SAP should provide a BAPI for it to be called by their own programs, 3rd party vendors, and anyone else who accesses the network.

They will experience the same checks, and not make mistakes with single fields of tables....

</ideal_world>

Julius

[Former Member]

Thank you all for your help.

The third party FM does not use RFC_READ_TABLE but actually is a replacement for it. I have been asked to test and see if this function honors security just the same way RFC_READ_TABLE does. I am using a development SAP system to do my tests.

The FM comes with a Windows client program that lets us specify the table name and columns for which we need to extract the data.

I hope I have given a better picture of what I am trying to do. Given this background, I would appreciate it if you can suggest the best way to test this FM.

Thank you once again for your help.

Regards,

Peter

[Former Member]

First, you need to decide whether or not you want to have users accessing tables directly at all.

Once you start with this, or queries, or SE16, etc... then you will have a a tough time getting them weened of it and they will always want more and more tables - representing a far greater magnitude of tables and risks as they are grouped via the authorization grouping concept of S_TABU_DIS.

Checking the FM is a matter of a code review. You could post the code here for us to take a look at, but the vendor might not be so happy about that....

For a start, you might want to take a look at what Wolfgang Janzen spotted in the code of this thread:

but there are many more things you can check in the code if you want to do a security review of it.

Cheers,

Julius

[Former Member]

Bearing in mind the other comments that you have received, I would test this with the bare minimum of authorisations to start with and then see what happens!

For instance, since you are in the development system, perhaps create a new role with S_TABU_DIS without any authorisation groups assigned and then see if you can successfully access the table data. If you are specifically concerned with the MARA table, since it is part of the MA auth group, you should not have access to it and hence the error message should appear.

Be aware that lots of SAP tables do not automatically have auth groups assigned or have the dummy one &NC& which does not require specific authorisation values.

Always try with the minimum authorisations as it is much easier to add than to retrospectively remove.

Simon

[Former Member]

Thank you all for your help. We ended up purchasing the code. Just to recall, this code is a replacement for RFC_READ_TABLE.

Like RFC_READ_TABLE, this function calls VIEW_AUTHORITY_CHECK. VIEW_AUTHORITY_CHECK ends up checking for authorization against object S_TABU_DIS.

While S_TABU_DIS seems to be everyone's favorite here, as I understand S_TABU_DIS checks the authority against "table class" and not "table." A table class can have 1000s of tables in it. To give a user access to one table, the admin has to give access to its class. Essentially, now the user has access to 1000s of tables.

Isn't using a table class for authorization frowned upon by Basis Admins?

Is there a better way?

Regards,

Peter

[Former Member]

> Isn't using a table class for authorization frowned upon by Basis Admins?

It is common to classify data, and according to their classification you can associate a risk to it and level of protection, including ownership of the data.

For this reason and ease of administration, tables can be grouped into authorization "classes".

Tables which are not classified, and therefore not intended to be accessed directly, are given a symbolic table class called '&NC&' => "Not Classified".

Whether or not you are going to let users query tables directly in your transactional system is a decision you need to make early on and live with the consequences (e.g. using the wrong table..) and all the audits, because it will be hard to get rid of it again later on down the line.

Cheers,

Julius

[Former Member]

Hello Julius,

Thank you for your help.

Can multiple authorization classes point to the same table? I am thinking we can propose our customers to create a custom authorization class and add all the required tables to this class. For example, MARA is a table that the users need access to.

Appreciate your help.

Regards,

Peter

[Former Member]

Hi,

No. One table can be assigned to one Authorization group (or class). MARA table usually can be found in the group MA. Check the above posts to find the authorizaiton groups of tables.

Regards,

Gowrinadh

[Former Member]

I was sure that I had posted a response to this earlier on about the difference between the authorization group of the view to the table(s) and the table itself, but it seems to be gone.

Oh well, if you are happy then that counts most

Cheers,

Julius

[Former Member]

Thank you all for your help. Points have been awarded.

Regards,

Peter