Skip to content
Sitesh Choudhary
← Architecture

IAM Observability: Monitoring an IGA Platform as a Governance System

· 3 min read
Platform DesignIntermediateOracle Identity Manager (OIM)

The problem

An IGA platform can be technically healthy — jobs running, connectors online — while still failing at its actual job. A provisioning task can fail silently and leave someone without required access for days. A connector can succeed but apply the wrong entitlement. A certification campaign can stall halfway through with nobody noticing until the audit deadline. Standard infrastructure monitoring (is the service up) doesn’t catch any of this, because the failures that matter here are governance failures, not availability failures.

Architecture overview

flowchart LR
Events[Provisioning & Lifecycle Events] --> Logs[Centralized Audit Log]
Connectors[Connector Health] --> Dashboard[Health Dashboard]
Logs --> Dashboard
Dashboard --> TechAlerts[Technical Alerts — failures, latency]
Logs --> GovMetrics[Governance Metrics]
GovMetrics --> CertProgress[Certification Completion Rate]
GovMetrics --> SoDViolations[Open SoD Violations]
GovMetrics --> OrphanAccess[Access Without Active Lifecycle Owner]
CertProgress --> GovAlerts[Governance Alerts]
SoDViolations --> GovAlerts
OrphanAccess --> GovAlerts
Observability spans technical health and governance health

Technical health (connector status, job failures, latency) and governance health (certification progress, open SoD violations, access that’s outlived its justification) are tracked as two related but distinct concerns, both sourced from the same underlying audit log.

Major components

  • Centralized audit/event log — every provisioning action, lifecycle event, and policy evaluation, captured with enough context to answer “why did this happen” later, not just “what happened.”
  • Connector health dashboard — per-connector success/failure rates and latency, surfaced by target system so a degrading integration is visible before it causes a backlog.
  • Governance metrics layer — derived from the same log: certification campaign completion rate, count and age of open SoD violations, access grants with no corresponding active justification.
  • Alerting — split into technical alerts (connector failures, job errors) and governance alerts (a certification campaign stalling, SoD violations aging past a threshold).

Design decisions

  • Governance metrics are first-class, not an afterthought. It’s common to instrument the technical layer (uptime, job success) and stop there. The metrics that actually get asked about in an audit — is certification on track, are SoD violations being remediated — need their own dashboards, not a manual report assembled at quarter-end.
  • Alerts are tiered by consequence, not just failure type. A failed provisioning for a low-risk application is a ticket; a failed deprovisioning for a leaver is treated as urgent, because it directly represents standing risk.
  • The audit log is the single source for both technical and governance views. Rather than separate logging for infrastructure monitoring and governance reporting, both draw from the same event log — which also means the audit trail used for SOX/GDPR evidence is the same data operators are already watching day to day.

Implementation considerations

  • Legacy and disconnected connectors often don’t emit useful telemetry natively. Instrumenting them usually means wrapping the manual fulfillment process itself (SLA timers, completion tracking) rather than expecting connector-level metrics.
  • Alert fatigue is a real risk. Early instrumentation tends to over-alert; thresholds need tuning against a baseline before the alerts are trusted enough to act on.
  • Dashboards need an audience-specific view. Platform engineers want connector-level detail; compliance stakeholders want certification and SoD trend lines. The same underlying data, presented differently.

Lessons learned

The instinct is to build observability around the platform’s technical operation, because that’s the familiar monitoring problem. The harder and more valuable part is instrumenting the governance outcomes — because those are what an auditor asks about, and they’re invisible unless someone deliberately builds the dashboards for them.