Allow users to access Z* tables and restrict access SAP Standard tables

[Former Member]

Hello,

i have a task in hand,i want to allow users to access Z* i.e company customized tables but at the same time i wanted them to restrict access to SAP Standard tables.I have heard of creating authorization Groups and assigning them but i do not know how to proceed.

can someone please help me out on this issue.

Regards

Dattaprasad

[blanca_serrano]

Hello,

If you want protect a table or if you want assign the authorization for a specific table to an user then you should allocate a new or existing authorization group to the table. This can be done in TC SE54.

I hope this helps you.

Regards,

Blanca

[Former Member]

Hello,

actually there are many may be 50 or 100 tables starting from alphabet Z.so i want to give access to all z tables.There is no authorization group existing as of now.

[Former Member]

Hello,

This is a task that involves DEV team and Basis team. The theorical idea to deal with this is:

1) DEV team assigns to the table Z1 the autorization group ZG

2) DEV team creates a new transaction Z_VIEW_Z1 as a view of the table Z1. This avoid the use of SE16.

3) According to the bussiness requeriments the transaction Z_VIEW_Z1 should be included in one or more roles.

note in this case you can have two roles for example:

Z_role1: Allows access to tx Z_VIEW_Z1 but for display only

Z_role2: Allows access to tx Z_VIEW_Z1 for display and change

4) Basis team should work with the object S_TABU_DIS, fields ACTV= (02,03 or both) and fixed DICBERCLS =ZG to perform the activities described in 3).

Remember that if you haven´t assigned a table a group, this table has the default group &NC&. have a look at TBRG and TDDAT tables.

I do not recomend assign all tables the same group ZG. You should define groups accordingly. But this depends on the bussiness requeriments.

Hard Work, Good Luck!

Diego.

[OttoGold]

Hi,

I can recommend what other have said already, especially Diego`s answer is very nice. Not a copy paste one and providing big picture to help you start. Nevertheless you might need some more details or a "push", so that`s why I jump in.

DEV team assigns to the table Z1 the autorization group ZG

You have to decide if you want to go for S_TABU_DIS or S_TABU_NAM. Check your release, I am not sure since when S_TABU_NAM is supported but I have that feeeling that it is kind of new. If you go for NAM, then you don`t have to go through the tables and assign them the groups. If you want to assign groups, please put some thought into it before you star, because ZG = one group = is not very good idea. It`s like &NC& ... almost...

2) DEV team creates a new transaction Z_VIEW_Z1 as a view of the table Z1. This avoid the use of SE16.

If you have people who can run SE16 anywhere else than in development/ sandbox system, you should start working on that right now. That is not the right way. Except securing the data access you must also educate your users and PREVENT them from CORRUPTING the database!!

2) DEV team creates a new transaction Z_VIEW_Z1 as a view of the table Z1. This avoid the use of SE16.
3) According to the bussiness requeriments the transaction Z_VIEW_Z1 should be included in one or more roles.
note in this case you can have two roles for example:

That also means that you can mainatin SU24 proposals for the transactions so you don`t have to run the whole things manually and can make PFCG to do most of the work for you.

Cheers Otto

[martin_voros]

Yep, S_TABU_NAM is new. Check note 1481950. Also interesting note is 1500054.

Cheers

[Former Member]

Gold,

Thanks for your comments. I just want to point out something that I've forgotten. If you have a good group definition it allows you to do checks in your Z programs like this:

AUTHORITY-CHECK OBJECT u2018S_TABU_DISu2019

ID u2018DICBERCLS u2019 FIELD u2018ZGu2019

ID u2018ACTVTu2019 FIELD u201802u2019.

Cheers,

Diego.

[Former Member]

Thanks Diego ,Martin ,Gold i will contact the dev team and do the following tasks..

Thanks everyone for your help.

[Former Member]

Sorry, but hardcoding a configurable auth group value is a bad design.

You should call function module VIEW_AUTHORITY_CHECK which will resolve the group assigned to the table or view, and if sy-subrc 0 then it will check S_TABU_NAM ...

*then it will check S_TABU_NAM* !

Cheers,

Julius

[Former Member]

Julius,

Probably you're right. I just I've learned this way from SAP standard codes. This is a random note:

0001479762 - Missing authority check in SAP_RSADMIN_MAINTAIN

This is the change that SAP made to source code:

Insert Block

• authority check S_TABU_DIS

AUTHORITY-CHECK OBJECT 'S_TABU_DIS'

ID 'ACTVT' FIELD '02'

ID 'DICBERCLS' FIELD '&NC&'.

IF sy-subrc NE 0. "no authority

message e417(MO) raising no_permission.

ENDIF.

Maybe I`m not getting your idea, are you proposing something like this?:

