Role building with (non) organizational values in SAP

All role administrators are familiar with the challenges that come with making a SAP role concept efficient and effective. Since organizations are always changing, the role concept must be easy to adjust to these changes as well. SAP has some features to help role building and maintenance like master – derived roles, single and composite roles.

Organizational elements can be used to restrict the functionality of a user to a specific organization.

Example use of organizational element: You have two plants in your organization, plant A and plant B. User1 needs access for goods receipt in plant A and create purchase orders in plant B. User2 needs access for goods receipt in plant B and create purchase orders in plant A. In this case you can define master roles for the two functionalities; goods receipt and create purchase orders. These two master roles can be derived for plant A and plant B. The derived roles have the same functionality as the master roles but are further restricted on the plant level; plant A or plant B. You will end up with 6 roles in total, two master roles and four derived roles.  These derived roles will be assigned to the users. User1 gets the role for goods receipt in plant A and create purchase order  in plant B while user2 gets the role for goods receipt in plant B and the role for create purchase orders in plant A.

Alternative you could have created these roles for plant A and plant B not via master- derived roles but manually. You would have four roles in total. But can you imagine the amount of work it will take if you have more than these two plants and these two roles to define?

Sometimes there are small differences in the roles when they are being used on different locations. For example different movement types are being used on different plant locations. When maintaining master – derived roles it is important that you maintain only the master role and do not make any changes into the derived roles directly, not only for consistency reasons. After changing the master (parent) role, the role changes will be inherited to the child roles automatically. Manual changes that where done in the child (derived) roles are gone when the master role changes are inherited to the derived ones.  

It is possible to promote authorization fields to organizational field (SAP note  323817 - PFCG_ORGFIELD_CREATE) . Almost all authorization fields can be promoted to become an organizational element. The two fields “activity” and “transaction code” cannot be promoted.

To solve issues when maintaining roles, promoting an authorization field to an organization fields seems to be a good solution, but you must be aware that promoting to an organization field is not always a good thing to do. Some authorization fields are used throughout the system and have different tasks here. If you promote the authorization field to organization field this leads to errors in the assignment of these authorizations.

Organization fields are not only useful for the master derived concept, using organizational elements in the role concept helps restricting access and preventing Segregation of Duty conflicts. During audits you should not only focus on the “what”, but also focus on the “where”. A combination of functionality might look like a segregation of duty conflict, but if the user is allowed to do the one thing in organization A and the other thing in organization B, the conflict is no longer there.

That is why we want to fully use the “Where” aspect in defining, building, maintaining and auditing SAP security concepts. 

CSI tools has unique features to use all advantages of the Where aspect. During role building and role maintenance the organization values and non-organizational values are used while deriving roles. Furthermore, besides deriving the single roles, CSI tools makes it possible to derive the composite roles as well. These features  makes it possible to create a role concept fully automatically: All authorization field values, like organizational values as company code AND non organizational values like a release strategy and movement types for example, are document in one central codification sheet. After the codification sheet is complete and contains all correct values, the single roles and composite roles can be derived fully automatically- talking about time saving!

It is even possible to fill this codification sheet via reverse engineering. In this case, the application takes the values that are already defined in the SAP roles and fills the codification sheet with these values.

Not only building and maintaining the roles are important, how about auditing and analyzing them? Make sure that the roles are set up correctly and do not lead to unwanted access. Analyzing the Where aspect is fully covered by CSI tools. During night jobs all roles are analyzed to verify for example if a Belgian role gives only access to Belgian data, if a display role does not accidently give a small update access, if a European role give access to all European countries and not more! Especially for multinationals that have vertical integration, display access to only one operating company is crucial, since this ensures the “competition” with the group.

All this is integrated in the solutions of CSI tools; CSI Role Build & Manage makes it possible.

(C)Meta Hoetjes www.csi-tools.com
The podcast of this blog can be found here: http://mhoetjes.podomatic.com/entry/2015-03-25T03_02_57-07_00