assign table to multiple authorization groups

[Former Member]

Hi,

I would like to restrict user access to certain standard tables. these Tables are already assgined to authorization groups.

eg all PA-tables are assigned to group PA. However I want restrict access only to a subset of all PA-tables.

Can I assign the tables of this subset to another authorization group, which I create myself, so a table is then assigned to two authorization groups eg

PA0001 => PA and

PA0001 => MyGr

Is there another way to restrict access to tables on finer granularity level then predefined groups

Thanks

Torsten

[Former Member]

Hi,

There is no way to assign a table to more than 1 auth group.

One thought is that you could define a custom auth group schema e.g. for example that allows you to set up a higher level auth e.g. ZPAx where ZPA reflects the general area and the x can be used for subsets underneath that. You can assign ZPA* to people with the wider access and more granular as needed.

[Former Member]

First of all, right upfront, I would question why the user is needing to display such an application data table directly.

> Can I assign the tables of this subset to another authorization group

That is exactly what the application reporting tools do, in this case via FM HR_READ_INFOTYPE and nothing to do with tables so direct access from SE16 etc is not a "backdoor" either.

There is an option to use the "line by line" org. check in the data browsers and views (see SU21 object S_TABU_LIN documentation) but that is not table or infotype specific.

If you cannot eliminate the requirement... then I would suggest isolating the tables which you do want to view and consider changing their auth group in SE54. For this you should create a view and give the user access to a parameter transaction calling the view, and you can add more authority-checks to the view as well - but you cannot disable checks. This will be your restraint, as I assume you wanted to grant an authority for a second sub-authorization which "overrides" the previous one.

It does not work that way.

What you can do is bypass checks using open SQL execution, but that is not a good solution either really. You loose the traceability to your code, and anyone else who runs it generically will bypass your table and the HR checks as well.

Looking back, you will have achieved the same level of security by using parameter transactions and trying to prevent generic ones (SE16, SM31, etc).

I would suggest rather not using S_TABU_DIS for anything other than current settings in production, for customizing in development where there is no "real" application data" and selected views in all, and transfer the rest to "reporting".

That way you do not have a conflict, and there (in reporting options) you will find the granular checks, against multiple objects and many field combinations, which you are looking for.

Cheers,

Julius

[Former Member]

Hi,

I had a similar kind of requirement to change few HR tables. The queries in SQ01 which were developed long ago has been using few HR tables to pull users/their managers from organizational management and etc. Especially infotype 1001. I have moved the required HR tables to different authorization group (suggested in above posts as well) and now provided access to end users who uses those queries to the custom authorization group.

Now the HR sensitive access is protected from normal users has been assigned to required ones i.e. HR staff.

Regards,

Gowrinadh