SSOGEN / SSO Audit Log With Tamper-Evident Integrity
Integration
SSO Audit Log With Tamper-Evident Integrity
Every sign-in, refusal and administrator action goes into an append-only chain with daily seals, searchable in the console and sent to your systems by signed webhook.
Why scattered, editable logs fail an audit
An SSO audit log has value only if an auditor can trust it. Auditors do not accept logs that are:
- scattered over a dozen systems;
- editable by the people they describe;
- contaminated with passwords and tokens.
In a breach, those logs become a liability. SSOGEN keeps one append-only trail that proves its own integrity.
A tamper-evident SSO audit log with export and webhooks
- Append-only, with a chain. A cryptographic hash links each audit record to the one before it. Nothing updates a row, so an altered or removed record breaks the chain and shows.
- Daily seals. SSOGEN seals each day’s records in a digest. You can verify the digest and the integrity of the chain from the console.
- Searchable and exportable. Find events by who, what and when in Monitoring, then export a redacted copy for your auditor.
- Archive without losing proof. Plan, export and commit older segments by day. The live log stays manageable, and the history stays verifiable.
- Send events where they are needed. Webhooks deliver sign-in and administrator events to another system as they happen. SSOGEN signs every delivery, so the receiver can check that it came from SSOGEN.
- See current activity. Monitoring shows active sessions and system health beside the log.
- Decisions explain themselves. You can replay access decisions with what-if. SSOGEN records refused sign-ins and launches with the reason.
- Least privilege for the auditor. The security audit reader role is for people who need to read the log without administering anything. Only super administrators and security audit readers see the detail of each event. Other roles see the summary.
How the hash chain, digests and retention work
- Catalog: audit events are typed and documented, covering authentication, federation, sessions, applications, administration, security, system components and non-human identities (AI agents).
- Redaction by design: events never contain passwords, TOTP seeds, recovery codes, authorization codes, tokens, cookies, private keys, full SAML assertions or private-access request bodies. Fields have size limits.
- Console and API: search, recent events, integrity check, digest verify and seal, export (a bounded page of up to 100 redacted events per request) and archive plan, export and commit. Archiving needs its own permission.
- Webhooks: an HMAC-SHA-256 signature over a timestamp and the body. The signing secret stays in the vault and is never listed.
- Gateway events: the SSOGEN Gateway reports its own events and remote-session events to the same trail. Session events carry no person data.
- Evidence for your audit: the log is the evidence for your own compliance certification. Signed webhooks and redacted export send it to your SIEM or archive.
What auditors and security teams do with the log
- Answer “who changed this policy, and when” in minutes.
- Show an auditor that nobody has altered the log since the last digest.
- Send sign-in failures to your own monitoring through a webhook.
- Prove that a leaver’s access ended, and when it ended.
- Show which person an AI agent acted for, as an AI agent delegation audit requires.
What it looks like in the Admin Console
The Audit page: integrity status, daily checkpoint, archive controls and the table of recent events
Where to go next
Read the guide to the tamper-evident audit log. Send events to your tools with webhooks. See the adaptive authentication policies that produce many of the entries.