TA_Guardium API Add-on for Splunk

[0xAli]

Hi All,
I hope all is well.

Kindly, anyone works with Guardium API Add-on for Splunk:

https://splunkbase.splunk.com/app/8290

I have two questions:

1. The auth-token will be expire just in 3 hours, is this addon will refresh it

I used this command to generate the token:

grdapi register_oauth_client client_id=splunk_client2 grant_types="password" user="admin" password="<PASSWORD>" GetToken=1

Output:

{"client_id":"splunk_client2","client_secret":"440cef5c-42a8-4fd5-9741-17266cxxxxx","grant_types":"password","scope":"read,write","redirect_uri":"https://someApp"}
{"access_token":"token","token_type":"bearer","expires_in":10799,"scope":"read write"}

2. This command doesn't work properly as expected?

url -k -X POST https://<guardium_host>:8443/restAPI/online_report \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"reportName":"SQL Activity","indexFrom":"1","fetchSize":30000}'

[natecrisler]

I have also tagged the developer (@efheem) on this thread to raise visibility and get his input.

[natecrisler]

Hey 0xAli, I haven't run this add-on myself, so rather than guess I pulled the package off Splunkbase and read through the collector code (bin/input_module_guardium_online_report.py). That answers both your questions and turned up a couple of things you'll want to know before you lean on it.

1. Token refresh: no, it won't. The only auth setting is the global auth_token, a bearer token you paste in. There's no client_id, no client_secret, and no Guardium GUI login anywhere in the config or the code. The collector just stamps Authorization: Bearer with that stored token on every call. Since the password grant gives you no refresh_token (check your output, there's only an access_token) and the add-on has no credentials to re-authenticate with, the token expires at the ~3 hour mark (expires_in 10799 is Guardium's default) and the calls start failing.

And here's the part that matters more than the expiry itself. When a run fails, the code still advances its checkpoint to the current time and saves it. It does that on the unreachable path, the JSON-parse path, and the error-response path. So once your token expires, every 60 second run fails, logs a warning, and then moves the checkpoint forward to now anyway. By the time you notice and paste in a fresh token, everything between expiry and the fix is gone, with no backfill. So the token issue isn't just "ingestion stops", it's "ingestion stops and silently drops the gap". Worth knowing before you put this in front of anything like compliance reporting.

Until the developer adds credential-based auth, the realistic options are to script the token regeneration and write the fresh token back into auth_token before it expires, or to stretch the lifetime with setOAuthTokenExpirationTime. That last one is a global appliance setting with the obvious security tradeoff, and the token still expires eventually, so treat it as a stopgap. Either way, watch the logs for "Guardium API unreachable after retries". That line is how an expired token actually shows up, because the 401 gets caught and retried rather than reported as an auth failure.

2. The online_report call. Two things, and the second is why your command behaves the way it does. The tiny one: it starts with "url" instead of "curl", a paste slip. The real one: your body has no reportParameter block, and online_report returns ErrorCode 1001 without it. The reason the add-on works but your hand-run doesn't is that the collector builds that block for you. Straight from the code, it sends QUERY_FROM_DATE and QUERY_TO_DATE plus the report's runtime params: ServerIP, DBUserName, OSUser, DBName, DBUser, SHOW_ALIASES, REMOTE_SOURCE, SourceApp, FullSQL. So for a manual test, add the same block (corrected call below). reportName also has to match an existing report exactly and the token's GUI user needs access to it, and fetchSize tops out at 30000.

A few more things I noticed in the code while I was in there:

• It treats Guardium error responses as empty. If the report name is wrong or a parameter is off, Guardium replies with a JSON object, and the code logs that as "No data returned" at INFO and stops. So if you ever see "No data returned", don't assume the window was empty, it can be a hidden error, and per the checkpoint behavior above it still advances past that window.
• Dedup is a one second watermark, not real dedup. It tracks the highest Timestamp at second resolution and keeps only rows greater than it. In a busy SQL feed, events that share that boundary second across two runs can get dropped.
• Times are local. The query window end uses the forwarder's local clock, and event time is built from the row timestamp as local time, so if the forwarder and Guardium aren't on the same timezone, the window is offset and your event times are skewed.
• Small one: paging starts indexFrom at 1 instead of 0, so the first row of a result set gets skipped.

None of that means it can't work. For a single timezone, lower volume setup with a long lived token it's fine. The checkpoint-on-failure behavior is the one I'd be careful about, especially paired with the 3 hour token.

Corrected manual call below, fill in your real date range:

curl -k -X POST https://GUARDIUM_HOST:8443/restAPI/online_report \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "reportName": "SQL Activity",
        "indexFrom": "1",
        "fetchSize": 30000,
        "reportParameter": {
          "QUERY_FROM_DATE": "2026-05-01 00:00:00",
          "QUERY_TO_DATE": "2026-05-07 23:59:59",
          "ServerIP": "%",
          "DBUserName": "%",
          "OSUser": "%",
          "DBName": "%",
          "DBUser": "%",
          "SHOW_ALIASES": "true",
          "REMOTE_SOURCE": "%",
          "SourceApp": "%",
          "FullSQL": "%"
        }
      }'

Docs:

• IBM: Using Guardium REST APIs (auth flow and token lifetime)
• IBM: Create online report REST API reference

For a token-only input like this, the durable fix is a small scheduled job that re-mints the token and writes it into auth_token before the old one expires, which also sidesteps the checkpoint gap. If you want to stay on this add-on, that's the piece I'd add first.