ICS for business processes in SAP systems
Maintain permission values using trace evaluations
An alternative to using the S_TABU_LIN authorization object is to create custom table views that make organisational delimitation easier to achieve. To do this, create a new view in the SE11 transaction and add the table to which the constraint will apply on the Tables/Join Conditions tab. The Selection Conditions tab allows you to specify your restrictive organisational condition in the form of a field and a field value. You then authorise all relevant users to access the view, which contains only data for your organisational restriction.
The first line defines that access to all files is forbidden unless other settings have been made for them in the other lines. The asterisk (*) is in the first place here and in this case for all files and paths. If the asterisk is in a different position, it is interpreted as part of the file name, which is not allowed in Microsoft Windows, for example. In our example table, setting the switches FS_NOREAD = X and FS_NOWRITE = X for all paths prohibits reading and writing. This makes the table a white list. This is preferable to a black list for security reasons. SPTH, on the other hand, becomes a Black List if you remove the first line with PATH = * in our example or if you do not set any of the switches FS_NOREAD, FS_NOWRITE or FS_BRGRU. The second line with PATH = /tmp allows read and write access for all files starting with /tmp, similar to a permission value /tmp*, as an exception to the access ban defined in the first line for all files and paths. This setting is not limited to subdirectories, but includes, for example, all files whose name starts with /tmp-xy. The third line with PATH = /tmp/myfiles defines a permission group with FS_BRGRU = FILE, triggering the subsequent permission check on the S_PATH object. The SAVEFLAG = X switch defines that these files will be included in a backup procedure; however, this is not relevant for the permission award.
Use SU22 and SU24 transactions correctly
Then you create a subroutine with the same name as the User-Exit definition and programme your customised checks (for example, for specific data constellations or permissions). Include the exit definition (UGALI) via the GGB0 transaction. You will need to call this transaction again to read the programmed exit and select it.
The high manual maintenance effort of derived roles during organisational changes bothers you? Use the variants presented in this tip for mass maintenance of role derivations. Especially in large companies, it often happens that a worldwide, integrated ERP system is used, for example, for accounting, distribution or purchasing. You will then have to limit access to the various departments, for example to the appropriate booking groups, sales organisations or purchasing organisations. In the permission environment, you can work with reference roles and role derivations in such cases. This reduces your administrative overhead for maintaining functional permissions and reduces maintenance work for role derivations to fit the so-called organisational fields. However, maintaining the organisational fields can mean enormous manual work for you, as the number of role derivations can become very large. For example, if your company has 100 sales organisations and 20 sales roles, you already have 2,000 role outlets. Here we present possible approaches to reduce this manual effort.
"Shortcut for SAP systems" is a tool that enables the assignment of authorizations even if the IdM system fails.
In doing so, we analyze your existing workflows and processes and work out optimization potentials.
So much information... how can you keep it so that you can find it again when you need it? That's what Scribble Papers is great for.
But restructuring must also be carried out at the organizational level.