creation of custmized tcode for se16, sm30, se38 ?

[Former Member]

Hello,

Myself Naveen Dalal. Working as a sap security consultant and a new user for this furum. I have one question to u all sap security gurus:

Requirement is to create customized tcodes YSE16, YSM30 and YSE38 for se16, sm0 and se38. Lets start with YSE16.

1. Client want YSE16 tcode to restrict users based on some tables within a authorization group or even * value for auth group field.

SE16 restricted on:

S_TABU_DIS -

---

Auth Group and Activity

As per Requirement YSE16 tcode sld be restricted on :

Y_TABU_DI2 (customized object) -

---

Auth Group, Activity and Table name

We dont want to give SE16 to user. So basically requirement is to restrict users on table name with YSE16 irrespective on authorization group. User sld only be able to access the table mentioned in Table name field.

We have some program and we asked our ABAPers to modify accordingly but not succeed. Everytime it is going to check S_TABU_DIS to access any table and se16 as well.

Do u guys have some other solution. We want it for YSM30 and YSE38 as well. Thanks.

Regards,

Naveen Dalal

[Former Member]

Naveen

Issue ZS_ZSE16 (the program behind ZSE16) performs a call to the start

function within the program behind SE16. This program now has an

"additional-authority-check" for SE16 which was introduced in ECC6.0.

Solution: A new custom program ZS_ZSE16N with custom transaction ZSE16N.

This program does not call SE16 and finally users didnt recieved any error.

Additonal auth check was applied in the program for custom object

Z_TABU_DIS which applied checks on "Activity", "Auth Group of table" and

"Table Name".

Read Murray_Girl

http://sap.ittoolbox.com/groups/technical-functional/sap-security/using-custom-transaction-to-avoid-...

Thanks,

Sri

.

[mvoros]

Hi,

Get better ABAPers They just need to copy everything to remove all unwanted authorizations checks. It's obvious that just copying corresponding program is not enough. It calls some additional function modules which need to be modify as well.

I would try to avoid making Z copies of standard programs. It creates a mess and increases maintenance cost. If you are running on top Netweaver then you can try to use enhancement framework. I checked the code of SE16 and it calls FM rs_table_list_create after entering table name. So you can try to implement implicit enhancement point to add additional authorization at the beginning of this function module. Don't forget that this FM is called from other places. Also check if there is no other way how to get to selection screen.

Cheers

[Former Member]

Thanks Sri and Martin. Here is the Code of the customized program. Abaper did bit changes. They used YSE16 tcode name and Y_TABU_DI2 is the authority chk object like S_TABU_DIS in SE16. Can you please advice the necessary modification so that I can suggest to my ABAPER. I even doubtfull how many FMs they have created till now for this ..Problem is All tables are alligned with Auth Group and they are with S_TABU_DIS. So in our program we want to perforn it without checking S_TABU_DIS. But to check Y_TABU_DI2

REPORT zsec_se16_databrws NO STANDARD PAGE HEADING

LINE-SIZE 132

LINE-COUNT 65.

----

---

• Report : ZSEC_SE16_DATABRWS T-Code :ZSE16 *

• Author : *

• Title : Custom data Browser with Auth Check For Table name *

• This program will Allow the same functionality as SE16 *

• but provide additional authorization check functionality *

• to limit access based on table name. *

----

---

• Change History: *

----

---

• Author | Date | Request# | Description *

----

---

• | | | Initial Version *

----

---

************************************************************************

TABLES: tddat.

************************************************************************

• Selection Screen *

************************************************************************

PARAMETERS: p_tablen LIKE databrowse-tablename.

************************************************************************

• At slection screen *

************************************************************************

AT SELECTION-SCREEN.

• Check custome authorization object for table name

SELECT SINGLE * FROM tddat WHERE tabname = p_tablen.

IF sy-subrc <> 0 OR tddat-cclass = space.

tddat-cclass = '&NC&'. " 'non classified table'

ENDIF.

AUTHORITY-CHECK OBJECT 'Z_TABU_DIS'

