Important components in the authorization concept
A concept for SAP authorizations prevents system errors and DSGVO violations
Customising roles are temporary because of their project nature. Therefore, when assigning users, maintain the end date. You cannot also map transactions manually if you created a role directly from a project or project view. Conversely, you cannot use an existing transaction role in the menu as a customising role. The transactions associated with a customising role are not displayed in the Session Manager or the SAP Easy Access menu, but can only be viewed through the view in the customising.
Locking and validity of the user account is done through the user administrator and is also valid for other authentication procedures. This means that a login via SSO is not possible for an invalid user or a user with administrator lock. We therefore always recommend that you prevent access to the system by setting the validity of users. Setting validity on assigned roles also prevents the user from performing actions in the system, but does not generally prevent them from logging in.
Debug ABAP programs with Replace
As part of identifying authorization problems, it should be documented what the risks are if the current situation is maintained. Often, those responsible in the company do not want to make a correction because it causes costs and work. If the current concept works and security gaps are abstract, many people in charge are reluctant to change anything. For these reasons, the first step should be to document what problems and dangers lurk if the current concept is not corrected: First, the risk of fraud, theft, and data privacy and security breaches increases. Documentation can help identify where dangers lie. There is a fundamental problem of financial damage to the company if action is not taken. Another danger is that users will experiment with their authorizations and cause damage that can be avoided by having a clean authorization structure. Also a problem is the increased administrative overhead of granting and managing permissions. The effort increases if the current role assignments are not transparent and optimally structured.
Native or analytical tiles: These tiles work exclusively in the FIORI interface and are adapted to the new technology. Here, for example, push messages are displayed on the tile, or key figures, diagrams, etc. are displayed, which can then be processed directly with a click. These tiles do not have direct GUI access, or cannot be used directly in the GUI environment. As mentioned above, access to these tiles is provided in a so-called front-end system via corresponding catalogs and groups. However, the underlying conceptual permissions (who is allowed to do what within the functionality of the tile) follows the same processes as in the "old world" for transaction access. The tile in the front-end needs here corresponding dependent distinctive authorizations (keyword: SU24 adjustment). In the back-end system, then again - analogous to the "old" world - about a role, which is built in the profile generator and maintained on object and field level, or set. Of course, topics such as updating internal and third-party tools, integrating cloud solutions, modern hybrid infrastructures, defining and operating ongoing dynamic changes, etc. must also be taken into account here.
Authorizations can also be assigned via "Shortcut for SAP systems".
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
You can then proceed with role follow-up as part of the release change in the SU25 transaction (see also Tip 43, "Customise Permissions After an Upgrade").
If you have made a release change to SAP NetWeaver 7.31 or higher, there are some changes in the logic of the transaction SU25.