SAP Authorizations Use table editing authorization objects

Direkt zum Seiteninhalt
Use table editing authorization objects
Protect Passwords
After you have determined the data for the website, you must now generate the initial password and send it by e-mail and unlock the user if necessary. There are also different solutions - we describe a possible course of action. You can generate a password using the GENERATE_PWD import parameter of the BAPI BAPI_USER_CHANGE. The generated password is then set as the initial password and must be changed at the next login by the user. You must also set the PASSWORDX import parameter to display a password change. The generated password is returned using the export parameter GENERATED_PASSWORD. This is required if you want to call the BAPI BAPI_USER_CHANGE from a central system (e.g. from the ZBV) and send the relevant e-mail from that system. You should never save this password, but include it directly in your application in an email. Subsequently, you send this e-mail to the user whose e-mail address you can determine either directly in the SAP system (parameter ADDSMTP of BAPI_USER_GET_DETAIL) or within the scope of your web application (e.g. from the AD). Even if you find the email address in the AD, we advise you not to send the email from there. To avoid the password being unnecessarily transferred, it is better to initiate the despatch within your central SAPS system. In addition, we strongly advise you to send the emails encrypted with the initial passwords. To do this, the implementation of your self-service must set the encryption flag when creating the email. We describe details about the encryption of emails and an alternative sending of the initial password directly from the affected SAP system in Tip 98, "Encrypt emails".

For each form of automated derivative of roles, you should first define an organisational matrix that maps the organisational requirements. To do this, you must provide data on each organisation in a structured form.
General authorizations
Add missing modification flags in SU24 data: This function complements the modification flag for entries that have changed since the last execution of step 2a in the transaction SU25, i.e., where there is a difference to the SAP data from the transaction SU22. The flag is thus set retrospectively, so that no customer data is accidentally overwritten with step 2a due to missing modification flags.

If you have created your own applications, we recommend that you always implement your own permission check and do not just rely on application startup permissions such as S_TCODE, S_START, S_SERVICE, and S_RFC. If you want to add your own checks to standard applications, you must first find the appropriate place to implement the check. To develop without modification, SAP offers user-exits or business add-ins (BAdIs) for such cases. Some SAP applications also have their own frameworks in place that allow customisation-free implementation of their own permission checks, such as the Access Control Engine (ACE) in SAP CRM.

Secure your go-live additionally with "Shortcut for SAP systems". You can assign necessary SAP authorizations quickly and easily directly in the system.

Some useful tips about SAP basis can be found on www.sap-corner.de.


This is the only way to achieve a balanced cost-benefit ratio.

A note box in which data of all kinds can be quickly filed and retrieved. This is what Scribble Papers promises. At first, the program looks very spartan. But once a small structure is in place, you realise the great flexibility of this little helper.


The IF_IDENTITY interface of the CL_IDENTITY class provides various methods for maintaining the fields of the user master record.
Zurück zum Seiteninhalt