Overview
The OpenID Shared Signaling Framework (SSF) enables real-time sharing of security events between systems and organizations through standardized Security Event Tokens (SETs). SSF includes two key profiles: the Continuous Access Evaluation Profile (CAEP) for dynamic session management and the Risk Incident Sharing and Coordination (RISC) profile for cross-organization incident response. Rather than relying on static token lifetimes, SSF allows systems to immediately respond to security events—session revocation, credential compromise, device compliance changes—across trust boundaries. This capability is foundational for Zero Trust architectures where continuous verification requires real-time security context. Organizations implementing SSF can terminate compromised sessions within seconds instead of waiting for token expiration, dramatically reducing the window of exposure from security incidents.
Architecture & Reference Patterns
Pattern 1: IdP-to-SP Event Streaming (CAEP)
The Identity Provider transmits CAEP events (session revoked, credential changed, assurance level changed) to subscribed Service Providers via webhook or polling. SPs immediately invalidate sessions or require reauthentication when events are received. Primary use case for enterprise SSO environments where the IdP detects risk and SPs need to respond.
Pattern 2: Cross-Organization RISC Federation
Multiple organizations in a trust federation share RISC events (account compromised, credentials stolen, identifier recycled) to enable coordinated incident response. When one organization detects account compromise, federated partners are notified and can take protective action for shared users. Essential for consumer identity federations and B2B scenarios.
Pattern 3: SIEM/SOAR Integration
SSF events are consumed by Security Information and Event Management (SIEM) systems for correlation and threat detection, and by Security Orchestration, Automation, and Response (SOAR) platforms to trigger automated incident response workflows. Enables security teams to incorporate identity events into broader security monitoring.
Pattern 4: AuthZEN Policy Integration
SSF events feed into Policy Decision Points (PDPs) implementing AuthZEN, providing real-time context for authorization decisions. When a device compliance event is received, subsequent authorization requests reflect the changed security posture. Enables continuous authorization based on current context rather than point-in-time authentication.
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| Event delivery method | Push (webhooks), poll, hybrid | Push for time-critical events; poll for reliability | Push requires endpoint availability; poll introduces latency |
| SET validation approach | Signature only, signature + issuer validation, full claim validation | Full validation including iss, aud, iat, exp | Partial validation creates security gaps |
| Event retention policy | No retention, short-term (hours), long-term (days) | Short-term retention for replay and debugging | Long-term retention may have privacy implications |
| CAEP vs. RISC scope | CAEP only, RISC only, both | Start with CAEP for session management; add RISC for federation | CAEP is simpler to implement; RISC requires cross-org trust |
| Event filtering | All events, filtered by type, filtered by subject | Filter by subject where possible to reduce volume | Unfiltered streams can overwhelm receivers |
| Failure handling | Ignore failures, retry with backoff, queue and retry | Queue with exponential backoff | Immediate retry can amplify outages |
Implementation Approach
Phase 0: Discovery
Inputs: Current session management architecture, IdP capabilities, SP inventory, security incident response procedures, federation relationships Outputs: SSF capability assessment (which systems support it), use case prioritization (CAEP vs. RISC), trust relationship inventory, event volume estimates, security response gap analysis
Phase 1: Design
Inputs: Discovery outputs, security requirements, performance requirements, privacy requirements Outputs: SSF architecture document, event type selection, transmitter/receiver design, SET validation specification, event processing pipeline design, privacy impact assessment
Phase 2: Build & Integrate
Inputs: Design documents, IdP/SP SSF capabilities, test environments, SIEM/SOAR integration requirements Outputs: SSF transmitters configured, SSF receivers implemented, SET validation operational, event processing pipelines tested, SIEM/SOAR integrations functional, monitoring dashboards deployed
Phase 3: Rollout
Inputs: Tested SSF infrastructure, phased rollout plan, monitoring dashboards, incident response updates Outputs: CAEP events flowing between IdP and critical SPs, RISC events shared with federation partners (if applicable), security playbooks updated for SSF events, operational procedures documented
Phase 4: Operate
Inputs: Production SSF environment, monitoring dashboards, incident response procedures Outputs: Event delivery reliability maintained, security incidents trigger appropriate SSF events, event processing latency monitored, federation trust relationships maintained, continuous improvement of event coverage
Deliverables
- SSF architecture document with transmitter/receiver topology
- Event type catalog with processing requirements per type
- SET validation specification
- Event processing pipeline design
- SIEM/SOAR integration playbooks
- Privacy impact assessment for event sharing
- Federation trust agreements for RISC (if applicable)
- Incident response playbook updates for SSF events
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| Event delivery delays leave sessions active | M | H | Event processing latency increasing, sessions surviving revocation | Monitoring latency, redundant delivery paths, short token lifetimes as backup |
| Invalid SET accepted leads to unauthorized action | L | H | Security assessment findings, unexpected session terminations | Full SET validation, signature verification, issuer allow-listing |
| Event volume overwhelms receivers | M | M | Processing queue depth increasing, dropped events | Event filtering, receiver scaling, backpressure mechanisms |
| False positive events disrupt legitimate users | M | M | User complaints, sessions terminated unexpectedly | Event source validation, configurable response policies, appeal process |
| Federation partner breach compromises trust | L | H | Partner security incident notification, unusual event patterns | Trust boundary controls, event source verification, rapid trust revocation |
| Privacy concerns from event sharing | M | M | Legal/privacy team concerns, regulatory inquiries | Data minimization in events, privacy impact assessment, consent where required |
KPIs / Outcomes
- Event delivery latency: P99 under 5 seconds for critical events (session revoked)
- Event processing success rate: Target 99.9% of events processed without error
- Session revocation effectiveness: Compromised sessions terminated within 30 seconds of event
- False positive rate: Track and minimize events triggering unnecessary user disruption
- Federation coverage: Percentage of federated partners participating in RISC
- Security incident response time: Should decrease with real-time event sharing