Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Using Authorisation Objects to restrict use of SWEQDEL & SWWL in PRD

Former Member
0 Kudos

Hi there

I need to know which authorisation Objects that are assigned to the 2 TxCdes I can use to restrict access in a Production environment.

SWWL - PLOG; S_CTS_ADMI; S_DATASET; S_DEVELOP; S_DOKU_AUT; S_GUI; S_OC_DOC; S_OC_ROLE; S_OC_SEND; S_PROGRAM; S_RFC; S_TCODE; S_TRANSLAT; S_TRANSPRT

Suggestion is that we use: S_OC_ROLE (SAPoffice: Office User Attribute) but have no idea what we should code or even if this is the correct Object to use; I suspect not.

SWEQDEL - S_ADMI_FCD; S_BTCH_ADM; S_BTCH_JOB; S_DATASET; S_DEVELOP; S_GUI; S_PROGRAM; S_PRO_AUTH; S_TCODE; S_WF_WI

Suggestion is that we use: S_WF_WI - this we have done but then needed to set ALL available options, this does seem to defeat the object of the excercise.

Any ideas will be gratefully accepted and paid for with thanks.

Carl Cavendish-Davies

SAP Development Manager

1 ACCEPTED SOLUTION

Former Member
0 Kudos

This looks like something patched together from SU24 (the capability of the transaction) and an ST01 trace (what turned up --> interpreted to be what is needed, which might not be true on complex authorization-check constructs).

> I need to know which authorisation Objects that are assigned to the 2 TxCdes I can use to restrict access in a Production environment.

What is it that you want to achieve in the Prod environment?

The choice of transaction is important, but this has an influence on the checks.

Cheers,

Julius

11 REPLIES 11

sdipanjan
Active Contributor
0 Kudos

Go to Tcode SU24 ... put your Tcode .. execute.... check which are the Authorization Objects available for Checking as well as Maintenance in Profile Generator. They will be available in PFCG (Authorization Tab) when you add them in the menu.... So you can use them to restrict (which is technically incorrect as Authorization concept is not to restrict access, rather to allow) the access to TCode.

Alternatively, you can check the proposals in the tables USOBT_C and USOBX_C

One more suggestion: Please try to attend SAP NetWeaver Security course for getting more concept on these..

Regards,

Dipanjan

Former Member
0 Kudos

This looks like something patched together from SU24 (the capability of the transaction) and an ST01 trace (what turned up --> interpreted to be what is needed, which might not be true on complex authorization-check constructs).

> I need to know which authorisation Objects that are assigned to the 2 TxCdes I can use to restrict access in a Production environment.

What is it that you want to achieve in the Prod environment?

The choice of transaction is important, but this has an influence on the checks.

Cheers,

Julius

Former Member
0 Kudos

I have used SU24 and identified all the relevant authorisation objects but cannot really find one that is appropriate for my use.

We are trying to restrict the usage of the other functions around these 2 TxCdes e.g. PLOG - Personnel Planning (need to restirct which Info Types can be seen).

Personally I do not actually see a need to restrict these; they are only in the Workflow Administration Role and this Role has only been given to 4 people. If there is a trust issue, well...... Our Governance & Security committee feels that there is a risk in the data that can be accessed not just from these TxCdes but after Double Clicking through into the Workflows and Workitems.

Here are the Auth Obj for SWEQDEL -

S_ADMI_FCD - System Authorizations

S_BTCH_ADM - Background Processing: Background Administrator

S_BTCH_JOB - Background Processing: Operations on Background Jobs

S_DATASET - Authorization for file access

S_DEVELOP - ABAP Workbench

S_GUI - Authorization for GUI activities

S_PROGRAM - ABAP: Program Flow Checks

S_PRO_AUTH - IMG: New authorizations for projects

S_TCODE - Transaction Code Check at Transaction

S_WF_WI - Workflow: Work Item Handling

Which one/many is/are sensitive and needs to be blocked?

Here are the Auth Obj for SWWL - PLOG-Personnel Planning;

S_CTS_ADMI - Administration Functions in Change and Transport System

S_DATASET - Authorization for file access

S_DEVELOP - ABAP Workbench

S_DOKU_AUT - SE61 Documentation Maintenance Authorization

S_GUI - Authorization for GUI activities

S_OC_DOC - SAPoffice: Authorization for an Activity with Documents

S_OC_ROLE - SAPoffice: Office User Attribute

S_OC_SEND Authorization Object for Sending

S_PROGRAM - ABAP: Program Flow Checks

S_RFC - Authorization Check for RFC Access

S_TCODE - Transaction Code Check at Transaction

S_TRANSLAT - Translation environment authorization object

