User & Authorization Management with SIVIS as a Service
User Management
The assignment of roles does not include any special features. Therefore, we only deal with the topics of time-space delimitation and logging. Time-space validation is implemented as an additional filter that runs after the usual permission checks. This additional filter logic works as follows: The first step is to check whether the user is entered in the tax verifier table (Table TPCUSERN, Configuration with the transaction TPC2). Only then will the further tests be carried out. If not, no additional checks will be carried out. The programme is then checked to see if it is included in the table of allowed programmes (table TPCPROG, configuration with the transaction TPC4). If the check is negative, the system cancels with a permission error. The time-space check is performed against the valid intervals in the table TPCDATA (configuration with the transaction TPC6). The time-space check works in context: In addition to the supporting documents of the audit period, older supporting documents are also included if they are still relevant for the audit period, such as open items that were booked in previous years but only settled in the audit period. Records that do not fall into the valid period according to the logic described above are filtered out.
Once you have identified the organisational features to consider, verify that you can redesign the existing roles so that the organisational features can be clearly maintained by use. This leads you to a concept in which functional and organisational separation is simply possible. However, it will end up with a larger amount of roles: Roles posting/investing, changing roles, reading roles. Such a concept is free of functional separation conflicts and is so granular that the organisational characteristics can be pronounced per use area.
Authorization concept - recertification process
Run step 2a (automatic synchronisation with SU22 data). In this step, the data of the transaction SU22 of the new release will be transferred to the transaction SU24. If there is a change or difference in applications (changed check marks, suggestions, field values, or new or deleted authorization objects), the USOB_MOD or TCODE_MOD table of the MOD_TYPE is set to M. With SAP Note 1759777, a selection is offered for step 2a, with which this step can be simulated. Another option, Delete Flags for applications with modified data, is offered to apply the new changes only if Step 2a is executed selectively.
Each UI component that can be clicked corresponds to an external service that must each have permission set up. UI components also include creating or calling stored searches or navigating from one record directly to another record, such as calling an appointment directly from a business partner; This corresponds to cross-navigation. All navigation options in the form of external services are defined in the customising of the CRM business role in the form of a generic outbound plug mapping to the navigation bar. Outbound Plugs (OP) define what happens when a user leaves a view in SAP CRM. Here the customising is set for scenarios that do not necessarily fit all CRM business roles. The corresponding CRM business roles have been configured to be associated with outbound plugs that are not required for the respective CRM business role scenario. This explains the large number of external services in the role menu.
Authorizations can also be assigned via "Shortcut for SAP systems".
You can also find some useful tips from practice on the subject of SAP authorizations on the page www.sap-corner.de.
Delete a transaction from a test role and remix that role.
What rules should you follow? Introductory projects usually produce a large number of customised programmes without being subjected to a permission check when they are executed.