(I´m not an abaper, so I'll just write an algorithm)

group = get_table_group (z_table)

Authority_check (group,read/write)

Regards,

Diego.

[Former Member]

Hi Diego,

Probably you're right.

If I am wrong then I will eat my hat.

I just I've learned this way from SAP standard codes. This is a random note:
> 0001479762  -  Missing authority check in SAP_RSADMIN_MAINTAIN
>
> This is the change that SAP made to source code:
> 
> Insert Block
> * authority check S_TABU_DIS
>   AUTHORITY-CHECK OBJECT 'S_TABU_DIS'
>                   ID 'ACTVT'      FIELD '02'
>                   ID 'DICBERCLS'  FIELD '&NC&'.
>   IF sy-subrc NE 0.                    "no authority
>     message e417(MO) raising no_permission.
>   ENDIF.

No. That was in the incorrect source delivered with the first version of the note. The second version (report by me ironically) is the correct one and if you look at the source it is now:

* authority check S_TABU_DIS
CALL FUNCTION 'VIEW_AUTHORITY_CHECK'
  EXPORTING
    view_name                            = 'RSADMIN'
    NO_WARNING_FOR_CLIENTINDEP           = 'X'
  EXCEPTIONS
    OTHERS                               = 1.

**** sy-subrc <> 0 raise no authority
  IF sy-subrc NE 0.                    "no authority
    message e417(MO) raising no_permission.
  ENDIF.

Maybe I`m not getting your idea, are you proposing something like this?:
 (I´m not an abaper, so I'll just write an algorithm)

You made the same mistake which the SAP developer did in the note. You could work for SAP actually...

(just joking)

Cheers,

Julius

[martin_voros]

Maybe SAP shoul add additional check with warning to extended check of code. Something like "Direct use of S_TABU_DIS. Use FM instead". There would be escape sequence for special cases to hide this warning. I know that it's not going to help with bad developers because they do not give a ****. But it would be nice.

Cheers

[Former Member]

The trick IMO is to get the folks off SAP_ALL...

That way they have to build a role and start thinking about how to code (or as in this case call) appropriate AUTHORITY-CHECKs which are re-usable and adapt themselves with the concepts and the config changing.

Some folks dont read the manuals. Others do (as in this case) but dont "get it" at first. It is not always easy and S_TABU_NAM is new - so it draws attention to the use of modularization of checks.

SAP themselves have about 200 "hardcoded" S_TABU_DIS checks (if you include the use of the object as a constant or variable) which S_TABU_NAM triggered the correction of.

There are about 5000 parameter transactions for the data browsers and maitenance tcodes (SE16, SM30 etc) which do not propose a group or propose an incorrect group in SU24, although the group would in most cases be easy to determine.

If it is missing or '&NC&' then the concept is missing... !

But they didnt' read the manual either or only people with SAP_ALL equivalent use these transactions it seems...

If there are so many "bad developers" regarding table access, then I think the concept is the problem, along with insufficient and / or buggy reporting in the application of the tables.

Try retro-fit '&NC&' after it is "out there" for the users for a while. I do not believe that this is possible nor feasable.

S_TABU_NAM solves this immediate problem via FM VIEW_AUTHORITY_CHECK. Also for the isolation of direct table access when the rest of the implemented concept sucks or the business requirements were too strong.

In future I can see all the users using webservices which are easier to use for them and more abstracted than SE16. Their user IDs will be "in memory" only and their authorizations with be message level SAML assertions. SU02 will be gone. PFCG will be a modelling tool for menus, org-levels (though these will be largely eliminated) and groupings of personalizations on the frontend.

Only bad code and grumpy basis admins using server clients will remain....

That is my rant for the week as well. Enjoy the weekend,

Julius

[martin_voros]

> In future I can see all the users using webservices which are easier to use for them and more abstracted than SE16. Their user IDs will be "in memory" only and their authorizations with be message level SAML assertions. SU02 will be gone. PFCG will be a modelling tool for menus, org-levels (though these will be largely eliminated) and groupings of personalizations on the frontend.

There is a famous and really good Aussie movie The Castle with very famous quote "Tell him he's dreaming". So I am telling you are dreaming

Cheers

[martin_voros]

Hi,

You should assign auth. groups to your bespoke table and use S_TABU_DIS. As a temporary solution S_TABU_NAM ca gel you solve your problem.

Cheers

[Former Member]

Hi

Create new auth. grp in se54 and include all the required tables .save th auth grp.create a new role.in field decbrls in auth object s_tabu_dis include the created auth grp .assign the new role to the users .hope it will help u.

Thank you

[Former Member]

Hello Dattaprasad,

Apart from the above posts, have a look at my post which might helpful for you.

Workout the scenario in Development box with sample authorization groups along with user assignment. We can restrict at all levels of levels with authorization groups.

Good Luck

Rgds,

Durga.

[Former Member]

Hi Durga,

For creating the Authorization Group i first went to transaction

se54-> Authorization Group->Create/Change->New Entries->Enter AuGr and Details-

Now since i want all the SAP standard tables to be inserted as values where and how should i proceed.