topic Re: SAP-Authorization Revamp in Application Development and Automation Discussions

SAP-Authorization Revamp

Former Member — Tue, 20 Jan 2015 02:12:18 GMT

Hi,

There is a activity planned (in planning stage) for ECC PRD system Authorization revamp for all the users (approx. 950 users).

The activity planned is to streamline all the authorization a users is having from multiple roles into 1 single role.

So require details with respect to Org-Values, how we can extract these Org-values from multiple roles for the single user,

(e.g. as while creating a new role for a single user, who have 200+ roles, where Org-value may vary from role-to-role)

& other limitations if any with respect to limitation of Profiles can be assigned to a user, total objects in roles/profiles, single/derive role, GRC limits etc..

So please suggest the plan to extract the users/roles/t codes/Object_values.

Regards,

Shaik Maideen A

Re: SAP-Authorization Revamp

magexposito — Tue, 20 Jan 2015 08:29:56 GMT

Hello Shaik,

You can use table AGR_1251 to check the Org-Values for specific roles. You just have to write the role name (AGR_NAME) and the Org-Value object (FIELD) on the selection screen and you will get the Org-Values on the field 'LOW'.

Best regards.

Re: SAP-Authorization Revamp

Colleen — Tue, 20 Jan 2015 12:19:41 GMT

Hi Shaik

This is not a simple to determine. Yes it is technical to map user through to org value by tables:

AGR_USERS is user to roles but the user might have composite roles (could exclude them) based on the role type and confirm with AGR_AGRS table)
AGR_1252 - Org Values
AGR_1251 - Obtain the Org Fields where inheritance may be broken

The problem with joining these two tables is that organisational values depend entirely on the authorisation they are part of. Really the join is AGR_1251 to AGR_1252 to include that context.

What it means when you remove the authorisation is that you are getting all potential org values the user has but not how they are restricted. This means you might have situations such as:

Display all data roles - asterisk or all potential values entered in the role
Modify roles (posting/master data) - limit to specific org values
Potentially broken inheritance (you'll need the AGR_1251 table for that)
Modify roles that are not restricted on a specific org value that other roles would

And I'm sure I haven't covered all the scenarios. But what will happen is they will all be merged together and you'll lose the context in your analysis of how much access to the org data the user truly has.

The examples I list are potential situations if you mention the need to rebuild security. If you are at the stage of performing a massive clean up and rationalising design then there is a good chance you will have other technical issues in the build the further skews your analysis.

If you had managed to use a role convention and build and provisioning rules to limit users to certain areas of the business, then you might be able to rely on this analysis to an extent.

Regards

Colleen