SAP Security Audit Log Integration via API

Purpose

This guide explains how to collect SAP Security Audit Log (SAL) records in Logsign USO through an ABAP REST service. Logsign calls the service over HTTPS with Basic Authentication, asks for one time range at a time and continues from the end of the last range it completed.

Logsign does not install this service. Your SAP team publishes it on your SAP system, so the service must follow the contract described in Step 1. This source is also the better choice when SAP exports SAL to a file that it overwrites in place: such a file cannot be read reliably by byte offset, which loses and duplicates records, while this source works with time ranges instead of file positions.

Prerequisites

Logsign version: a Logsign USO release that lists SAP Security Audit Log under the API sources.

Network access: the Logsign server must reach the service URL. There is no fixed address for this integration, because the URL belongs to your own SAP landscape (an application server or an SAP Web Dispatcher in front of it). Use HTTPS, because the username and password are sent with every request.

SAP service user: create a dedicated user for Logsign and use it only for this service. It needs permission to call the service and to read Security Audit Log records, and nothing else. The exact SAP authorizations depend on how your service is implemented, so Logsign does not publish a fixed list. Avoid using a dialog or administrator account.

Step 1: Publish the Service on the SAP Side

The service must accept a POST request with Basic Authentication and this JSON body. All four parameters are always sent, and a range can cross midnight:

{
  "iv_date_from": "20.10.2025",
  "iv_date_to": "20.10.2025",
  "iv_time_from": "00:00:00",
  "iv_time_to": "00:59:59"
}

It must answer with a JSON object that has a data list:

{
  "data": [
    {
      "msg": "AU1",
      "sid": "PRD",
      "instance": "sapapp01_PRD_00",
      "sal_date": "2025-10-20",
      "sal_time": "00:00:46",
      "tasktype": "B1",
      "taskno": "020",
      "slgmand": "100",
      "slguser": "JOBUSER",
      "term_ipv6": "",
      "param1": "B",
      "param2": "0",
      "param3": "A",
      "slgrepna": "RSBTCRTE",
      "txsubclsid": "Dialog Logon",
      "sal_data": "Logon successful (type=B, method=A)",
      "paramx": "",
      "counter": 0
    }
  ]
}

Logsign relies on the following behavior, so check each point with your SAP team before you add the source:

On SAP systems that provide it, the standard function module RSAU_API_GET_LOG_DATA can supply the records and accepts separate date and time limits. How you build the service around it is up to your SAP team.

You can test the service from the Logsign server before you add the source. curl asks for the password:

curl -u <service_user> -X POST "https://<host>:<port>/<service_path>?sap-client=<client>" \
  -H "Content-Type: application/json" \
  -d '{"iv_date_from":"20.10.2025","iv_date_to":"20.10.2025","iv_time_from":"00:00:00","iv_time_to":"00:59:59"}'

Step 2: Configure the Integration in Logsign USO

Go to Settings > Data Collection > +Device, select API and then SAP Security Audit Log. The form contains the following fields:

The other common source fields (Period, EPS, Data Policy, Device Name and so on) work as they do for other API sources.

Setting the Offset correctly

SAP has no timezone information in this API, so Logsign works out the SAP time from its own clock and the Offset field. The value is used in two places: to calculate the time range it requests from SAP, and to convert Time.Generated to Logsign time.

If SAP and Logsign run in the same timezone, leave Offset at 0. If they differ, enter the number of minutes you must add to the SAP time to get the Logsign time. For example, with SAP on UTC and Logsign on UTC+3, select + and enter 180. With SAP on UTC+3 and Logsign on UTC, select - and enter 180. Always enter a positive number and set the direction with the selector, because a negative number in this field is ignored.

The offset is a fixed number, so if only one of the two systems follows daylight saving time you need to update it when the clocks change. Keep both systems synchronized with NTP as well: if the SAP clock runs behind the Logsign clock by more than the Safety Lag, Logsign can request a second before SAP has reached it, and records from that second are then missed. Increase the Safety Lag if you cannot rule this out.

Step 3: Disable Other Collection for the Same SAP System

Disable any existing SMB, SFTP or syslog collection for the same SAP system when the API source goes live, otherwise records arrive twice. The API source does not know about records another source has already collected. Choose a Log Start Date that does not reach back before the old source was stopped if you want to avoid duplicates in that period.

The new source reports a different event source than the file and syslog collection, so review any alert rules or reports that use these values. Filters on Vendor and Product keep working. Filters on PrefixID or Category need updating.

What Gets Collected

Every record the service returns is collected. Field mappings:

This layout is the same as the SAL Structured syslog plugin. The param fields carry different content depending on the SAP message, so in a logon record URL.Path holds the logon type rather than a path. Empty values are not written. The counter field is not mapped because it is only the row number in the response and changes between queries; it stays in the raw SapSalAPI data.

Logsign classifies each record by its msg value using a built-in list of 149 SAL message IDs, which also fills Event.Info and Severity.Name. A few examples:

Message IDs outside the list are still collected and fall back to System / Operation / Info with information severity.

Notes and Limits

• One SAP system per source: the source calls one URL, so add a source for each SAP system that has its own service.
• Time ranges: each request covers at most one hour. Empty ranges still move the position forward.
• Catching up: a polling cycle processes at most 24 ranges, which is 24 hours of records. A long first-run window or an outage is therefore collected over several cycles.
• Errors: when a request or response fails, the position does not move and the same range is requested on the next cycle, so records are not lost while the service is down. Ranges that completed before the failure stay completed.
• Newest records: records appear in Logsign only after the Safety Lag and the next polling cycle have passed.

Troubleshooting

The poller log shows the result of each request. The HTTP causes below are general HTTP meanings; the service is your own, so its exact error responses depend on how your SAP team built it. In every case Logsign keeps the position and retries the same range on the next cycle.