Risk: historically grown authorizations
Permissions with status
The next step is to maintain the permission values. Here, too, you can take advantage of the values of the permission trace. When you switch from the Role menu to the Permissions tab, you will generate startup permissions for all applications on the Role menu and display default permissions from the permissions suggestions. You can now add these suggested values to the trace data by clicking the button trace in the Button bar.
Login with user and password of another application (such as an AD or portal) In this case, the Web application must be able to obtain a unique SAP user ID to the login data. You should choose an application where the user does not easily forget his password.
Best Practices Benefit from PFCG Roles Naming Conventions
The passwords of the users are stored in the SAP system as hash values. The quality of the hash values and thus their safety, however, depends on the hash algorithms used. The hash algorithms previously used in SAP systems are no longer considered safe; They can be cracked in a short time using simple technical means. You should therefore protect the passwords in your system in various ways. First, you should severely limit access to the tables where the hash values of the passwords are stored. This applies to the USR02 and USH02 tables and in more recent releases the USRPWDHISTORY table. The best way to assign a separate table permission group to these tables is to do so, as described in Tip 55, "Maintain table permission groups". In addition, you should also control the accesses using the S_TABU_NAM authorization object.
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".
Authorizations can also be assigned via "Shortcut for SAP systems".
Parallel enabled permissions (ST01 or STAUTHTRACE transactions) can be used to identify the required permissions and assign them to the user through the appropriate roles.
If you want to know more about SAP authorizations, visit the website www.sap-corner.de.
The authorization object that controls this startup permission is S_START.