Adding Authorization Group to ZTable Programmatically

[Former Member]

Dear Experts,

Does anyone know if there is a way to add an authorization group to a ZTable programmatically?  Is there already an SAP Function Module to do this or does someone have any custom code that would do this?

Thanks,

Bradley Sorensen

[tomas_talpa]

Hello Bradley,

I'm not sure what you mean by "add an authorization group to a ZTable programmatically"...

...do you want to check authorisations in custom code?

use abap statement AUTHORITY-CHECK;

...do you want to check authorisations in SM30?

define your own auth.group in table maintenance generator, and add this group to role for auth. object S_TABU_DIS "Table Maintenance (via standard tools such as SM30)";

...do you want to check authorisation in SE16N?

use auth.object  S_TABU_NAM "Table access with generic standard tools" (or defined auth.group for your table in SE11: menu "Utilities -> Assign Authorization Group", and use S_TABU_DIS);

...oh, maybe now I get it -- you want to assign authorisation group to table?

write custom code update table TDDAT "Maintenance Areas for Tables", or use maintenance view V_DDAT_54 "Authorization group assignment to table/view" to do it manually;

TomT

[Former Member]

Hi TomT,

Thanks for your reply.  Your last assumption is correct...I want to assign an authorization group to a table using code.  We have a situation where we got dinged by auditors because our custom tables (ztables) don't have any authorization groups assigned to them.  I don't want to have to go through and manually assign authorization groups to each one individually.  We have a broad authorization group we want to assign to all the ztables then we can manually change or add more authorization groups to ztables that require more security.  My problem is I don't know what all takes place (behind the scenes) when you manually add an authorization group to a table V_DDAT_54 "Authorization group assignment to table/view".  I don't want to write custom code that leaves something out.  I was wondering if someone already has custom code out there that will accomplish this or if there is a standard SAP Function Module that will do the trick?

Thanks,

Bradley Sorensen

[tomas_talpa]

as for "My problem is I don't know what all takes place (behind the scenes) when you manually add an authorization group to a tableV_DDAT_54"

-- well, Bradley, this one is easy, then;

-- simply try to add the auth.group in SE11, and then check the resulting transport content; you will see that there is only the view V_DDAT_54 capture in the transport  (record like R3TR VDAT V_DDAT_54)... there are no "behind the scenes" updates;

TomT

[matt]

Do you actually use table authorisation groups in your security concept? If not, then there's nothing need doing, surely?

[Former Member]

Hi TomT,

Thanks for your reply.

Thanks,

Bradley Sorensen

[Former Member]

Hi Matthew,

If you read above you will see that we aren't currently using authorization groups on ztables but we are going to start using authorization groups on ztables.

Thanks,

Bradley Sorensen

[matt]

You have only stated that you want to add authorisation groups to tables. My point is that the audit finding is only relevant if you have roles that include differentiation by authorisation group. I.e. if you don't have anything that checks authorisation groups and all users have access to all tables, then it'sa pretty pointless activity. The reason I make this point is that I've worked at a place where exactly this happened!

You might like to know that updating the authgroup directly in the table TDDAT has been live in one of my client's systems for over three years without any adverse effects.

[Former Member]

Hi Matthew,

Thanks for your reply.  We will have roles that reflect these authorization groups.  The overlapping authorization group will be display only I believe for all ztables.  Then we can customize form there.  It is nice to know that someone has done the same thing updating TDDAT directly and has not had any bad side effects.  Thanks again!

Thanks,

Bradley Sorensen