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

Direkt zum Seiteninhalt
Implementing the authorization concept in the FIORI interface
SAP Authorizations - Overview HCM Authorization Concepts
When you create users in the SU01 transaction, do you want to automatically pre-occupy certain fields from a data source? Use a new BAdI for which we present an implementation example. If you create a user in the SU01 transaction in an SAP system, there is almost always data about that user in other systems. A classic example is user data in the Active Directory or the personnel master data in SAP ERP HCM, which are already maintained as part of the employee recruitment process. If user data is present in multiple systems, then the first choice is to automatically create a user through an identity management system, which is resolved by an HR trigger in SAP Identity Management (ID Management). ID Management detects changes, such as personnel master data, SAP ERP HCM, or business partners in SAP CRM, and either applies the appropriate users in your systems or makes changes and deactivations. But what if you don't have an identity management system in place? Do you need to type all of this data? No - you can pre-document them automatically. You can use a Business Add-in (BAdI), which allows you to pre-define certain fields when you create a user in the SU01 transaction.

However, a full SAP security audit does not end here. In addition, the auditor examines whether the four important concepts of SAP Security, namely the data ownership concept, the proprietary development concept, the authorization concept and the emergency user concept, meet the requirements. Each of them should represent a fully formulated document that, on the one hand, contains all the target specifications for the respective topic and, on the other hand, is consistent with the actual state found during the audit.
Use SAP Code Vulnerability Analyser
With the new transaction SAIS, you will enter the AIS cockpit, where you will be able to evaluate the various audit structures related to the topic. When performing an audit, under Audit Structure, select one of the existing structures and select a check number in the appropriate field. Audit structures may be subject to different audits; Therefore, you must always select an audit first. To do this, select a verification number or create a new audit. After you select the audit, the audit tree will appear in the cockpit. You can now perform the individual steps of the audit along the definition in the audit tree.

When you mix roles, either after upgrading or during role menu changes, changes are made to the permission values. You can view these changes as a simulation in advance. As described in Tip 43, "Customising Permissions After Upgrading," administrators may see some upgrade work as a black box. You click on any buttons, and something happens with the permissions in their roles. For example, if you call step 2c (Roles to be reviewed) in the SU25 transaction, all roles will be marked with a red light, which requires mixing based on the changed data from the SU24 transaction. Once you call one of these roles and enter the Permissions Care, the permission values change immediately. Using the Alt, New, or Modified update status, you can see where something has changed, but you cannot see the changed or deleted values. A simple example of how to play this behaviour without an upgrade scenario is changing the role menu. Delete a transaction from a test role and remix that role. You are aware that certain authorization objects have now been modified and others have even been completely removed, but can't all changes at the value level be replicated? Thanks to new features, this uncertainty is now over.

Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.

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.

You can do this in the transaction SCUG and transfer user data from the subsidiary system to the central system.
SAP BASIS
Zurück zum Seiteninhalt