S_TRANSPRT - Transport Organizer

same question Which one/many is/are sensitive and needs to be blocked

Regards

Car lCavendish-Davies

0 Kudos

You seem to have closed your question... I don't think that was your intention.

Those objects are all powerfull, but you have not mentioned with which field values you are granting them. That makes all the difference....

Sorted again in "approximate order of power":

S_DEVELOP - ABAP Workbench

S_RFC - Authorization Check for RFC Access

S_CTS_ADMI - Administration Functions in Change and Transport System

S_DATASET - Authorization for file access

S_TRANSPRT - Transport Organizer

S_PROGRAM - ABAP: Program Flow Checks

S_TCODE - Transaction Code Check at Transaction

S_DOKU_AUT - SE61 Documentation Maintenance Authorization

S_GUI - Authorization for GUI activities

S_OC_DOC - SAPoffice: Authorization for an Activity with Documents

S_OC_ROLE - SAPoffice: Office User Attribute

S_OC_SEND Authorization Object for Sending

S_TRANSLAT - Translation environment authorization object

S_OC_ROLE in particular has been used for many (also conflicting purposes). It seems to try to force you into granting this access, but then again it is too much at the same time.

In one implementation, I know that we solved this problem with a simple COMMIT WORK. before calling the SEND function and then it still went through.

I will try to look up the note again (you will find many notes on this object...).

Cheers,

Julius

Former Member
0 Kudos

I have tried some of the options suggested but am still unable to really restrict the TxCdes. Our Audit findings do not allow for us to have these TxCdes in our PRD environment without 'locking' them down.

Any other suggestions would be helpful.

Thanks

Carl Cevndish-Davies

0 Kudos

I noticed that SWEQDEL is a report type transaction and the report auth group is a WF_ADMIN. Additionally, in the initialization event, the system checks for authorization of the tcode again, also when it is called from SE38 or a program. Several other checks are made as well which are at a first glance not any type of end-user activities...

Perhaps if your users explain to you exactly what they want to do, then you can find a better transaction. This one is an administrator transaction with various related administrator checks involved.

If you need it to work only in a specific type of way, with specific values... then an option is to run it as a job and create a SYSTEM user for it. You can also logon as the SYSTEM user temporarily to create a protected variant for the report, and then let the admin only release the job when they need it, or have it run periodically.

Cheers,

Julius

0 Kudos

Julius

there are no 'users' that have these TxCdes; it is only my workflow Administrator. Our auditors are unhappy with the 'wide range' of access these TxCdes give us and thus we are looking for a way to restrict the access so that only certain parameters can be used. I do like your idea of setting up specific variants and then running as abackground job. This I will investigate. Any other ideas are most welcome.

Thanks.

Carl Cavendish-Davies

0 Kudos

Hi Carl,

It's not exactly answering your question but why exactly does your admin need this access a permanent basis. Generally SWWL is a "last resort" transaction. As an alternative mitigation why don't you look at providing this access on an "as needs" basis taking the firefighter/firecall approach?

This way you retain the ability to use the transactions as required yet it is granted via a controlled process that is linked to a specific problem.

0 Kudos

I was considering suggesting a standard transaction variant, but that does not help if the function codes are still executable and the checks do not differentiate between one button and the other.

I agree: An emergency user ID would be a better option, if there are any "routine" stuff which cannot be passed over to the background processing and at the same time are not "non-routine" ... otherwise every day will be an emergency day

Cheers,

Julius

0 Kudos

A variant could work, as you say it's dependent on what is going on in the background. A variant covering a few common scenario's could do the job and 75% of auditors would miss it as the transactions are renamed.....

0 Kudos

What I meant was a standard transaction variant - in which case the transaction code would not change. This would be more secure as all standard navigation pointing into the transaction would have the same restricted screen.

A SAP_ALL or S_TCODE = * user would have both, where the ZSWEQDEL would be the standard screen.

Anyway... the transaction calls AUTHORITY_CHECK_TCODE at initialization so the auditor could simply look in SE97 whether there are any entries.

> 75% of auditors would miss it

What you should also consider is that the user will be equiped with the authorizations, but cannot "see" some of the buttons. There might be other transactions, reports, etc which correctly check those same authorizations, but without the screen restraints.

I think consultants would miss 75% of them...

The advantage of the auditor is that he needs only to find 1, and then the whole things boils up again. That is why I agree with you that a "Super User" access procedure is a better approach. I regularly develop them for customers and they work like a charm, particularly to combat access to all the theoretical things which might happen on Sundays, special topics like this which the auditors are onto and want logged, things which you might want to have an additional release procedure for, etc.

Cheers,

Julius