Authorization check
Development
After the functional specification has been removed, the implementation can begin: To do this, first create your custom authorization object and implement the permission check provided. The next step is to maintain the SU24 transaction proposal values for the respective customer transaction. To do this, call your custom-created transaction and assign the necessary authorization objects either manually by using the Object button, or use the Permissions or System Trace to assign the permissions (see Tip 40, "Using the Permissions Trace to Determine Custom Permissions Proposal Values"). You must leave the authorization objects used in the customer's own coding. For each authorization object, you can maintain field values that appear as suggestion values in the respective roles. Now all the roles concerned must be adapted. If the mixing mode for the transaction PFCG is set to On (see tip 38, "Use transactions SU22 and SU24 correctly"), all PFCG roles assigned to the transaction in the role menu will be recognised and can be remixed via the transaction SUPC. If the customer's transaction is not yet in the PFCG rolls, it will be added here and the respective PFCG role will be remixed.
In order to provide user authorisation support, you often need their information. However, there is also the possibility to view missing permissions centrally for all users. If a user has a permission issue, a ticket is usually displayed at support. However, it is difficult for a support worker to understand permissions errors because they have different permissions and are often missing detailed information about the application where the permission error occurred. In practice, therefore, support staff often help themselves by asking the user to send a screenshot of the transaction SU53. Because this transaction shows the last failed permission check. In many cases, however, the information displayed there is not helpful to the permission administrator. You may have seen that a screenshot from the SU53 transaction shows a missing permission for typical base authorization objects, such as S_ADMI_FCD, S_CTS_ADMI, or S_TRANSLAT, but you know that your check has nothing to do with the actual permissions problem in the application. So you need the opportunity to see for yourself.
Introduction & Best Practices
The aim of authorization concepts is to provide each user with the authorizations required for his or her task in the SAP system in accordance with the rules. A good authorization concept is the cornerstone for efficient and cost-effective authorization assignment.
This very critical authorization can be used to electronically erase, or manipulate program runs including authorization queries in a variety of ways. This authorization should be assigned only very restrictively, for example developers need the authorization however for their daily work.
"Shortcut for SAP systems" is a tool that enables the assignment of authorizations even if the IdM system fails.
In addition to the partially available online help for individual authorization objects, the question arises as to how the documentation for the authorization object can be called up.
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
The found authorization objects are imported from the table, but are not yet marked with any suggestion values.