CAEP and Shared Signals: Real-Time Session Management Explained

When an employee is terminated, how long until their access is actually revoked? With traditional IAM, it can take hours or even days. CAEP (Continuous Access Evaluation Protocol) and the Shared Signals Framework (SSF) solve this by enabling real-time security event propagation.

In this deep dive, we'll explore how CAEP works, why it matters for modern security, and how TigerIdentity implements it to achieve sub-second session revocation across your entire infrastructure.

The Session Revocation Problem

Traditional IAM systems operate on a polling or batch sync model. When a critical security event occurs, there's a dangerous gap between the event and the enforcement:

What Is CAEP?

CAEP transforms identity security from a batch-oriented, eventually-consistent model into a real-time, event-driven architecture. Instead of waiting for sync jobs to run every 15 minutes or hour, security events are pushed immediately to all participating systems.

How It Works

CAEP events are transmitted as signed JSON Web Tokens (JWTs) containing structured security event data. Here's what a session revocation event looks like:

{
  "typ": "secevent+jwt",
  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
      "subject": {
        "format": "email",
        "email": "[email protected]"
      },
      "event_timestamp": 1706198400,
      "reason_admin": "Employee termination",
      "initiating_entity": "HR System"
    }
  }
}

When TigerIdentity receives this event, it immediately:

1. 1.Validates the JWT signature to ensure authenticity
2. 2.Identifies all active sessions for the subject ([email protected])
3. 3.Revokes sessions across all connected applications
4. 4.Propagates the event to downstream systems via their CAEP endpoints
5. 5.Logs the event for audit and compliance reporting

This entire process completes in under one second, turning what used to be hours of exposure into milliseconds.

CAEP Event Types

The CAEP specification defines multiple event types for different security scenarios. TigerIdentity supports all standard events and allows custom event types:

TigerIdentity's CAEP Implementation

TigerIdentity provides a complete CAEP infrastructure that acts as both a receiver and transmitter of security events:

This architecture ensures that security events flow seamlessly across your entire identity ecosystem, from HR systems to SaaS applications to internal services.

Configuration Example

Setting up CAEP in TigerIdentity is straightforward. Here's a complete configuration showing how to receive events from Okta and your HR system, then propagate them to your applications:

caep:
  enabled: true

  receivers:
    - name: okta-events
      type: ssf
      endpoint: https://company.okta.com/.well-known/ssf-configuration
      events: [session-revoked, credential-change]

    - name: hr-system
      type: webhook
      endpoint: https://hr.company.com/events
      events: [employee-terminated, department-changed]

  transmitters:
    - name: downstream-apps
      events: [session-revoked, token-claims-change]
      subscribers:
        - https://app1.company.com/caep
        - https://app2.company.com/caep

  actions:
    session-revoked:
      - revoke_all_sessions
      - notify_security_team

    credential-change:
      - force_reauthentication

    token-claims-change:
      - reevaluate_policies
      - update_session_context

    device-compliance-change:
      - adjust_access_level
      - trigger_compliance_check

With this configuration, TigerIdentity automatically handles the entire event lifecycle - from receiving signals from upstream identity providers to enforcing policy decisions and propagating events to your applications.

Why CAEP Matters for Your Security Posture