Event logging

Operational guidance for Event logging in Fortified ID Access deployments.

Event log entries describe a well-defined set of events performed by the system. Events are separate from system logs. Event format is structured in Common Event Format, CEF.

An event consists of:

event id and a number of information items

Event detail level
Time of event
Event id
Friendly event display description
Optionally, additional decritive parameters relevant to the event context.

Example:

Application identity and outcomes

SAML IdP and OIDC OP events identify the target application with the following CEF extensions. Empty or unknown values are omitted.

Extension	Meaning
`applicationId`	Exact SAML SP entity ID or OIDC `client_id`.
`applicationIdType`	`sp_entity_id` or `client_id`.
`applicationProtocol`	`saml` or `oidc`, describing the target application.
`applicationProvider`	SAML IdP identity or the statically configured issuer of outgoing OIDC ID tokens, when known.
`applicationAttemptId`	Correlation ID for this application attempt, separate from the session's `traceID`.
`applicationResult`	Observed stage or result, listed below.
`applicationResultReason`	Fixed reason or stage code, when available.

Use these fields when correlating application access. Existing sourceServiceName and destinationServiceName fields retain their directional meanings. In particular, OIDC authorization code and implicit events still put the redirect URI in destinationServiceName; device authorization uses the client ID. An upstream IdP issuer on a broker event does not identify the target application. Identifiers are exact: do not automatically merge SAML identifiers that differ by :443, for example.

OIDC provider identity comes from the configured outgoing ID-token claims. Client claim configuration replaces the authenticator's default claim object. A missing or dynamic issuer leaves provider identity unknown; retain deployment and customer scope when grouping such events.

Event ID	`applicationResult`	Interpretation
`WEB_100103`	`requested`	Access accepted a request for a known application.
`WEB_100101`	`issued`	Access prepared its protocol response or token. This does not prove that the application accepted or used it.
`WEB_100102`	`rejected`	Explicit negative decision or protocol rejection; inspect the reason.
`WEB_100104`	`failed`	Failure at the reported stage; the underlying cause is unknown.
`WEB_100104`	`error`	Identified configuration or implementation error, such as unsupported SAML response binding.
`WEB_100105`	`cancelled`	Explicit cancellation of a browser SAML or OIDC attempt.

authorization_denied denotes an explicit negative authorization result. Reasons such as authorization_pipe_failed, pre_pipe_failed, and authentication_chain_failed identify a failure stage without classifying its cause. A failed pipe call is not sufficient evidence of policy denial. WEB_100044 and WEB_100045 remain AuthController pipe observations and must not be counted as terminal application decisions.

Group attempts by applicationAttemptId: one session can contain several attempts. Device authorization can repeat requested with the same attempt ID when the browser binds to the same pending device request. Device cancellation returns that request to PENDING and does not produce a terminal cancellation event.

Closing the browser, losing the network connection, session expiry, or missing log delivery can leave an attempt without a terminal result. Treat that outcome as unknown. Duplicate suppression in authenticator state is not a durable exactly-once delivery guarantee and does not isolate concurrent attempts against the same authenticator in one browser session.

System event ids

WEB_000000 Server initialising
WEB_000001 Server initialised
WEB_000002 Server starting
WEB_000003 Server started
WEB_000004 Server stopping
WEB_000005 Server stopped
WEB_000006 Server initialisation failed
WEB_000007 Server start failed
WEB_000008 Server stop failed