Audit plugin discussion

[nandhu-kumar]

We are adding a subscriber in ThunderID (Go backend) that forwards observability events to the Mosip Audit Manager /v1/auditmanager/audits endpoint. The first implementation mirrors the existing eSignet IdaAuditPluginImpl (Java) exactly, but several field mappings need confirmation from the eSignet / Audit Manager teams before we lock the contract.

Structures

ThunderID event.Event (source) — backend/internal/system/observability/event/event.go

Field	Type	Notes
TraceID	string	Correlation id across related events
EventID	string	Unique id for this event instance
Type	string	e.g. user.created, token.issued
Timestamp	time.Time	Event occurrence time
Component	string	Source service/component
Status	string	success / failure / in_progress / …
Data	map[string]interface{}	Free-form event-specific payload (unenforced)

Example Thunder event (one real TOKEN_ISSUED event from the publisher):

{
  "trace_id": "84920707-6148-46f6-b6ec-d82fe3bac755",
  "event_id": "019e44b3-4ef9-7493-8956-9616feec1088",
  "type": "TOKEN_ISSUED",
  "timestamp": "2026-05-20T14:54:22.3935474+05:30",
  "component": "AuthHandler",
  "status": "success",
  "data": {
    "client_id": "sample_app_client",
    "duration_ms": "8",
    "grant_type": "authorization_code",
    "scope": ""
  }
}

Note: data here has client_id, not userId / userName / idType — illustrating the unenforced-keys problem in Q5/Q3.

Mosip AuditRequest (target) — fields used by the Java plugin

Field	Java plugin value
eventId	event type string
eventName	event type string
eventType	SUCCESS / FAILURE / …
actionTimeStamp	LocalDateTime (no timezone)
hostName	"localhost"
hostIp	"localhost"
applicationId	"eSignet"
applicationName	"eSignet"
sessionUserId	userId or "no-user"
sessionUserName	userName or "no-user"
id	transaction id
idType	UIN / VID / … (IDA-specific)
createdBy	"IdaAuditPluginImpl"
moduleName	component name
moduleId	component name
description	curated JSON string (clientId, relyingPartyId, state, hashes, link-tx id)

Direct mappings (no ambiguity)

AuditRequest field	Thunder source
eventId, eventName	event.Type
eventType	event.Status (upper-cased)
actionTimeStamp	event.Timestamp
moduleName, moduleId	event.Component

Fields with no clean Thunder equivalent — questions

1. applicationId / applicationName / createdBy — Java hardcodes "eSignet" and "IdaAuditPluginImpl". Should we keep those literal (so Thunder events look identical to eSignet's in the audit trail) or use "ThunderID" / "ThunderIdAuditSubscriber" so the Audit Manager can distinguish the source product?

2. actionTimeStamp format — Java LocalDateTime serializes without a timezone. Does the Audit Manager strictly require the zoneless Java format, or does it accept ISO-8601 with Z? Go's default time.Time JSON encoding is RFC 3339 with offset (see +05:30 in the example above).

3. idType — ThunderID has no equivalent of Mosip IDA's UIN/VID. Options: always empty, hardcode (e.g. "thunderid-user"), or source from event.Data["idType"] when present. Preference?

4. id (transaction id) — Mosip expects a transaction identifier. Thunder's TraceID is the closest analogue but semantics differ (correlation id vs. transaction id). Acceptable, or should we look for a transactionId key in event.Data first and fall back to TraceID?

5. sessionUserId / sessionUserName — event.Data is a free-form map; keys are not enforced. Are "userId" / "userName" the right conventional keys to read, and is "no-user" the correct fallback (matching Java)? (The TOKEN_ISSUED example above has neither key — it would fall back for both.)

6. description — Java packs a curated JSON object (clientId, relyingPartyId, state, code/access-token hashes, link-transaction id). For Thunder, should we:

   • dump the entire event.Data map as a JSON string (simple, but may leak unexpected fields), or
   • curate a fixed allowlist of keys per event type (predictable, but more work to maintain)?

Any guidance from the Audit Manager / eSignet team on which of the literals must stay literal for downstream consumers (dashboards, reports, retention policy) would help us finalise the mapping.