Challenges in authorization management
SAP Data Analytics
Don't simplify your entitlement concept before you know all the requirements, but first ask yourself what you need to achieve. So first analyse the processes (if possible also technically) and then create a concept. Many of the authorisation concepts we found in customers were not suitable to meet the requirements. Some of these were "grown" permission concepts (i.e., requests were repeatedly added) or purchased permission concepts. Many of these concepts had in common that they had been oversimplified, not simply. A nice example is permission concepts that summarise all organisational levels in value roles or organisational roles. There are few examples, such as the role manager of the industry solution SAP for Defence and Security, in which the result of a value role concept is still useful and appropriate for the user. The assumption that you "sometimes" separate all the authorization objects that contain an organisational level is simple, but not useful. We have not found the simplification that only a user without permissions can definitely not have illegal permissions. However, there was always the case that users had far too many permissions and the system was therefore not compliant.
Other dangers include admins simply copying user roles, not having control processes for permission assignments, or not following the processes over time. In this context, two things should be clarified: Which SAP user is allowed to access which data? How do the roles differ (especially if they are similar)?
SAP Authorization Trace - Simple Overview of Authorizations
This type of programming makes sense if large amounts of data have to be read. Before starting to read the data from the database, a DUMMY check can be used to quickly determine whether the user is authorized to access part of the data. However, as can be seen from the table above, a code must not only be secured by a general check, but must be supplemented by later, detailed checks. However, even in this context space (or ' ') does not need to be explicitly authorized.
If you only want to translate the description of the role, it is recommended to record the PFCG transaction and to change the source language of the role using the Z_ROLE_SET_MASTERLANG report before the LSMW script runs through. The report on how to change the source language can be found in SAP Note 854311. Similarly, you can use the SECATT (Extended Computer Aided Test Tool, eCATT) transaction to perform the translation instead of the LSMW transaction. Furthermore, automation is possible with the help of a customer-specific ABAP programme. To do this, you should take a closer look at the AGR_TEXTS table. The table contains the different text blocks in different languages. Here we show you a section of the table with our example role Z_SE63. Short texts are assigned a value of 00000 in the column LINE, and long texts are assigned a value of 00001 to 0000x. The language keys are displayed in the SPRAS column. An ABAP programme now allows you to write the counterparts for the text fields in the target language into the fields in the tables.
"Shortcut for SAP systems" is a tool that enables the assignment of authorizations even if the IdM system fails.
The freeware Scribble Papers puts an end to the confusing paper chaos. The tool is also suitable for storing, structuring and quickly finding text documents and text snippets of all kinds in addition to notes.
Any error in the authorization system falls within the remit of a company's data protection officer.
Here you can filter the evaluation directly and get a better evaluation representation.