Using Generic Application Access Rules in SAP Custom Development
SAP applications often require the need to restrict access for certain entities to a subset of all instances. In most scenarios, SAP’s authorization concept is sufficient for this purpose. However, there are some disadvantages using SAP authorizations:
- When introducing a new business process it might not be clear which instances need to be accessed and which should be made inaccessible
- There is always a risk that some users are assigned to roles that grant unrestricted access to an entity (authorization field XYZ = ‘*’).
- It is hard to detect unauthorized access attempts to a forbidden instance
Developers can eliminate these disadvantages by integrating allowlists into business processes. By assigning an appropriate delivery class to the allowlist table/view, it is possible to reserve separate namespaces for third-party and customer content. However, the separation of namespaces often requires the introduction of artificial keys since the entity keys do not typically follow namespace conditions.
Generic SAP Application Access Rules
SAP Generic Application Access Rules introduce a switch framework that overcomes all the previously described limitations. It came into focus when SAP started to deliver Access Rules for the remote access to arbitrary tables via the function module RFC_READ_TABLE (see SAP RFC Read Table: Accessing Arbitrary Tables in SAP). The options for restricting this kind of remote table access are:
- Deny any call of RFC_READ_TABLE in the system via the Unified Connectivity Framework (UCON)
- Restrict the usage of the function module to certain users via authorization object S_RFC
- Grant certain users limited access to specific tables via authorization objects S_TABU_DIS or S_TABU_NAM
The following two control options were added through the introduction of Access Rules:
- Restrict access to specific tables for all users
- Restrict the programs from which the function module is allowed to be called
- (If RFC_READ_TABLE is called via the RFC interface, the calling program is always SAPMSSY1).
Generic Access Rules can be used as an additional layer to restrict user access. This framework is available for all SAP NetWeaver AS ABAP versions >= 7.0.
Managing Generic SAP Access Rules
The central transaction for the maintenance of Generic Access Rules is transaction SLDW. This is how Access Rule Definitions and Active Access Rules are maintained.
Note: In SAP NetWeaver Releases < 7.56, Generic Access Rules are called “Generic Whitelists” and/or “Generic Allowlists”. Unfortunately, the renaming was not completely done in all areas of the SLDW application. Therefore, this post also uses the previous wording whenever it directly references a part of the application that was not yet renamed by SAP.
SAP Access Rule Definition
The starting point when creating an access rule is the Access Rule Definition. The definition contains the header data of an Access Rule and optionally one or multiple Access Rule elements.
The header data includes:
- Name
- Short description
- Check Status
- Possible values are:
- A: Whitelist check active
- N: Whitelist check inactive
- I: Informal whitelist (warning without error encoding)
- R: Recording mode (add new elements in dialog)
- X: Recording mode (new elements get status Valid)
- D: Recording mode (new elements get status Invalid)
- SAL Mode (Security Audit Log Mode)
- Possible values are:
- N: No recording in the Security Audit Log
- E: Record failed checks in SAL
- A: Record all checks in the Security Audit Log
- A SAP document object
- An error message (optional)
The interesting aspect is that you can run an Access Rule in a learning mode that records all the newly checked elements (Check Status: R, X, D). Another helpful feature is the connection to the Security Audit Log(SAL). The following events have to be activated in SAL:
|
|
|
|
|
|
|
|
|
|
|
|
The element list of an Access Rule Definition contains information about the allowed and (optionally) the disallowed values. Possible status values for an element are:
- <space>: Not maintained
- X: Valid Rule Entry
- D: Invalid Entry (flagged for deletion)
- A: Entry for Check Note(Note mode)
An Access Rule Definition usually only contains entries of status ‘X’ since values not included in the element list are automatically disallowed. Records with status value <space> or ‘D’ are usually inserted into the element list of an Active Access Rule during recording (refer to next section).
SAP Active Access Rule
Once the creation of an Access Rule Definition is completed it must be activated. Transaction SLDW can be used to transfer the Access Rule Definition to an Active Access Rule. The Active Access Rule initially inherits all properties and elements defined in the Access Rule Definition. This can be adjusted afterwards either manually or through enabling one of the recording modes. This concept allows SAP and third party software providers to ship updated Access Rule Definitions without overwriting the customer’s active settings. Customers can then adjust their Active Access Rule, in a separate step, to the updated Access Rule Definition. These adjustments can be executed with transaction SLDW_COMPARE.
SAP Access Rule Check in Source Code
To check the existence and status of an element against an Active Access Rule, the following method call must be used:
cl_sldw=>access_check_entry( EXPORTING id_wl_name = ‘<Access Rule>’
id_wl_ename = CONV #( ‘<Element to check>’ )
id_silent = abap_false ).
If the check succeeds, the method returns 0. The parameter id_silent can be used to control whether the method should provide its own error message popup or if the error is handled by the caller of the method. In the later case, the message number and message area can be read from system variables. The message identifiers can be customized as part of the Access Rule Definition header data.
Important: The check method also returns 0 in case the check status of the checked Active Access Rule is marked “Whitelist check inactive” or if the Active Access Rule doesn’t exist at all! You can use the consistency check in transaction SLDW_COMPARE to identify such scenarios, but only if the Active Access Rule is still missing when starting the consistency check.
Lifecycle of an SAP Customer Access Rule
- Create an Access Rule Definition on the development system
If you are not sure about the allowed elements, enable an appropriate recording mode
=> The Access Rule Definition is tracked in a transport request as R3TR SLDD object
- Use transaction SLDW to transfer the Access Rule Definition to the corresponding Active Access Rule
=> The Active Access Rule is tracked in a transport request asR3TR SLDC object
- Transport the transport request to a test environment
- After the end of the recording period, based on the recorded entries on the test system, you can either adjust the Access Rule Definition and the Active Access Rule manually on the development system or you can use transaction SLDW_TRANSFER to transfer the results via a file interface from the test to the development system
Note: While transaction SLDW_COMPARE can be used to synchronize an Access Rule Definition with the corresponding Active Access Rule, there seems to be no option for the opposite direction. Thus, entries that were added to an Active Access Rule through recording must always be applied manually to the Access Rule Definition. - Change the check status of the Access Rule Definition to “Whitelist check active”
- Use transaction SLD_COMPARE, option “Mass Update- Header Data Active Rules” to adjust the check status of the Active Access Rule accordingly.
- Transport the transport request that recorded the changes into the follow-up systems.
The lifecycle for an Access Rule shipped by SAP or a third-party provider is explained in SAP Note #1922712, titled “SLDW: FAQ: Supplementary notes for whitelist maintenance”.
Conclusion
The Generic Access Rule framework can be used as an alternative or an additional option when it needs to restrict access to a certain entity. The advantages are:
- The recording mode allows the initial collection of all instances of an entity that must be accessible
- The framework, as an additional filter layer on top of the SAP authorization concept, can prevent unrestricted access granted through accidentally assigned generic authorizations (authorization field XYZ = ‘*’)
- Any attempt to access a forbidden instance can be recorded and detected in the SAP Security Audit Log
- SAP and third-party providers can ship updated content without impacting the customer’s active business processes
Helpful Transactions and Reports
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|