- Introduction
- SAP Realms
- Import SAP Tables
- Reports
- RFC Execution
- SOD & Audit
- Coverage
- Mapper
- Code Security
- Settings
- Technical Connection Information
- Extraction Information
ZSecTools is a browser-based application for SAP security administration and Segregation of Duties (SOD) analysis. It connects to one or more SAP systems via RFC, lets you import and manage authorization-related data, run mass administration tasks (such as batch RFC execution for users and roles), perform SOD risk analysis against a configurable rule matrix, and scan ABAP source code against configurable security checks (see Code Security).
The application is organized into sections, accessible from the side panel: SAP Realms, Import SAP Tables, Reports, RFC Execution, SOD & Audit, Coverage, Mapper, Code Security and Settings (which includes Health Checks). In the side panel, all section buttons are disabled until an active SAP Realm is selected, with the exception of SAP Realms and Settings, which are always available
A "Realm" represents a single SAP system you want to connect to. In this section you can create, edit, and delete as many realms as you need, each with its own connection details (application server, system number, client, credentials, and language).
Always verify that the machine running the backend can reach the SAP system referenced by the selected realm — you can confirm this with an RFC ping by using the Test connection (RFCPING) button.
Selecting an active realm here is mandatory to use every other section of the application.
Please also pay attention to Realm reference date field: it should match the SAP tables download date, because it will be used as a reference for calculating users and roles validity.
Note: Users and roles validity is calculated using Build additional infos (see Import SAP Tables): remember to update it if you are using an already existing realm to import SAP tables multiple times on different days!
This section lets you download the SAP tables that the application relies on, directly from the currently selected realm.
The list of tables that can be downloaded is controlled by the SAP-TABLE-LIST.txt configuration file in the project root. You can edit this file to add or remove tables according to your needs. From the UI, you can then select or deselect, on each run, which of the listed tables to actually download.
For most of the application's features to work correctly, it is recommended to download at least the default tables listed in SAP-TABLE-LIST.txt, with the exception of the RSEC* tables (specific to SAP BW) and TBTCP / TBTCO, which are optional and only relevant for specific use cases.
Buttons available in this section:
- Download selected Tables from SAP: downloads the currently selected tables from the active SAP realm and stores them locally.
- Export TXT: exports the locally stored tables as
.txtfiles, useful for backup or for transferring data between environments without a direct SAP connection. - Import TXT: imports previously exported
.txttable files back into the local database. - Select All / Deselect All: quickly select or deselect every table in the list.
- Build additional infos: builds internal helper tables that several features of the application depend on, most notably the Reports section. This button should be run after downloading the relevant SAP tables and, ideally, after downloading user statistics as well.
- Download Statistics / Export Statistics TXT / Import Statistics TXT: equivalent download/export/import actions, but for SAP user usage statistics rather than table data.
This section provides a collection of ready-to-use reports. Some of them mirror reports available from the SAP SUIM transaction, while others are additional reports built specifically for this application, not directly available in standard SAP transactions.
Reports are generated from the locally imported tables (see Import SAP Tables), so make sure the relevant tables — and, where needed, the additional infos — have been downloaded and built beforehand.
Select a report from dropdown menu (reports content is self-explanatory), run it with button Execute query, wait for results, and then you can export to a CSV file.
This section allows you to run mass operations against SAP, such as bulk user or role changes, by executing the same RFC call repeatedly for a list of input rows.
The application expects a tab-separated CSV file as input. The exact column layout expected depends on the RFC action you select from the dropdown menu: once you pick an action, the application displays the required field layout directly in the UI, so you always know which columns your CSV file needs to contain before uploading it.
After uploading the file and reviewing the preview, click Execute RFC Batch to run the operation against every row of the input file. The application reports execution results per row, including any errors encountered.
When uploading an input file, the application checks the first line (header) match the Required fields schema (and if not, it refuses to upload it); please copy-paste this for creating header in input file, do not consider the example below in which every header is modified in order to make it more explanatory. Example box shows for each RFC Command the expected data values (such as datefrom-dateto that should be YYYYMMDD).
This section allows you to run Segregation of Duties (SOD) analysis and SAP security audits using a configurable risk matrix.
An example matrix is provided in the sodMatrixExample.zip file in the project root. Its main purpose is to document the exact file layout the application expects when importing a rule matrix — the format is closely modeled on the one used by SAP GRC Access Control (on-premise).
The section is organized into the following panels:
- Ruleset dropdown: selects which ruleset (rule matrix) is currently active for the analysis.
- Import: imports a rule matrix from files matching the expected layout (see
sodMatrixExample.zip) into the selected ruleset. - Export: exports the currently selected ruleset back to files in the same layout.
- Delete Ruleset: deletes the currently selected ruleset and all of its rules.
- Delete SOD (All): deletes all SOD-related data (every ruleset and every rule) from the application.
- Element Type / Element ID: select whether you want to analyze users or roles, and which specific element(s) to include.
- Add element: adds the selected element(s) to the list of elements to be analyzed.
- Analysis Level: selects the depth of the analysis to be performed.
- Run Analysis: runs the SOD analysis against the elements added so far, using the currently selected ruleset.
- Refresh: reloads the results table with the latest analysis output.
- Export results: exports the analysis results to a CSV file.
- Clear elements: removes all elements currently queued for analysis, letting you start a new selection from scratch.
The typical workflow for this section is: import the rule matrix, select the ruleset to use, add the elements you want to analyze with Add element, run the analysis with Run Analysis, then review and export the results.
The Coverage Analysis section allows you to evaluate role assignments against actual transaction usage. This helps identify over-allocated roles, missing access, or required security adjustments for analyzed users.
This analysis is specifically tailored for business users. Therefore, best works with only transactions explicitly present in role menus; any access granted via ranges or wildcards in the S_TCODE authorization object is intentionally included, but it is not the correct use of this tool.
The analysis follows this workflow:
- Define Users: Specify the targeted users to analyze.
- Define Role Assignments: Load or import the candidate role-to-user mappings to test.
- Fetch Usage Data: The system retrieves historical transaction execution statistics for each user.
- Evaluate Proposed Coverage: Checks if executed transactions are covered by the candidate role mappings provided in Step 2.
- Evaluate As-Is Coverage: Checks if executed transactions are covered by the user's current ("as-is") role assignments in the database.
- Generate Results: Outputs the final coverage matrix for comparison.
While most coverage statuses are self-explanatory, note the following key states:
01-COVERED: The transaction is covered by the proposed role assignments.02-MISSING: The transaction is not covered by the proposed role assignments, but it is covered by the user's current ("as-is") roles. Removing these roles would result in lost access for actively used transactions.03-EXTRA: The proposed roles grant access to transactions that the user has never executed in the retrieved usage statistics.04-ALREADY-MISSING: The executed transaction is covered neither by the proposed roles nor by the user's current ("as-is") role assignments. This indicates one of two scenarios:- The transaction assignment was revoked from the user between the start of the collected usage period and the execution of this analysis.
- The transaction access is currently granted via range or wildcard values in
S_TCODErather than an explicit menu entry.
Note: If you run an analysis using the actual current assignments (e.g., loaded via Get as-is roles from DB), you should expect no
02-MISSINGstatus in the results—onlyCOVEREDorALREADY-MISSING.
Define the scope of users you wish to include in the coverage check.
- User ID Input: Input a specific User ID or use SQL wildcards (
%and_) to select multiple users (e.g.,ZTEST%). - Add user: Executes a search/filter and adds matching users to the analysis queue.
- Upload CSV/TSV File: Select a local CSV, TSV, or TXT file containing user data to load.
- Import users: Uploads and imports the selected user file into the temporary analysis buffer, with tcode relationship. Append mode.
- Export users: Downloads a CSV file containing the currently loaded list of users to analyze.
- Get Users Statistics: Fills user-tcode table with statistic data.
- Clear: Clears all loaded users from the current workspace.
Manage the roles assigned to the targeted users for comparison.
- Get as-is roles from DB: Automatically populates existing role assignments for the targeted users directly from the DB.
- Upload CSV/TSV File: Select a local file containing user-to-role mappings.
- Import roles: Uploads and imports the role assignments file into the temporary buffer, with tcode relationship. Append mode.
- Export roles: Downloads a CSV file containing all currently active role assignments in the buffer.
- Clear: Clears all loaded role assignments from the workspace.
Run the analysis and review the coverage metrics.
- Run Coverage Analysis: Triggers the background processing engine to evaluate transaction logs against role definitions for all loaded users.
- Refresh: Reloads the results table view with the latest status from the backend (usually not necessary).
- Export CSV: Exports the full coverage results matrix into a formatted CSV file.
The analysis classifies results into distinct status categories for quick review: see Understanding Analysis Results
The Mapper Analysis section allows you to identify the most suitable roles to assign to a user, a composite role, or any other transaction container (defined as an "element to map"). The algorithm operates as follows:
- Group transactions for each element to be analyzed (element to map).
- Search among the candidate roles (mapping items/roles) for the one containing the highest number of required transactions.
- If 2 candidate roles contain the same number of target transactions, the role with the fewest total transactions overall wins.
- If both candidates also have the exact same total number of transactions, the one that comes first alphabetically is selected (as a fallback rule).
- The logic iterates until all transactions for the "elements to map" have been evaluated.
This analysis tool should be used within a carefully designed authorization model—typically one featuring role families divided by access levels and based on the subset principle: In a role family, the "full" level role contains all transactions for that family, the "edit" level contains only "edit" and "read" transactions, and the "read" level contains only "read" transactions. This allows the algorithm to effectively identify only the role with the exact access level required by the user (or element to map).
This analysis is specifically tailored for business users and business roles. Consequently, it is important to avoid mapping IT/ICT users or roles, which are typically very broad and contain ranges or wildcards (*) for the S_TCODE auth object.
The workflow is as follows:
- Define Users / Elements to Map: Specify which users to analyze (or a fictitious container).
- Define Mapping Roles: Load or import the candidate role-tcode mappings to test.
- Fetch Usage Data: The system retrieves historical transaction execution statistics for each user, if needed.
- Evaluate Proposed Mapping: Checks if executed transactions are covered by the candidate role mappings provided in Step 2 (using the algorithm described above).
- Generate Results: Outputs the final coverage matrix for comparison.
While most coverage statuses are self-explanatory, note the following key states:
01-COVERED: The transaction is covered by the proposed role assignments.02-MISSING: The transaction is not covered by any role specified as a "mapping item".03-EXTRA: The proposed roles grant access to transactions that the user has never executed in the retrieved usage statistics, or that are not listed in simulation assignments.
Define the scope of users, composite roles, or any containers you wish to include in the Mapper Analysis.
- Element ID Input: Input a specific User ID or use SQL wildcards (
%and_) to select multiple users (e.g.,ZTEST%). - Add user: Executes a search/filter and adds matching users to the analysis queue.
- Import Element to Map: Select a local CSV, TSV, or TXT file containing elementid-tcode relationships you would like to analyze. Data is loaded in append mode.
- Export Element to Map: Downloads a CSV file containing the currently loaded list of elements to map.
- Get Users statistics: Automatically fetches users' transaction execution statistics to populate the elementId-tcode relationships to be mapped.
- Remove Users: Removes selected (checked) users/elementIDs from the workspace.
- Clear ElementID: Clears all loaded elements.
Manage the roles used to match the transaction requirements of the "elements to map".
- Role Name Input: Input a specific Role Name or use SQL wildcards (
%and_) to select multiple roles (e.g.,ZROLE%). - Get tcodes from DB: Automatically fetches tcodes assigned to roles directly from the database. Attention: Tcodes are evaluated from
S_TCODEobject values: any range or wildcard will be expanded. - Import Mapping roles: Uploads and imports the role-tcode assignments file. Data is loaded in append mode.
- Export Mapping roles: Downloads a CSV file containing all currently active mapping role-tcode assignments in the buffer.
- Remove item: Removes selected (checked) roles from the workspace.
- Clear Roles: Clears all loaded roles from the workspace.
Run the analysis and review the coverage metrics.
- Run mapping: Triggers the background processing engine to evaluate
element-to-map - transactionagainstrole-tcodefor all loaded elements. - Refresh: Reloads the results table view with the latest status from the backend (usually not necessary).
- Export Results: Exports the full mapper results matrix into a formatted CSV file.
- Clear Results: Drops the results table.
The Code Security section lets you search ABAP programs, download their source code (including all their includes) and run configurable security checks against it. Typical use cases are the detection of hardcoded user IDs, obsolete or dangerous statements, or any other coding pattern you want to monitor across a set of programs.
All the artifacts of this section live in the CodeSecurity/ folder at the application root:
codeSecurityChecks.txt: the check definitions (see The checks configuration file).codeSecurityChecksExample.txt: a sample checks file delivered with the project. WhencodeSecurityChecks.txtis missing, it is automatically created at first startup by copying this example file; only if the example file is missing too, a single built-in sample check is created instead.- one sub-folder per downloaded program, each containing the
.txtsource of the program plus the source of every include found (recursively).
The section works on the currently selected realm: the program list comes from the TADIR table (repository objects of type PROG), which is imported by the Import SAP Tables section.
Each check is defined in CodeSecurity/codeSecurityChecks.txt as a group of KEY=VALUE rows; a new check starts at the ID= row. The supported keys are:
| Key | Meaning |
|---|---|
ID |
Unique identifier of the check; starts a new check record. |
TEXT |
Free description shown next to the ID in the UI. |
SEARCH_STRING |
The string to look for in the source code. It can be repeated inside the same check: every SEARCH_STRING= row adds another string to search, and all of them are evaluated together (the occurrence counters are summed). |
EXCEPTION |
Optional exclusion pattern, can be repeated. Source lines matching an EXCEPTION are excluded from the occurrence count; in addition, if any EXCEPTION pattern occurs anywhere in the program, an IS_DEFECTIVE=FALSE check can never turn red (see Semaphore logic). |
IS_DEFECTIVE |
TRUE or FALSE. Defines the semantics of the check: TRUE means the searched string is a defect (found → red); FALSE means the string is a required/safe pattern (not found → red). |
Both SEARCH_STRING and EXCEPTION values support the SAP-style wildcards * (any sequence of characters) and + (any single character); the search is case-insensitive.
Note: ABAP comments (full-line
*comments and inline"comments) are stripped from the source before scanning, so strings inside comments do not affect the results.
The checks file is read when the section is loaded; use the Reload checks button to re-read it from disk after editing it (no application restart is needed). A check without at least one SEARCH_STRING row is ignored.
Every check run produces, for each downloaded program, a result row with a traffic-light value:
- RED: the check found a problem — either at least one
SEARCH_STRINGoccurrence was found andIS_DEFECTIVE=TRUE, or no occurrence was found whileIS_DEFECTIVE=FALSEand noEXCEPTIONpattern matched. - GREEN: no problem detected (all other cases).
The circle next to each check in the Security Checks panel shows the overall check semaphore: RED if at least one scanned program is red, GREEN otherwise (grey means the check has not been run yet).
- Program name: input field with SAP-style wildcards (
*= any string,+= any single character), e.g.Z*orSAPL+ABC. - Search program: searches the TADIR table of the active realm for programs (
PROGobjects) matching the pattern and fills the Found programs table on the right. The result set is capped (500 programs): if the limit is reached, the UI suggests refining the pattern. - Import CSV: alternative to the pattern search, useful when the programs to verify do not share a single naming pattern. It loads a one-column CSV file (
.csvor.txt) containing the list of program names to verify in TADIR:- the first row is treated as the header and is skipped;
- only the first field of each row is read (separators
;,,or tab are accepted; surrounding double quotes are stripped); empty rows and duplicated names are ignored; - every listed program is verified in TADIR exactly as the Search program button does, and the found ones replace the content of the Found programs table;
- at the end of the upload a summary message reports: how many programs are listed in the file, how many were found in TADIR (and loaded in the table) and how many do not exist (the missing names are listed, up to 20).
- Download Source: downloads the ABAP source of every program listed in the Found programs table (the textbox value is ignored), creating one sub-folder per program under
CodeSecurity/. Includes are followed recursively and saved next to the main program (with cycle protection). A live progress bar shows the current program, and the final message reports the total number of files written and any per-program errors (a failing program does not stop the batch). The button is disabled until a search/import has filled the table.
Shows the search/import results (one row per program). This table is the input of the Download Source button.
Lists the checks defined in codeSecurityChecks.txt, each with a checkbox, the semaphore circle and a per-check run button:
- Reload checks: re-reads the checks file from disk.
- Select all / Deselect all: tick or untick every check checkbox at once.
- Run selected checks (N): runs only the ticked checks (the number of selected checks is shown on the button; disabled when no check is selected).
- Run all checks: runs every defined check.
- run this check (per row): runs only that check.
Each run scans every .txt source file of every downloaded program folder, counts the occurrences of all the SEARCH_STRINGs (case-insensitive, wildcards allowed, comments stripped, EXCEPTION lines excluded), stores one result row per program in the database and refreshes the semaphore of the check.
Shows the stored results, one row per program/check (program, check id, result, occurrences, run timestamp), with rows colored according to the semaphore (red/green). The table is paginated (First / Prev / Next / Last).
- Refresh: reloads the results from the database.
- Export results: exports the whole results table (not just the visible page) to a CSV file.
- Clear results: permanently deletes all stored results and resets the semaphores of the checks; a confirmation is required. The button is disabled when there are no results.
The typical workflow is: define (or review) the checks in codeSecurityChecks.txt → search the programs with Search program or load them with Import CSV → download the sources with Download Source → run the checks (Run all checks or Run selected checks) → review, export or clear the results. Re-running a check replaces its previously stored results for that check.
The Settings section groups application-level configuration and diagnostics. It is organized into two sub-sections: General and Health Checks.
Work in progress. General application settings (such as appearance/theme options) will be available here in a future release.
This section lets you verify that the application's prerequisites are correctly installed and working: backend availability, database connectivity, and the SAP NW RFC SDK setup. You can also save the SDK path here, which is persisted in the database and applied automatically on backend startup. Please restart application if on Windows (no needs in Linux or Docker container). Keep in mind you still need to use Linux SAP SDK with Docker running on Windows.
Before running an SAP connectivity check (RFCPING), select an active realm in the SAP Realms section. The ping check verifies that the machine running the backend can actually reach the selected SAP system over the network and that the provided credentials are valid.
The program uses the standard SAP library (sapnco.dll or sapnco.so) which provides the classes necessary for developing interface programs (RFC connections) in a Windows/Linux environment.
The default connection occurs on port 36[SID] via RFC (this is a standard SAP behavior, you cannot change it).
For RFC calls, it is necessary to provide the program with the credentials of a valid user (interactive mode is not required), therefore one of the following SAP user types: B (System) or A (Dialog) or S (Service). User type B (System) is recommended.
Type C (Communication) is not applicable as the classes dedicated to self-service password changes are not available.
The connection user must have the following minimum authorizations assigned, please consider anyway to use ZSECTOOLS.SAP role as it has been fully tested. The following list is for documentation only proposals:
Object 1: S_RFC
- ACTVT: 16
- RFC_NAME:
- DDIF_FIELDINFO_GET
- RFCPING
- RFC_FUNCTION_SEARCH
- RFC_METADATA_GET
- RFC_READ_TABLE
- SWNC_COLLECTOR_GET_AGGREGATES
- RFC_TYPE: *
Object 2: S_TABU_DIS
- ACTVT: 03
- DICBERCLS:
- &NC&
- BWC
- FC01
- MCOR
- PA
- PC
- SA
- SC
- SPWD
- SS
Object 3: S_TABU_NAM
- ACTVT: 03
- TABLE: (see next point Extraction Information). In our case, all values listed in the first column "Table" should be entered in this authorization field (at least mandatory ones).
Object 4: S_TOOLS_EX
- AUTH: S_TOOLS_EX_A
The tables extracted by the program are as follows (this list may change in future releases):
| Table | Table Group | Table Description | Mandatory |
|---|---|---|---|
| AGR_DEFINE | SS | Role definition | YES |
| AGR_AGRS | SS | Roles in Composite Roles | YES |
| AGR_1250 | SS | Authorization data for the activity group | YES |
| AGR_1251 | SS | Authorization data for the activity group | YES |
| AGR_1252 | SS | Organizational elements for authorizations | YES |
| AGR_1016 | SS | Current Subprofiles for Single Roles | YES |
| AGR_TEXTS | SS | File Structure for Hierarchical Menu - Customer | YES |
| AGR_TCODES | SS | Assignment of roles to Tcodes | YES |
| AGR_FLAGS | SS | Role attributes | YES |
| AGR_HIER | SS | Table for Structure Information for Menu | YES |
| AGR_HIERT | SS | Role menu texts | YES |
| AGR_USERS | SS | Assignment of roles to users | YES |
| AGR_DATEU | SC | Personal settings for roles | YES |
| AGR_TIME | SS | Time Stamp for Role (Menu, Profile, Authorizations) | YES |
| AGR_LSD | Role attributes | YES | |
| AGR_BUFFI | SS | Internet Links for a Role | YES |
| ADCP | SA | Person/Address Assignment (Business Address Services) | YES |
| ADR6 | SA | E-Mail Addresses (Business Address Services) | YES |
| ADRP | SA | Persons (Business Address Services) | YES |
| DF14L | SS | Application Components | NO |
| DF14T | SS | Business Application Component Names | NO |
| HRP1000 | SC | Infotype 1000 DB Table | NO |
| HRP1001 | SC | Infotype 1001 DB Table | NO |
| TADIR | SS | Directory of Repository Objects | YES |
| TBTCO | SC | Job Status Overview Table | NO |
| TBTCP | SC | Background Job Step Overview | NO |
| TDEVC | SS | Packages | YES |
| USORG | SS | Org. levels for profile generator | YES |
| USORG_DB | Generated Table for View | YES | |
| USVART | SS | Possible authorization fields as variables | YES |
| USR01 | SC | User master record (runtime data) | YES |
| USR02 | SPWD | Logon Data (Kernel-Side Use) | YES |
| USREFUS | Reference user for internet applications | YES | |
| UST04 | SA | User masters | YES |
| UST10S | SS | User master: Single profiles | YES |
| UST10C | SS | User master: Composite profiles | YES |
| UST12 | SS | User master: Authorizations | YES |
| USR21 | SA | User Name/Address Key Assignment | YES |
| USGRP | SC | User Groups | YES |
| USGRPT | SC | Text table for USGRP (User groups) | YES |
| USGRP_USER | Assignment of Users to User Groups | YES | |
| USR06 | SA | Additional Data per User | YES |
| PA0001 | PA | HR Master Record: Infotype 0001 (Org. Assignment) | NO |
| PA0002 | PA | HR Master Record: Infotype 0002 (Personal Data) | NO |
| PA0105 | PA | HR Master Record: Infotype 0105 (Communications) | NO |
| T001 | FC01 | Company Codes | YES |
| T001W | MCOR | Plants/Branches | YES |
| T777P | PC | Plan Versions | YES |
| T778P | PC | Plan Versions | YES |
| TOBJ | SS | Authorization Objects | YES |
| TOBJT | SS | Short Texts for Authorization Objects | YES |
| TSTC | SS | SAP Transaction Codes | YES |
| TSTCT | SS | Transaction Code Texts | YES |
| TSTCP | SS | Parameters for Transactions | YES |
| USOBT_C | SC | Relation Transaction > Auth. Object (Customer) | NO |
| USOBX_C | SC | Check Table for Table USOBT_C | NO |
| RSECHIE | Status of Authorization Hierarchies | NO (BW only) | |
| RSECHIE_STRING | Status of Authorization Hierarchies | NO (BW only) | |
| RSECTXT | BWC | Authorization Texts | NO (BW only) |
| RSECVAL | Authorization Value Status | NO (BW only) | |
| RSECVAL_STRING | Authorization Value Status | NO (BW only) | |
| RSECBIAU | Header Table for TLOGO BI Authorization BIAU | NO (BW only) | |
| RSECUSERAUTH | BI AS Authorizations: Assignment of User Auth | NO (BW only) | |
| RSECUSERAUTH_CL | BI AS Authorizations: Assignment of User Auth (Change Log) | NO (BW only) | |
| RSECHIE_CL | Authorization Hierarchies Changes Change Log | NO (BW only) | |
| RSECTXT_CL | Change Documents for Document Texts | NO (BW only) | |
| RSECVAL_CL | Authorization Value Change (Change Log) | NO (BW only) |
Access to these tables occurs in read-only mode via the standard SAP function module RFC_READ_TABLE.
Additionally, daily, weekly or monthly aggregated usage statistics are extracted, whose database can be accessed in SAP via transaction ST03N (function module SWNC_COLLECTOR_GET_AGGREGATES).
Non-mandatory tables are not necessary for analysis purposes and could be extracted only for specific needs.