SAP Authorizations Implementing the authorization concept in the FIORI interface - SAP Basis

Direkt zum Seiteninhalt
Implementing the authorization concept in the FIORI interface
Permission implementation
The SU25 transaction lists additional customisation options in addition to upgrade activities. Under the item Adjustment of the permission checks (optional) are the transactions SU24 for the maintenance of the value of the proposal, the transaction AUTH_SWITCH_OBJECTS for the global elimination of the authorization objects as well as the transaction SE97 for the maintenance of transaction startup permissions checks (see Tip 76, "Maintain transaction start permissions when calling CALL TRANSACTION"). In the Manual Adjustment section of selected roles, you can create roles from manually created profiles, generate SAP_NEW (see Tip 64, "Use SAP_NEW correctly"), or generate SAP_APP as roles. In the General maintenance for suggestion values section, the reports SU2X_CHECK_WDY_HEADER for the registration of header data for external services (see tip 38, "Use the SU22 and SU24 transactions correctly") and SU2X_CHECK_CONSISTENCY for the concession test (available via the in SAP Note 16466666446445) 692 named Support Package) of suggestion values for the selected authorization objects.

Additional permission check on the S_RZL_ADM authorization object: For security reasons, an additional permission check is performed on the S_RZL_ADM authorization object for special PSE (Personal Security Environment) files with access type 01 (Create). These files are called *.pse and cred_v2. These files are required for single sign-on, encryption and digital signatures. They are maintained using the transaction STRUST and the transaction STRUSTSSO2, which require the same permission (see SAP Note 1497104 for details).
Goal of an authorization concept
You may have special requirements that are necessarily to be included in the naming convention, such as when you define template roles in a template project that can be customised locally. You can identify this in the naming.

If the changes to your SU24 data have not been detected with step 2a, or if you have imported transports from other system landscapes into your system, you have the option to reset the timestamp tables and start again. To do this, run the SU24_AUTO_REPAIR report in a system that is still at the state of the legacy release so that the modification flag is set correctly (see tip 38, "Use the SU22 and SU24 transactions correctly"). Subsequently, you create a transport and transport your SU24 data to the system, which is at the state of the new release. Now delete your timestamp tables. You can use the report SU25_INITIALIZE_TSTMP. Starting with SAP NetWeaver 7.31, you have the choice to set the reference time stamp from the SU22 data or delete the contents of the time stamp tables. You can then run Step 2a again.

With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.

Records that do not fall into the valid period according to the logic described above are filtered out.

Depending on the quantity of external services from the Role menu, the authorization objects will appear.
Zurück zum Seiteninhalt