Getting the correct Authorizations without endless SU53 screens

[Archie-Hammer]

Hello Security experts,

I am a developer and I am a bit displeased with the cycle I seems to run into whenever I request a new t-code being added to a role.

1. I request a t-code be added to a role.

2. I test the t-code and run su53.

3. Basis adds missing authorizations

4. Repeat steps 2 & 3 until complete

My problems with this approach:

• SU53 doesn't always tell the basis team the correct authorizations.
• If the program has done authorization checks to make decisions nothing will show in SU53 and the program will not execute correctly and I am then left to go searching through code to find with authorization checks are there and what is being checked.
• The ownership feels to be on my shoulders to identify everything for Basis rather than basis knowing the correct authorizations to assign (though could just be my area).
• I am expected to test every possible area and function of the t-code with the hopes that all the missing authorizations have been identified.

I am told this is the best practice so the user is only getting the "exact" authorizations needed, no more, no less.

I can appreciate the need to get correct authorizations but I wish there was a less time consuming way (for me and my basis team).

If this has been addressed already I would love to see what the solution is. Otherwise I would love ideas I would be able to present to my basis team.

[mvoros]

Hi,

for the standard transaction SU24 gives you a good overview of objects that are checked in transaction. To speed up the process you can activate auth. trace ST01 and run transaction with a user that has broad authorizations. You need to run all common use cases of this transaction to capture all checks. This can be really tricky for more complex transactions. This gives you a list of all executed authorization checks. There is no silver bullet for figuring out what authorization checks are performed. Especially, in complex scenarios such as posting goods movement you have these edge cases.

Cheers

[Colleen]

Martin's captured the two key approaches

Alternatively, read or debug code - easier if simple program. You can search for words like AUTH, DATASET, etc to pic up most checks

The drawback with testing with broad authorization - depending on how code is written and IF statement in the syntax may use an authority check to route the user down one path whilst other checks will send them a different direction. E.g display vs change access

Security is massive in SAP land now. It's why a lot of client sites have dedicated security team/admin performing the activity instead of Basis. By using a dedicated team they become familiar with the functionality and have a better educated guess of build requirements. I realize this won't change the predicament you are in. My point though - familiarity speeds up the process.

[Former Member]

This drove us up the wall as well to memorize +100k transactions, +4000 application objects, etc even if they are the specialist, so we built some reporting around it to show what is missing, what is too much and what is a decision-point in the process which the security admin should not need to take on their own.

We could not see any other way for mortals to survive at least for a few upgrades..  🙂

Cheers,

Julius

[Former Member]

Hello

I'm just trying to imagine the bad flow of events in creating a custom transaction and its program

How would it work?

1a. Business process owner identifies as series of time-consuming events within SAP which they ask to be simplified - not sure if this is valid but a stab in the dark.

1b. Maybe there's a problem with the process and the business can't handle the steps with existing SAP delivered transactions?

2. The request may be raised as a change request- whatever the process it proceeds...

3. A functional (by module?) person is given a task to define the steps needed in SAP to produce an A to Z result. It may be a segregation of duty nightmare!

4. A fag packet spec task is created for the developer who reviews the steps to find the best fit. How this works is beyond me - well done developers

5. The custom transaction is created (based on a standard edit - design standard - ZMM_, ZPM_ etc edit) and the program is assigned

6. The functional people try the new custom transaction in DEV/QA/Sandbox using their own user ID and decide the functionality is fine after some/several tweeks to the fag packet

7. The program and new transaction is moved to QA/PRD (worst case) and the business process owners says the business can't run the new custom transaction

8. Everybody points to security to get the access assigned in PRD

9. Now the fun for the developer or the functional people?

10. Security find  role to add the transaction to, do a quick check in SU24 and find nothing, do a quick check for 'authori' via SE93 drill down on the program, try running the transaction in DEV/QA in the hope of catching an authorisation check...they gently ask for at least one authority check - preferably something meaningful and related which the developer does with the knowledge of the program and experience!

Now - just how much access should each user have to the new transaction? All of it - i.e. all found auth checks, all traced auth checks with 04/08 returned fixed, no auth checks until the functional people decide?

Does the business need 1 role with one set of SU24 default values, two roles with a default SU24 and a copied/maintained object giving slightly more access/SU24 not maintained in this business anyway?

I can't see the developer being constantly told to keep testing the new program/transaction or defining which role it should be added to? Should it not be the functional people with the business deciding on the access with the security people?

Just wondered - sorry I didn't give an answer 😞

Cheers

David

[Former Member]

Here is the magic blackbox: developer is clairvoyant and sees the trouble coming, so she creates the z-application in such a way that it re-uses the semanticly correct objects for the business process step it is meant to simplify. Then (here comes the first trick) she tells the authorizations guru that the new tcode for it belongs in the menu of single job role XYZ which already contains those semantic objects but maintains SU24 anyway so that the where-used-lists are complete and other future roles dont need to SU53 the blasted thing again either. If the developer also understands the design aspects of roles, then you can also automate several parts of the process, create worklists automatically, etc.

Works like a charm - all you need is a talented developer who knows more than "SAP_ALL works"...  😉

Cheers,

Julius

[mvoros]

Hi David,

it's not that hard to maintain default checks for custom transactions. Generally, you can break development of custom transactions into two big groups: development from scratch and re-using standard SAP functionality. In the first case the developers build everything. So they are in the best position to define a reasonable authorization checks based on business requirements. To be honest, usually it's all or nothing. So a user with access to a transaction can do everything provided by that transaction. Sometimes it gets complicated and you need to incorporate org. level fields. By re-using standard SAP functionality I mean that you want to provide a simplified version of standard SAP transaction. E.g. you want to provide a web application to users. It allows them to post goods receipt with simple click (the screen is simplified for this scenario). So in this case you just need to map it back to standard transaction and use defaults from there.

Cheers