ID 'DICBERCLS' FIELD tddat-cclass

ID 'ACTVT' DUMMY

ID 'TABLE' FIELD p_tablen.

IF sy-subrc IS INITIAL.

ELSE.

MESSAGE e419(mo).

• You are not authorized to display this table

ENDIF.

************************************************************************

• Start of selection *

************************************************************************

START-OF-SELECTION.

SELECT SINGLE * FROM tddat WHERE tabname = p_tablen.

IF sy-subrc <> 0 OR tddat-cclass = space.

tddat-cclass = '&NC&'. " 'non classified table'

ENDIF.

AUTHORITY-CHECK OBJECT 'Z_TABU_DIS'

ID 'DICBERCLS' FIELD tddat-cclass

ID 'ACTVT' DUMMY

ID 'TABLE' FIELD p_tablen.

IF sy-subrc IS INITIAL.

ELSE.

MESSAGE e419(mo).

• You are not authorized to display this table

ENDIF.

CALL FUNCTION 'RS_TABLE_LIST_CREATE'

EXPORTING

table_name = p_tablen.

Thanks Guys.

Regards,

Naveen

[Former Member]

Naveen,

If you are working in ECC6, then modify ZSe16N transaction prgram. It is not mandatory that you need to follow this method. You need to decide which method is good for company. Share your thoughts / idea, with client & ABAPers. Some thing will workout

In ECC5, you will not have any problem.

Thanks,

Sri

[Former Member]

> So in our program we want to perforn it without checking S_TABU_DIS

Not possible nor intended. The check is in the function module RS_TABLE_LIST_CREATE. You must grant the S_TABU_DIS and then restrict further using your Z_TABU_DIS - this is however only restricted to your YSE16 report as the entry point.

What you can do further is go to SE97 and maintain a "no check" indicator for YSE16 when the AUTHORITY_CHECK_TCODE function checks TCD = 'SE16' otherwise the user will bypass your Z_TABU_DIS object prior the rear.

Another option is to concatenate '/1BCDWB/DB' and the value of p_tablen to submit the dynpro of the selection screen for the table, then when the user hits "Execute" in it use SUBMIT /1BCDWB/DB<p_tablen> VIA SELECTION-SCREEN AND RETURN. It will work.

But at the end of the day you will revert back with the same because the authorization maintenance will break you and end up creating parameter transactions and controlling at S_TABU_DIS group levels, which is the intended and "best practice" approach.

The advantage of this is that you can define an authorization group name or convention of them and maintain it once in the authorizations - it is up to the developer to assign the new and changed tables to the existing and correct group if the existing and already authorized users.

Cheers,

Julius

Edited by: Julius Bussche on Jul 9, 2010 10:00 AM

[Former Member]

Just to add my 2 centimes:

there are 3rd party SE16-tools which come with a highly sophisticated authority check, one of them is called SE16-XXL Table Wizard. Usually these tools can be imported via STMS (transport requests) and the cost is minimal (less than what an qualified abapper bills for 2 hours work).

Just a thought

[Former Member]

Some things only show their true costs and skid marks further down the line...

In this case, take a carefull look on page 24 of [this article by the ABAP language development group|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f2dac69e-0e01-0010-e2b6-81c1e8e5ce50?quicklink=index&overridelayout=true] and the sentence about "extending the package concept to the runtime environment (to control access to repository objects)".

That is tables and package conform API's to them, like the BAPIs are to the Business Object Repository objects.

But there is no BAPI_TABLE_READ.....

There is also no BAPI_REPORT_RUN......

SAP's first attempts to introduce them many years ago are clearly marked as "uncertifiable interfaces which should not be used in the first place".

Cheers,

Julius

Edited by: Julius Bussche on Jul 9, 2010 1:34 PM

Sorry, hit "Post" by mistake too early. Added more venomous infos

[Former Member]

>

> Some things only show their true costs and skidmarks further down the line... 

yes, but that goes for custom development as well, doesn't it?

[Former Member]

Not if the custom development uses BAPIs...

Cheers,

Julius