Interest in the OpenID Foundation’s Shared Signals Working Group work for CAEP and Shared Signals has really grown in the past few months. (See this June 2023 post for our coverage of the announcements from Apple and Okta.)
The session I conducted at Identiverse 2023 with Tim Cappalli of Microsoft, was well attended, ran long, and had a lot of really great and interesting questions from identity practitioners interested in the progress and actionability of CAEP. I’ve also attended gatherings internal to large companies as a guest, and been excited to see the uptick in organizations considering how CAEP and SSF may help their security posturing.
Across these forums, I’ve noticed similar questions come up. So in this blog post, I wanted to highlight interesting use-cases, and answer some questions I’ve heard.
What is CAEP?
What started as an independent effort with my Google blog post (from early 2019, when I worked there) became the driving force behind the formation of the OpenID Foundation Shared Signals working group. CAEP now stands for Continuous Access Evaluation Profile, which is a profile of the OpenID Shared Signals Framework (SSF).
SSF is a generic asynchronous publish and subscribe framework with flexible subject definition, stream controls and reliable delivery mechanisms. Any API can leverage it to implement webhooks. SSF enables streams of Events from Transmitters to Receivers. CAEP is a set of Event types that enable Transmitters (i.e., publishers in the publish and subscribe framework) to communicate session properties to Receivers (i.e., the subscribers in the publish and subscribe framework).
Transmitters and Receivers communicate with one another using SSF to help organizations implement dynamic session controls by building awareness of any Events that can impact session security. This helps achieve zero-trust using open standards because every access decision is now enforced by leveraging the latest information that was propagated through CAEP events.
Is it a CAEP Transmitter or SSF Transmitter?
The framework to establish communication streams between Transmitters and Receivers is always SSF. A specific SSF Transmitter may only support CAEP Events, and is therefore called a CAEP Transmitter, although it is also an SSF Transmitter.
Who can be a CAEP Transmitter or Receiver?
Since CAEP relates to login session security, it often maps to federated identity models of Identity Providers (IdPs) and Service Providers (SPs), also known as Relying Parties (or RPs). However, there are other services that can impact session security, like device management services, endpoint security services or credential security services. Anyone who has new information about an identity that needs to be conveyed to other parties can be a CAEP Transmitter. For instance, a relying party (e.g., SaaS app) that sees potentially anomalous behavior with a user, may decide a user needs to be logged out of their app and can transmit Events such as “session revoked” to other Receivers. An IDP listening for session revoked Events can revoke that user’s login session in response and issue “session revoked” Events to other relying parties.
How is trust established?
SSF enables comprehensive negotiation capabilities so that Receivers can trust Transmitters for specific Event types, subjects, and delivery models. The Transmitter hosts the SSF API, which requires authorization to access and the Transmitter may decide how to authorize calls to this API from Receivers. Typically, a Transmitter will use OAuth to authorize such requests based on some predefined trust relationship.
A Receiver may request certain Event types to be included in the stream from the Transmitter. A Transmitter may independently decide which Events it includes in the stream. Similarly, a Receiver may request certain subjects to be included in the stream or removed from the stream. The Transmitter can also add or remove subjects from the stream.
How is delivery guaranteed?
There are two delivery models supported by SSF: Push and Poll.
In both models the Receiver provides acknowledgement that it has processed the received Event. Upon getting the acknowledgement, the Transmitter does not resend the Event, else the Transmitter keeps resending the same Event until the Receiver acknowledges it. As a result, delivery of each Event is guaranteed in the protocol.
What are common use cases of CAEP?
CAEP supports Events that indicate session revocation, assurance level change, device compliance change, credential change and token claims change. These Events support a multitude of use cases.
The most common events where organizations will find value with CAEP include:
- Session Termination: An IdP or SaaS app may decide to terminate a user session for various reasons. An IdP may get an administrative request to do so, or any service may detect behavior that indicates session compromise. CAEP enables a service to communicate this situation to all Receivers that trust it and are listening for this information. In the IdP example above, the IdP may send a “session-revoked” CAEP event to specific applications when the administrator suspends user access to those apps
- Credentials Change: A “credential change” Event is sent when a user changes their credentials. Typically, an IdP will send Events of this type. RPs can decide how to process such Events. In some cases, an RP can allow users reduced access to their application, and require that the user signs in again after receiving such an Event if they attempt a sensitive action. For example, a billing management application may allow users to read existing customer data even after receiving a “credential-change” CAEP event, but when the user tries to issue a refund, the app may require the user to reauthenticate
- Device Compliance Change: A device management service may indicate to an IdP (or a RP) that a device that was used to sign-in and access applications has failed to comply with organizational policy (or that a previously non-compliant device is now compliant). The Receiver of such Events can decide what actions to take. For example, an RP may decide that certain apps may still be accessed, or they may decide that the user needs to be blocked from accessing the app until the device gets back into compliance
How is SGNL supporting SSF and CAEP?
Being able to centrally manage access across applications and infrastructure in today’s zero-trust, and hybrid, multi-cloud world requires continuous access management. SGNL was founded with a vision that centralized, continuous access management is the best way for organizations to manage access at scale. CAEP is an open standard that helps us realize this vision, which is fully supported by our products.
To encourage standardization and adoption, we co-chair the OpenID Shared Signals Working Group and support caep.dev, a free, online CAEP Transmitter that enables developers to test their Receiver implementations. SGNL also maintains the caep.dev open source Receiver that implementers can use to build their own receivers.