Simplify Session Management and Access Control with OpenID Shared Signals and CAEP
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 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.
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.
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.
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.
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.
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:
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.
Want more of the latest identity-first security topics and trends delivered to your inbox? Helpful and insightful content, no fluff.