Authorization role

[Former Member]

Hello experts

I'm building some roles, but I'm having difficulty restricting access by organizational level.

EX: I have roles with organizational level authorizations (one per organization) and I have other roles with tcode. The Tcodes share the same authorization, but must be released by different organizations.

role.jpg

How do I restrict access in transactions that use the same authorization and must be released in different organizations?

[Matt_Fraser]

Hi Sergio,

You'll note that I've changed the tag on your question, as it's not really about Basis Technology, but about Authorizations in ABAP systems, and thus the tag "NW ABAP User Administration and Authorization."

Best regards,
Matt Fraser
SAP Community Moderator

[awalkenhorst]

Hello Sergio,

your approach isn't very good. It causes a lot of issues.

Best solution is to create a parent role, ypu'll define all functionalty there (t codes, activities etc.). Don't maintain organization levels.

Copy that role link it to the parent role. You only need to add the organization levels in that role.

Copy the roles for each organization you need.

[Matt_Fraser]

So you've already split out the function into two types of roles, right? You have "transaction code" roles (per your example, there would be three of them), and you have "organizational level" roles (again, per your example, two of them). At one time, this sort of thing was considered best practice, by the way, though I believe the thinking on this concept has moved on in more recent days. Still, no reason it can't work.

If the issue is that adding tcodes to the menus in the tcode roles is adding additional authorizations, there's no reason you can't just deactivate those additional authorizations in the tcode roles, so that users will have to get them from the org level roles. Just make sure the S_TCODE object is only in the one type of role, and the org level objects in the other.

Then, create composite roles with the desired combinations of tcode roles and org level roles, design the menu structure in the composite roles, and add the users at this level.

I'm certain to get some authorization design experts howling at me for suggesting this, but it is an idea that can work (though it takes some ongoing maintenance), and as I said, there was a time when it was considered best practice.

So, in your example you have three tcode roles and two org roles, which leads to a possibility of up to six composite roles for each possible combination.

So that's the simpler way of thinking about it, and this would work for org levels based on things like cost center, plant, company code, etc.

If, on the other hand, you are thinking of HR/OM org levels, meaning organizational units representing departments and so forth, there is another way. In this case, you will want to look into creating structural profiles and evaluation paths, then assign those structural profiles at either the org unit or position level, as appropriate. This is common, for instance, in ESS and MSS scenarios, where departmental managers all need the same type of access to manage their employees, but they should only be able to manage their own employees, not those of other departments. Rather than creating a separate MSS role for each and every department, you create one MSS role and a single related structural profile. If this is the type of organizational separation you're looking for, on an HR/Org Mgmt level, then this is a different path to follow.

Cheers,
Matt